Jump to content

Flexman

Members
  • Posts

    916
  • Joined

  • Last visited

Blog Entries posted by Flexman

  1. Flexman
    Taking a little time-out from debugging to recharge my batteries, something slightly less frustrating, camera views.
     
    Not helped by my original program flow which had camera commands in-line where needed, and I still have to go through and fix up TrackIR to work with the new class but shouldn't take long. TrackIR is really simple to implement in this kind of software.
     
    Crew positions are parented to a pivot and then offset so it was important to retain any camera/parent relationships, add offsets to source entity location and target entity location (in case the view needs to point-at some object but add some fudge factor, such as trackIR offsets or something).
     
    So I untangled the inline camera code and added a new class with SetPostion() Move() SetParent() SetOffset() etc.. and added GameCamera.Update() which does the final camera positioning. Now changing cameras is as simple as updating the GameCamera class you wish to render the viewpoint from. It will be possible to add camera views from an external source with a bit of extra code.
     
    These screens are not using the current terrain so still a bit washed out and using the old veg (will update my test build in the next few days, it just takes longer to load which doesn't help testing).
     
    Blade tip cam will be added again shortly. And I need a key to toggle the canopy doors (yes they do swing open and closed).
     




    And I remembered to increase the TADS camera range to 6km, I'm not using deferred lighting on the TADS buffer, just shader effects for light amplification and edge detection but need some atmospheric fogging to fade into the distance. Scratching my head on best way to implement that one.
     
    Source
  2. Flexman
    AD has been working on a new FOB which will be the "other" main camp you'll be deployed at during the course of the campaign.
     

    It's a triangle arrangement used by some forward operational bases. Here the CH47s are ready to be deployed.
     

     

    And finally..
     

    Don't have a name for the camp yet.
     
    Source
  3. Flexman
    Dave's been busy building the unsung hero of Afghanistan and other operations around the world.
     
    Rolf: Can you tell what it is yet? ;-)
     
    It's a non-flyable but will feature prominently in the game as you'll be tasked to provide armed escort for supply, insertion and extraction missions.
     
    Much time has been spent correcting smoothing errors. Brilliant work. We'll be adding the same functionality to the rotors and rear door using LUA scripts. This morning we were looking at the various flavours of cockpit, of which there are many. Never the same cockpit twice. I thought the Apache tandem cockpit was complex. The amount of work required to make this a flyable is out of the question right now. It's a level of complexity rivalling the Apache and a candidate for future expansion.
     
    Source
  4. Flexman
    Check off the list, working external canopy doors, flip up/down, will indicate available crew position as well as letting you chat to your mounted team-mate while you're on foot. You could even arm the pilots chopper for him.
     
    Internal doors and wipers next followed by external lighting system. Hopefully we'll have the cold start-up sequence in a few days, we need that so we can get on with more vital systems.
     
    (I just noticed the text on the rail is reversed)
     
    Source
  5. Flexman
    For the record, practical work on the detailed CH-47D interior started yesterday.
     
    The CH-47D is a great machine better suited to the environment in which it will operate in Combat-Helo. The Chinook (prn: shin-uk) is a surprisingly nimble and small helicopter, not the large lumbering giant as is often perceived. What you may find surprising (I did anyway) was that it's about the same size as the Apache. See the comparison image below.
     
    Apache / Chinook size comparisonIn Afghanistan, the CH-47 usurped the role of the UH-60, having a larger lift capacity, no energy hungry tail boom, armed protection from it's ramp and door gunners as well as a range of countermeasure devices. It's range, power and speed has saved the lives of many Afghan civilians and troops in the region. Additionally, transport helicopters reduce the reliance on vulnerable road convoys and are important in maintaining remote security outposts.
     
    The AI CH47 will be included in Combat-Helo. If we hit our sales target we hope to release a flyable CH-47D with detailed cockpit and systems as an addon (or stand-alone version - to be decided), as Combat-Helo Operation Pegasus. This will add the CH47 as an option to fly on medevac, armed escorts, insertions, extractions, transport, search and rescue missions as well as a new variant of the counter insurgency campaign.
     
    We feel that this is the better choice, it lets us explore the portalised aircraft technology we started with the Apache which will enable a level of interaction between crew that hasn't been seen in any other PC simulation title to date.
     
    Source
  6. Flexman
    The CH-47F has had a lot more work done in the cockpit area. The seats are looking remarkably clean, I just need to get a child to play inside with some squeeze boxes and a can of 3in1 oil.
     
    The Chinook is smaller than you might think, with a fuselage approx 50ft long, it's shorter than the Apache which is 58ft long (approx). I was surprised by that.
     
    Networking
     
    Today saw successful Combat-Helo net connection between the Leeds UK and Bangkok in Thailand. Getting the link to work through two routers involved the same port forwarding process as is required for BlackShark. Enabling NAT punch-through requires an external service to act as a matchmaking partner. Since the onus is on the host, we'll assume they know what they are doing anyway.
     
    The address-book had some problems with the XML save/update, now fixed. More changes to the colour scheme. A tidy into bar at the bottom rather like the in Falcon3+ and LockOn displaying connection status, camera, mode, fps etc. General tidy work to polish what's been completed already.
     
     
    Apache HMD
     
    I corrected the Helmet Mounted Display to show the pitch ladder and horizon line as fixed instead of being locked forward (as seen in the YouTube VRCockpit First Look video). Much better for the pilot, now I can comfortably look around and make corrections to the aircraft.
     
    There's more work to do in the cockpit to make front/rear/solo seat modes work. This is my focus for the coming week which will sees that engine start-up procedure working at last.
     
     
    Game Engines / iPhone
     
    We pre-ordered Unity 3.0 last week since it was on offer. We can squeeze the Combat-Helo PC campaign into a stripped down iPhone game. Fans of Combat-Helo can support PC development and have a little fun pretending to be an Apache gunner for 3 minutes at a time.
     
    I still haven't migrated the PC Leadwerks engine to 2.32 yet. So many issues with the cockpit and camera-picking still. Some surface switches in our pit have a tolerance of 0.05 units and were not being recognised. This tolerance is perhaps too small anyway given floating point inaccuracies. These shouldn't be a problem when I move away from rendering the cockpit in the main world (still on my to-do list). Speaking of which here's the current priority list...
     
    To-do
     

    Electrical power system and engine start-up Master Arm and weapon selection Cubic spline interpolation for client character controllers Landing gear dynamics (still makes landing difficult)
     
    Combat-Helo : Operation Ouroboros
     
    Operation Counter Insurgency was noted on shots of a splash screen posted a while back. As remarked by one soldier, "It's not very military". This harks back where we didn't have a clue for a project title, it didn't seem to be a priority. For months it remained "Unnamed Helicopter Project" or UHP. Operation Counter Insurgency (OCI) came out of that as something to fill a splash screen. In keeping with the military tradition of using really obscure names (British operations have some really odd ones), Operation Ouroboros represents the endless cycle of conflict in the region. As an ancient symbol of a dragon or serpent that swallows itself, it's unlikely to be trademarked. Above all, it makes the game sound like a sneeze "CHOO".
     
    Bless you.
     
     
     
    A photo that sums up a fairly typical start to a Combat-Helo escort mission.
     

     
    Source
  7. Flexman
    Was exactly a year ago today we started work on Combat-Helo. I really don't know where the time has gone. Happy buffday team, and well done. To commemorate the occasion I dug out one of the earliest screen-shots I could find to compare with one from this afternoon.
     
    And thank you to everyone who's offered kind words of support and encouragement. It all helps.
     
    Sept 2010 - "Herat"
     

    Oct 2009 - "Camp Zero"
     

     
    Source
  8. Flexman
    Now available.
     
    *edit* A few additional notes...
     
    The controller setup page shown in this video has a number of devices listed. These are just the ones I had plugged in at the time of recording. All DirectInput controllers should be available, some will have ready to fly config files (most Saitek sticks, Logitech).
     
     
     
    I forgot to turn on the post processing effects since I work without them (generates more heat). There is a LOT of changes going on to various sensors and the IHADSS won't be updated to reflect these changes until I've done the MPDs. So please no accuracy police, I'm aware of the various bits and bobs. It's all in hand.
     
     
    YouTube Link: http://youtu.be/L8AHX8uXHpQ?hd=1
    Vimeo Link: http://vimeo.com/29957378
     
     
     
    Screenshot of the day
     
    Cleanup in lanes 1,2,3,4,5 and 6 please.
     
    Padlock, shoot, padlock shoot, HMD mode
    cleans house at close range , almost too easy

     
    Source
  9. Flexman
    I'm happy to announce that Combat-Helo will incorporate Frederic Naar's HTR Helicopter Total Realism technology for advanced helicopter flight dynamics. (link: Hovercontrol forum, HTR section). Developed as an external physics model that interfaces with Microsoft Flight Simulator via Pete Dawson's FSUIPC, HTR is an impressive implementation of blade theory using door-stopper text-books that designers of helicopters use as source material.
     
    Fred invited me over for a few days for a mutual show-and-tell and I got to see first hand how detailed the model is from the author, who better? First with the Bell 206, which had a tendency to side-slip to the right as weight comes off the skids, which left unchecked could potentially result in a fatal roll-over. Then I got a lecture on stabiliser wings and how vertical stabilisers depending on angle of airflow go from "sail area" to a wing generating lift. Blade flap and pitch is calculated per physics update, the amount of detail resulted in me experiencing a full frontal happy-attack.
     
    After the Bell 206, Fred introduced me to an early Apache flight-model. I didn't find flying with a Microsoft Sidewinder easy, also I'm now used to flying with my joypad (I have shame). Stick in hand, trying desperately to keep the nose on a tree while slipping sideways to gauge the tail drag and weight, with limited success. Apache seemed to make all the right movements with changes to collective and airspeed. Even attempting the classic Apache hammerhead turn, HTR delivers sweat inducing concentration required for advanced helicopter flight. HTR also offers stabilisation and a most impressive auto-pilot function, checking boxes required for Combat-Helo's assisted flight mode. Trim seemed to be a non-issue except when the autopilot was flying to a stable-hover when the pilot was fighting excessive trim while attempting to slow down.
     
    Given that HTR has to work within the limitations of Microsoft Flight Simulator, the implementation for Combat-Helo allows us to use even more parameters; feeding information about local terrain conditions for calculating updraughts, downdraughts , a detailed powertrain simulation as well as the ability to monitor rotor-behaviour via the nausea inducing blade-camera.
     
    The flight-model should also be able to handle a load carrying CH-47, applying all the right moments of inertia. Pretty elegant stuff, a masterful use of OOP.
     
    With Fred's addition we have completed the triad of physics, systems and technical art.
     
    Finally I'd like to thank Frederic and family for their hospitality as well as the staff of Corte Dei Tusci hotel who were always friendly and manage to create the most amazing foods daily.
     
    Source
  10. Flexman
    We're not trying to re-create Armed Assault, or even build some form of Helicopter MMO. Our plan is to take the old school 2D interfaces of military bases and create 3D analogues. Mission assignment and planning is done in the command tent. This is still exploritory, we have a number of office furniture elements planned, some of which we have tried in the editor to get a feel.
     
    There's more furniture to come. A mil-spec laptop/terminal, interactive map on a board (that's a copy of your personal map - will use the same buffer).
     
    And eventually we hope to have various AI pilots sitting in on briefings that you might want to converse with Wing Commander style. Romeo 1 from the intro mission will be hanging around. Along with WO J Petersan and others from time to time.
     
    I don't have much time to decorate, just placing these objects around my test-map to check how they look and function but it should give you an idea.
     
    With a couple of AI guys and a co-op friend there should be enough room to keep it looking busy. It's possible we might make AI crewman choices ala Gunship 2000 available in this manner if it works.
     
    We need some flooring I think. Hexmesh or some other plastic matting.
     
    Using a projected texture for mission briefings on the OHP. Interacting with a screen set 5 meters away is problematic, once at the projector you'll get to interface which will allow you to view available missions and annotated map, with a "close up" option (position a 3rd person cam up close to the screen).
     
    Like with other parts of the game, such as arming, the player interfacing with the projector will have their data shown to everyone else. Allowing you to give briefings. If there's time we might add a laser pointer for mouse control.
     
    We're using a 1024x1024 buffer for the projector which is a material assigned to a special spot_light entity parented to the OHP model. Objects/avatars walking in front of the projector have the image mapped over them in a realistic manner. So you too can act like a right tit in front of the C/O making shadow puppets with your head.
     
     
    Additional objects in the command tent will operate on a private level, mission planning and editing will work on a laptop type screen and a wall map will be copy of your pop-up map. There may also be a Sierra Hotel score board, I think that's required by tradition.
     
    So this the the start of the important ground office in Combat-Helo. We tend to have about three different project elements on the go at any one time, rather like making a series like Star Trek, planning, filming and pre-production.
     
     
    Finally a recent ETADS screen-shot, taking a peek at a sign through the trees some distance away (it's way off to the left out of sight so don't bother trying to spot it). Some folks will be well pleased with the corners. This coming week I'll be working on the event system (delayed due to PC technical problems, see earlier blog posts) and more of the TADS elements.
     

     
    Source
  11. Flexman
    Today I added the ubiquitous chat console complete with 4 colour coded channel presets, Global, Side, Group, Vehicle. Complete with command parsing (/setkey lets you send keys to any object you're standing before which is handy). The console also has a command history using the UP/DOWN cursor keys.
    Chat entry toggled by hitting the ENTER key ala Warcraft. Be aware that the primary action key has moved from the ENTER key to the "P" key (P for primary and also handily close to the square brackets used for menu navigation.
    Clipboard paste is supported via..
    Extern "Win32"{ Function OpenClipboard(hwnd%) Function CloseClipboard() Function GetClipboardData:Byte Ptr(Format:Int)}if(OpenClipboard(0)) String.FromCString(GetClipboardData(1));
     
    Console text entry mode also disables all input mapper KEY_DEVICE inputs to avoid conflict. It was important to Flush the keybuffer on exit otherwise all those spaces translated into SUPER JUMPS after entering text. Besides, you should always flush before you leave.
    Network comms chat is working fine except an occasional (Not Responding) display "freeze" only when the server was active. I thought was a problem with my Raknet interface but logs show packets still being processed by the game. The problem seems related to not wearing the TrackIR pro-clip device when the network is active. As soon as I put on the head tracker device the display responded normally as if nothing had happened, even chat catches up. Most odd as I've not experienced this with TrackIR before.
    Commands for server control are working including IP ban/unban. I do need to harden the user interface for network connections, the menus need to change to show the connection is already active and offer a disconnect. And the client needs a suitable connect-time period before giving up and allowing a re-try. We will begin NAT testing when I've got that sorted.

     
    Last night I made a DLL into which I was able to pass a structure containing flight data. It did nothing beyond reading it back but will be handy for exporting game data to third party programs.
     
    My TrackClip Pro has fallen apart. Only glue is holding it together.
     
    Source
  12. Flexman
    Compounds, the Herat map contains approx 500 of them. Each one consisted of a number of walls and out buildings. Turns out, these sub objects chewed through a bit of processing time. In effect there were 7500 objects getting worked through. That's a lot and it was reflected in the performance in LE 2.31 on a fully dressed map.
     
    By collapsing the compound models into a single object for the lower LODs we saw a large increase in fps in LE 2.31. Although LE 2.32 shows not much difference (it's a better performer anyway) due to it's quad-tree culling system. Even so there lots of fine tuning to do, cockpit switches to be instanced, general code trimming. Entity view ranges, material combining and a dynamic detail function to add.
     
    Today I've been working on fixing the lighting buffer for the cockpit entity but I'm having problems copying the cockpit buffer into the main view buffer. Much strangeness, it's some alpha/blending issue I can't quite get a handle on but I'll get there.
     
    I spent some time looking at Open-flight as a specification for storing lots of scene data. It's not really designed for high efficiency 3D engines. And not surprising that other engines that use it have adopted some conversion process. Initially the idea was sound but on closer inspection it's just plain awful. Maybe I'm missing something in the organisation and construction of individual objects.
     
     
    Here are some random shots from today.
     
    Cockpit interior now moved to it's own world for rendering lighting. Materials are not happy but it's steady as a rock. You can see the GPU terrain mesh with it's 10 meter resolution rendering a DEM of mountains in the NW of Afghanistan.

     
    Not much to say about this. Pre optimisation and post debug slowdown. Not happy at all. It was just this slow on my dev machine. My laptop is much happier.

     
    The saturation and contrast levels adjusted on the "fly" can change the look of the game.
     

    I like heavily saturated games which is probably due to my first colour computer, a Sinclair ZX Spectrum which was a train-crash of colours, all eight of them. I still have one of the later models hanging around my desk (see photo I just took below). This one has an Interface 1 for Microdrives. If you don't know what they were, have a bit of fun and look them up. Strange to think that that kind of technology is still used as a backup system today. In the 80's my first games didn't get very good reviews, we had a laugh looking them up on the internet last week. They would make good mobile games today I think....hey I just found my keys.
     

     
    Source
  13. Flexman
    Never felt the need to keep fish until now. It's a crashed helicopter for use in your pond or aquarium. Thanks Phil (and Rob for sending it on).
     

    This wonder compares to the bizarre "Titantic with inflatable iceberge" bath toy I once found in an English Heritage gift shop.
     
    Source
  14. Flexman
    Dave completed more of the survival equipment, looking really good. The concept is simple, if you need to perform an emergency landing and leave your helo, the CSEL can be activated and will mark the location on everyone's tactical situation display. The signal flare may be use to mark your position visually.
     

    More up close pictures in the SimHQ thread here.
     
     
     
     
    I spun off a new shader to do the MPD video mixing. The symbology layer needed to mask the video layer using its alpha channel which was a five min job.
     
     
     
    Ideally I'd like to pass a "brightness" value to the shader but as the material is used for five displays which have their own settings, the symbology level is set by the alpha value.
     
     
    Here's the completed shader mixing sources and masking.
     
     

     
     

     
    Source
  15. Flexman
    Just got back home and Dave left a nasty sight in my MSN window. No, not another scene of drunken debauchery, actually I have to complain, there's been a distinct lack of that.
     
    We got to discussing visual representation of damage. Different ways we can do this. I write it here so I can remember what we discussed. We looked at some complex set-up of assets for iL2, the results of which are impressive but it hardly makes for an easy pipeline, especially if we want to quickly add more aircraft in future.
     
    After some thinking we boiled it down to two simple options.
     

    The first is application of a damage texture on parts (child objects) of the helo model that match the aircraft's damaged state. And Dave left me the following image, a simple test to check it out...

    Another technique is decals. Now I've looked at LE decals before and I don't think they will work everywhere on our map due to floating point and surface fighting in the outer regions. These are patches that positioned to be almost co-planer with the surface of a model (like the decals you stick on a model). If they work, they have the advantage in that they should work for everything.
    A more complex alternative is a new method of decals using a glyph shader. What we'd do is have a single texture upon which, in a grid patter is lots of damage and battlescar images. We pass this glyph texture into the mesh frag shader along with a damage map of the aircraft. The shader will splat areas from damage map with psudo-random glyphs of damage. This might look OK to pretty bad depending on textures. I'm quite keen to try this as I want to add such a system to give players some custom paint jobs reflecting game achievements/rank (such as earned 'shart teeth' and other hokey things).
     
    A similar shader is already present in LE version 2.40 for adding plaster-work to brick walls. Now 2.40 has some new commands for adjusting LOD ranges, we're almost goo to go to move the project to the new version of the engine.
     
    For now, keeping it simple works and I think the damage texture looks alright.
     
    Source
  16. Flexman
    The art-gnome at Combat-Helo has been playing with bloom and glow shader materials for the cockpit and came up with instrument night lighting. I thought it was a cool use of extra texture stages and materials with Leadwerks engine, it's an easy effect to add. With additional green point lights around the pit it should look pretty close to the real deal.
     


     
    Here's a real shot with night lighting. Panel back-lighting and small point lights.
     

     
    Source
  17. Flexman
    Remember the spinny radar thingy in Longbow 2? Scan sectors sizes and off-axis settings for the Longbow FCR (Fire Control Radar)? No?
     
    If you look at the heading tape of the screen-shot you'll see in the heading tape the "butt-cheeks" (two Ds back to back) on a heading of 225, off axis by 45 degrees. This indicates the direction the radar is pointing, as the FCR display is 'always up' in GTM mode. This can be a little disorientating and the radar footprint is mirrored on the TSD, this paints a clearer picture of where it's pointing. Failing that you can see the radome outside the aircraft turning as it seeks out the designated offset.
     
     



    (And why are all our aircraft IDs Z666? We shall never know. If you have a TrackIR and explore the cockpit nooks there's even a Clint Eastwood reference in it).
     
    Radar offset angle is set by clicking on either of the two LEFT RIGHT arrow buttons on the MPD or your designated sensor left/right control input when the FCR is your selected sensor. (If TADS is selected the sensor control steers TADS instead). NOTE: The offset can not be moved while the FCR is active, although you can queue movement by hitting the offset control then quickly cycling the FCR burst key. Got it?
     
    It will be in the manual. Promise.
     
    Vectors - all vectors, no bitmaps
     
    In the front seat, TEDAC view of the FCR

     
    Source
  18. Flexman
    Yes Panic.
     
    When you're rushing to get a reasonable build ready for hammering out problems I'm finding I'm making all new problems. Going over the HMD code I realise how badly it needs rebuilding, there are existing elements that need updating, a few new ones that require adding. There's no way to rebuild the HUD in time.
     
    Another problem. LUA in the Apache entity. Works in the first instance, but fails in subsequent entity spawns resulting in the inability to mount the aircraft. It's an issue relating to LUA accessing keys stored in the model. I want to rip out all the LUA code from models except for the model initialisation that puts on pylons and attaches the rotor models. Not much time to deal with that either.
     
    Dual Seat configuration.
     
     



    The interaction between front and rear seat was not well thought out early enough, instead I opted for a 'duality' where all features could be operated from either seat with just some interface differences. I should have opted for a strict seat A can do xxxx and seat B can only do yyyy. This was a mistake in my attempt to simplify control but ended up introducing more complex logic.
     
    It's not too late to undo this but a difficult process to start. If I have to design this game all over again I think I would probably nail down all of these problems from day one. Hindsight being wonderful.
     
    TrippleHead - lot more pixels to post process, looks great but a GPU strain
     
     



     



     
     

     
    Source
  19. Flexman
    Seem to be having performance issues with the new nVidia drivers 257.21
     
    I noticed the reported OpenGL version has done up from 3.2.0 to 3.3.0
    Repeated launching over an hour will sap the frame rate to around 1, yes one. No apparent memory leakage. But other games are fine. Also the editor will remain unaffected unless importing the Apache model where it will sometimes exhibit a black skin.
     
    So there's some combination of factors I need to understand, the current Apache model with it's recent material updates and animated wipers and the new nVidia drivers.
     
    I wouldn't mind so much except it's keeping me of adding new content right now.
     
    I also spawned an LE 2.32 build to test, which on a small map runs 50% faster, on the full sized Afghan theater it actually runs slower. I'm at the point where I'd like to take a shotgun to my PC. The laptop has almost double the performance of my desktop PC which makes no sense, same build, engine and 257.21 drivers.
     
    *sigh*
     
    Source
  20. Flexman
    Been pretty ill this last week, progress has been sporadic. I took time out to rebuild the engine code so it's now the same for all Apaches, AI and player alike.
     
    Pilot feedback from screen-shots and videos also allowed me to rebuild the whole engine start-up and ENG display page. Automatically switches to in-flight mode. Things blink, change colour, are boxed appropriately. Couple of bits left to do, the biggest headache was dealing with all the fiddly scale changes and adding new code to simulate power transfer which needs some attention. Here's the page with some values thrown in to show some extremes. The whole thing is worthy of a tutorial video sometime.
     

    Still have some parts to add to the engine simulation, oil, temp. Rotor speed and torque needs values from the new flight model to work properly but essentially it's just polling values from the helicopters state. Oh another thing I didn't put back in, the actual transient timers, these are counters that show how long you're flying outside of normal parameters which can shorten component life or lead to failure.
     
    The new alert system which I also had to overhaul is ready to drop the betty samples in en-mass.
     
    Will tidy this up tomorrow, look at where we are with the new flight model and see about the Leadwerks 2.40 engine upgrade. The PHY situation is not bad as I thought since we're not using LE for vehicle physics.
     
    Source
  21. Flexman
    David posted up some more CH47 pics around SimHQ and Facebook and possibly elsewhere. Lot of detail work has gone into the engines, rotor head and trying to get the smoothing correct at the rear of the aircraft.
     
    Looking forward to getting those blades turning, the sound thumping and the dust is flying.
     
    I've been doing a lot of logic work in the Apache in the past day or so. Also full of a head cold which tends to make me cranky.
     
    Sat in the cockpit, the APU sounds like a vacuum cleaner in the next room. Adding moving cockpit parts such as power levers, flashing lamp indicators and other one shot elements that require animation in a periodic update function suggests that maybe it would be better to place all of these things in something more general purpose.
     
    Rather than having a spider-web of update calls, updateCockpit, updateUnitWaypoints, updateEventTrigger etc. popping a function onto a stack when it's needed seems like the thing to do.
     
    I'm proposing to add a simple event system that can take an entity and perform a chain of moves, rotations, material or colour changes, and remove from the stack when the sequence is completed or removed. Then augment this to perform function calls for mission events, to be fired as offsets from mission start time or absolute world time.
     
    Initial thoughts suggest something like the following would cover most needed cases:

    eventID = EntityID, action, blend, userdata (e.g material, colour, vector) as csv eventSequence = ID, eventID[], deltatime_ms, cycle_ms, repeat_count, start-time_ms (absolute world time or zero for mission start time) Where a sequence to cycle a material between two states would need two eventID entries, one for each material and the entity to apply this to. And the eventSequence would contain the reference to both eventIDs. It's then up to the eventProcessor to handle the action. Which could also be SetKey() or SendMessage() but it should be generic enough to handle a lot of common situations.
     
    Event is performed [repeat_count] times, a value of zero implies loop. [cycle_ms] is time between each repeat cycle in milliseconds.
     
    Some checks may be required before injecting an even into the eventSequence. To prevent duplication, for example, hitting reload to trigger a reload animation repeatedly would have the effect of triggering the animation to play before the previous playback has ended. Therefore a parameter to test the uniqueness of the eventSequenceID before pushing it onto the stack should suffice.
     
    **edit: some of this doesn't make sense, seems it got screwed up in posting. Text has been mistaken for tags.**
     
    Source
  22. Flexman
    It's not going to win any awards for realism but we have a rudimentary ENV environment class that handles time-of-day ticking and updating scene elements accordingly. Lighting, colouring, fog, sun position. Currently it's using computed light values which renders lovely post apocalyptic scenes, the colours are terrible IMO, looks like a nuke's gone off. A lookup table will be better and an exercise I'll leave for later. Also I added some data structures for moving weather zones around the map. These are trigger zones for adjusting fog density as you penetrate. To be used for any spot environmental effects we want to add, dust-storms, rain.
     
    Not clear how best to add the gradient data, the old Combat Helo code used a tiny 64x64 bmp. Can't seem to find the graphic I used.
     
    In the remote chance I get to implement "Megaparticles" (looks around for Shader X book) the skies would benefit from 3D looking clouds. Value vs. performance. Helicopters on our battlefield won't be spending much time at altitude and we're not a fighter sim. We can manage some rudimentary clouds but I'd avoid using particles. Fill rate costs are not worth it. Which leaves billboarding and textured planes which are cheap to render.
     
    iPhone development picked up a pace. With access to my big box of assets, Dormouse (lead dev on that project) was showing me how to fly a Sophwith Camel around with nice springy 3D person camera moves and the base skybox I just made for CombatHelo. Nice little exercise to explore what we can do with Unity iPhone. Some rudimentary shaders, OpenGL and javascript. From what I've been seeing, it's not that far removed from LUA scripting in Leadwerks although I find the way Leadwerks interacts with entities more intuitive.
     
    Dave, part man-part frame-buffer, tackled craters and we had the problem of blending them with the terrain, especially when we have massive z-buffer artifacts with co-planer polys near the outer-regions of the map. Leadwerks nice built-in library of shaders proivded the answer. Using a terrain hugging vertex shader, the crater morphs to fit, and the frag shader does a reasonable job of blending in the base texture to the terrain.
     
    And we have a new concrete bridge for Herat. The region map has been a work in progress for close to three months now. All the compounds, village buildings, structures number approx 502 with the airbase and the city of Herat yet to complete.
     
    It's a massive region on foot, and takes a while to fly across. Navigation is a bit of a problem, I hope to fix that with a pop-up map if I can work out how to blend the different map layers from the terrain buffers to make something readable. Otherwise it's going to have to be another pre-loaded DDS texture with enough resolution to zoom in.
     
    Here's more of my least favourite colour in games. Brown.
     

     
    Source
×
×
  • Create New...