Merry Christmas Everyone

Back again to say have a Merry Christmas.

We'll be back to work in the new year, I'm taking time off to dedicate myself to the family. Snow has arrived again, and it's looking to be bitterly cold. Time to get in the egg nog, cheap supermarket port and stale cheese biscuits. Have fun y'all.

Replica WAH-64D control update

Rich at Komodo Simulations has a new design for the replica Apache controls which should be more accurate. If you've missed the discussion thread then see this.

Komodo manufacture replica helicopter control systems, seats and joysticks.

Weekend expression.

First weekend on the run-up to the holiday season.

Two things happened, first, I unboxed SSX Tricky for the Playstation 2 and lament that there hasn't been a hi-def remix for the current-gen consoles. It's still a brash, loud and stupidly over the top game. Great fun to pick up and play. While playing it, it was easy to forget everything else that follows.

The second thing...well that's everything else. I've had to deal with money matters, lawyers, game design issues and job interviews. All in one week. Granted I've not had a job interview in years for a game programming position, usually it's pitching for work and never had to express myself or my skills. Being English, (and a Yorkshireman) I tend to undersell. Dave who;s been working hard on the 3D art will say I'm the king of understatement, produce wonders and brush it off as nothing at all. Sometimes nothing at all can look wondrous.

A dear old chum from the 404th squadron (Stingray) had some helpful advice on IP law in the US. I can't discuss specifics (by co-incidence I was also contacted by a freelance journalist working on story about simulation and intellectual property) but he looked into issues surrounding the use of military aircraft, paid for by tax-payers, and the use of images and names of publicly funded hardware in video games.

Do you need to license such things? His analysis was most entertaining but he summed it up in two words, a "definite maybe". I love lawyer speak.

Meanwhile my oldest brother is in hospital pumped full of morphine, his liver cancer presumably catching up ready to take what's left of him and I'm unable to do anything about that except blog. Except I can't do it at the hospital as to use wi-fi services there patients must pay extortionate amounts to large telecoms. Everywhere you look a corporate entity is trying to suck money out of you while you fight for life. Vending machines, the privately run car-park outside, wi-fi. All of these things that surround you in these places are stupidly expensive. Don't get sick.

My wife is currently preparing food for hungry musicians at the local centre, it's all she can do to give something back to the community. I wonder what it would take to install free wi-fi in hospitals? And how much red-tape you'd need to cross just to get equipment in the building. I think I just found a new mission in life.

Coloured particle shadows

Just added coloured shadows to the rotor downwash/duster effect. It's a feature added to Leadwerks Engine when it added support for pureLight. It does require something of a beefy graphics card to render real-time smoke shadows. It certainly adds to the scene, some artefacts appear at some ranges from the shadow map. Need to investigate that.

A small problem emerges with the CH47, the helicopters are one way "portals", inside and the outside view is rendered around you seperate from the internal view. This way enviromental objects such as smoke do not intrude into the crew space. However we don't do the inverse, the CH47 has a large open cargo door at the rear. For performance we don't portalise aircraft interiors when the observer is located outside. To fix it, one option might be to insert a mask for cockpit/cargo areas into the foreground world. A simple cube/shape that matches the internal dimensions of a vehicle rendered in the foreground world maybe? On the whole it's only noticeable when looking up close from the rear. I wonder if it's worth the time and trouble.

*edit* btw these are test objects in the editor simply used for checking the materials, scripts and lighting. Also the new SSAA screen-space anti-alias is being used.

Story arcs - content made interesting

A recent query on the SimHQ forums prompted a quick appraisal of scripted content. I originally only penned one opening story to be recorded for use in trailers and/or training mission at the start. We don't have the  resources to do much more than that, and I'm not really sure more is needed (it would be nice to have more but gamers are smart and like to push in their own direction).

As the campaign is mostly dynamic there isn't much mission building needed. To break up the mission variety we came up with some simple to implement content. There's the 'deck of cards' intel-collection quest, ambient quests (short versions of campaign engine generated sorties collected whilst flying) and some scripted missions just like Longbow 2.

The deck of cards content is reasonably easy to assemble. The scripted mission content requires more of a story telling flair and using text with some recorded speech in some places we can embellish the hand crafted missions. I have a number of characters, some re-used from the opening introduction.

I'm assembling story arc ideas for the future. Cyclic has volunteered to play a British SAS officer and associate (I hope Druid will come and play too). I get to play a bad guy.

We have some content ideas I want to flesh out for the following characters...

- The "We Care" charity worker (female role)
- Italian liaison officer (no stereotypes please, Herat is transferring from Italian control at start of game)
- US Photographer
- Brit reporter

As much as I'd LOVE to include the Bermuda short wearing Camp Stone CO practising his golf drive out the back of a Chinook, it requires dedicated rigging and animation, things we can't do right now. So we need to keep it simple, limited to things that can be expressed as dialogue and moving vehicles.

Little update on FFD and other things

Just wanted to clarify what's happening with regard to Combat-Helo atm.

The game is currently undergoing a little restructuring while it's updated to use the new version of the 3D Engine (Leadwerks). New input routines to support easier swapping of controllers, campaign data, networking has been tweaked for the dual-seat / peer to peer comms.

Fred, developer of FFD (Free Flight Dynamics engine) has been working on *new* version of his elegant blade theory simulation and is about 90% complete. Then it has to be ported to C++, the Combat-Helo implementation was parked until this is complete and then we'll look into how best interface it. I really love how FFD works, it's quite different to everything else I've seen and adaptable for any kind of vehicle that is a collection of complex forces.

I received the first processed APU audio and quite pleased with that. No time to slot it into the game yet. One feature I'd like to use from OpenAL is doppler shift, oddly missing from the LE implementation as far as I can tell. And now I have a need to queue sounds on a TSource and finding that feature lacking here too. Might have to use my own OpenAL implementation if I can't mix OpenAL API calls with LE OpenAL buffers.

I've been Flipfaced

I've been Flipfaced, little plug for the artist.
http://flipface.me/

Mi-24v Tiger and InputMapper mk 2

Came across a DVD of the Royal International Air Tattoo 2006, a Czech Republic Mi-24V Hind (number 7353?) from the 231 Attack Helicopter Squadron had a camera strapped to the pylon. I've walked around a few Mi-24Ds at airshows but nothing as lovely as the tiger paint scheme on this one.

I'll just share a few images I grabbed.

The last image was taken by "Vojta_micek" (see his other photos here). Elements of the tandem cockpit appear modernised from what I remember. The all black theme

The Mi-24 is a fast twin engined helicopter, > 200 miles per hour. Versatile, with a small troop compartment/load area and large number of wing payload configurations.


Programming wise I've been re-engineering a lot of game internals to separate them more from the underlying 3D engine. And today that included an alternative input system. Short of using DirectX (which I have problems compiling under MinGW) there isn't a great solution for now. The SDL library falls short since it uses the Windows MMSYSTEM which only handles a few axis (6) and 32 buttons. It manages about 3/4qtrs of the axis and buttons on a new Saitek HOTAS PC joystick.

Ideally I'd use RAWHID which is a method Microsoft provide to read the raw data from any USB input device (there's a Linux library too). RAWHID would cover some exotic input devices, 3D navigators and touch devices for example but that will have to wait till version 2.0. For now I'm abstracting the input handling too, nearly finished with that.

Till now input configuration has been awkward, I wrote a quick and dirty config system last December. The cross-platform input library didn't even return a sensible name for a device on each, it was just a port number, if you unplugged or swapped them around you'd loose your input mapping. Terrible.

Now we have curve options, inversion, min/max range and device ID pulled from the Windows registry. An input monitor overlay with graph was added to help debug and test axis response. If anyone knows of a RAWHID multiplatform lib then please drop me a note.

Campaigns part 2

My previous field of work was the fascinating world of Risk Assessment. Software that monitored incidents, identified key risks and trends. It's been used as evidence in court cases and SOX Sarbanes-Oxley 404 (I kid you not) compliant. This work gave me an understanding of visualising trends and the mathematics of risk and game theory. (Moving on, William Boyd style)

One of the early games I worked on was a little ZX Spectrum number in the 80s, I did the all singing, all dancing Amstrad CPC and Memotech (unreleased) conversions of Next War. Next War was originally a very complex mathematical board game with hundreds of easy to loose cardboard counters, maps of the Fulda Gap East West Germany region, rule books and curved graphs that covered every kind of engagement you could think of. It's a rare game to track down but here's a picture I stole from a collectors site...

The Next War - extreme 80s board game

Cramming that into 48k was a challenge, indeed it couldn't be done on the 64k Amstrad without paging memory so it ended up as an early 'floppy disc' enhanced game or 128k model. Still surprisingly playable and I have a Blitz version half-written somewhere.

Over the months when I've sat down to sketch how Combat-Helo was going to work as a game, we knew what the conflict was going to be, the scope, how it would evolve and who the participants were. It had to be smart, never quite the same game twice. Also it had to retain the charm of the old 90's combat simulations, have a seemingly simplistic scope but at the heart would be a hidden educational agenda.

War is something that is hard to understand. Seemingly incomprehensible and I don't, (I hope I don't) make light or trivialise it in any way. What do scientists do when they don't understand something? Well, quite often they make a chart from data.

My hidden agenda with Combat-Helo circa 2002 was an accurate number crunching simulation of resources vs. the mission (originally for the Basra insurgency at that time). The mathematics of war is an interesting topic that's become better understood with the availability of information, modelling and work done by scientists like Sean Gourley (Oxford Physicist) from whom I borrowed some concepts for Combat-Helo Operation Ouroboros.

Using methods of data filtering Gourley's team identified wars/conflicts have distinct signatures from which you can make predictions. (See Telegraph article). Start by simply plotting size of attack against frequency.  This line is also found in areas of Risk Analysis. These lines often comply with something known as "Power Law". Here's a graph stolen from Wikipedia.

Many natural and man-made incidents follow this power-law. Earthquakes are quite common but only a few are devestating, power-cut disruption vs population, size of craters on the moon and even the player rankings of any Call-of-Duty game. Players wanting to rank high require early adoption, more so in a hit based market, over time you'll end up in the same place regardless of game. It's one of natures rules. It wouldn't surprise me if Activision sales of these games followed the same trend, and an incentive to hike the price. This is something  suggested by recent pre-order sales boasts at Activision-Blizzard.

Insurgency and terrorism follow the same curve. With a few deadly events causing catastrophic damage with many smaller acts carried through. Military planning in the real world can use this to predict the frequency of the next big attack, this is something you'll experience in Combat-Helo. By changing the slope (a polynomial expression) we can change the level of insurgency around the map, and the slope can be altered by many factors which you can influence while in the air or your skills at planning in the command tent. Not only can this be applied to COIN ops (pun partially intended) but also armoured and open warfare.

Equation that predicts likelihood of an attack

What you'll have is a reasonably realistic level of enemy activity regardless of scale.

Campaigns

This is going pretty well, planning and preparation over the months is paying off. If anything it's going too quickly as I find myself needing the games built-in editor sooner rather than later. I'm building this directly into the LE2.40 build to save time.

All your FARPS are belong to us.

Rather than have a basic game object "FARP" (Forward Arming and Refueling Point) we have "BASE" object of variable types. The structures for the base are made in the same way they are for mobile units, a list of objects expressed as offsets and rotations relative to the base location.

This is all stored in an easy to read and edit XML format.


Campaign stucture is currently set as follows:

• Campaign descriptor, name, date-time start, text description
• Terrain map filename, lat and lon of mid-point.
• Faction list, text names, ID (Civilian = 0, US = 1, etc)
• Base list, name, ID, position, supply data, faction
• Base object list (optional)
• Unit list, faction, postiion, name, visibility
• Initial waypoints if any
• Trigger conditions
• Zones
• Villages, names, faction control, population, security level, intel quality, contested flags
• Family tree data
• Object list (optional)
• Map Markings, text labels, symbols, lines

That might give you a little insight into the 'firefighting' aspect of the "A-Side" campaign. There will be additional data to add later relating to consumables. For example, hard hit zones will be 'up for grabs' and require urgent re-supply or risk loosing ground in that zone. With limited supply levels and resources you will have to do what you can to can.

Having to hand-code some of this data atm just to get the loader and data set-up. More later.

Engine upgrade progress

With a new PC build comes new responsibility.

Well, a new Intel i7 Quad Core running at ludicrous speed with an nVidia 460GTX (Palit) seems to shift millions of triangles without blinking. Certainly astonishing to see Combat-Helo over the city with all effects and TADS running at near fps cap (60hz) and only 20% CPU usage. Let the hand-brake off and it was soaring into the 90s and beginning to overheat.

It will shut down the card if left, so I'm having to find ways of throttling it. I think Star Trek Online had these issues too. Oddly, it only happens with the large map, and not the smaller test maps.

I've enlisted the help of gDEbugger, a handy tool that lets you 'freeze' and step through OpenGL programs, inspect states, frag programs (and recompile during execution), stats on state changes, bottlenecks, frame graphs, VBO composition, loaded textures and much more. I only have the trial version so it's a bit limited, so far it hasn't shed any light of the matter of the driver crashing (I assumed this was related to bad DDS files). I'm thinking there's some hardware fault on this card or a current nVidia driver problem with OpenGL4.0 cards. I'll continue to monitor, it doesn't seem to effect the other lesser computers I've been testing with.

I built simple test program in C++ and BMax to load in just the terrain (no objects) and that's all it need to crash the new build.

Lord of the Rings Online is now free to play in Europe and supports DX11 which is breathtaking with it's water effects. No other crashes except with the LE loaded map (editor loads and runs no problem). I hate these issues.


Apart from that, I've parked the cubic splines this week and have been continuing the slight re-structuring Combat-Helo to use Leadwerks 2.4, making it more modular as I go. I started last week with the new cockpit data and rolled that into one aircraft XML file.

Now I have a lot of quality audio from the airbase, it has me thinking about ways to integrate that to the avionics and helicopter classes. Trying to separate as much as I can from engine specifics to ease future portability to different rendering engines if needed. All of the instrumentation is just OpenGL, come this time next year I don't know if version 2.0 of combat-helo will be using Leadwerks 3.0 or something better suited to streaming larger terrains. But I don't want to loose the speed either. The Leadwerks 3.0 roadmap suggests great things might be possible if paged terrains can be streamed in as tiles that can be translated (for camera relative rendering). Speed and accuracy, having parts of buildings flicker slightly won't be acceptable to me in a second generation title.

For research purposes I downloaded a 3.5GB heightmap for the whole earth and parked that on my external project storage (a big cube that hums in the house, all lonesome, if only I could make it produce the eerie choir music from 2001 A Space Odyssey).

Looking through more jobs today, noticed Rockstar has opened a new office up in Edinburgh. I love that city, bloody cold but fabulous place to hang around...except for the local branch of Dixons.

AH64 sound recording

Thanks Recklezz for the stunning audio recording at Gilze-Rijen air force base. It's certainly going to transform the cockpit experience. Certainly loud too. My wife often comments, "Can't you make a less annoying game?"

A Zoom H4n, (product web page) is a mini portable recording studio capable of 24bit 96Hz and the results we're impressive. The audio will need some cleaning up, normalising to compensate for variable levels, the conditions for recording as you might imagine were less than ideal. If you need a portable audio recording solution for exterior or interior / voice work then this unit comes recommended.

Maybe Recklezz and Drummer will post a little more about their experiences with the full sized Apache simulator if you ask nicely :)

They have earned a place in the Combat-Helo hall of thanks. Cheers chaps.

Fingers crossed for good weather on Tuesday

Fingers crossed the weather is not too bad tomorrow at Gilze-Rijen air force base. Our man in the Netherlands is prepared for a day of audio recording for the Apache and Chinook.

Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat' :)

To facilitate new vehicles and multiplayer

In the process of sweeping changes to how the game loads vehicles and other data. A lot of data the describes how the virtual cockpit works, where you sit, angles of views etc. was not available early on and since my long term plan is a system in which we can serve you new vehicles down the wire, even adding the Chinook was going to need a bit of fiddling around. Some data was in the object LUA, some in an external file, some embedded. It wasn't the original intention to build vehicles this way, but it was expedient at the time.

Now it's time to put things right and make a nice neat all-in-one package that's flexible (after all that is my middle name).

Another thing I wanted to do was allow the ability to tie entities to simulation variables, so a cockpit altimeter needle can be assigned to the vehicle.baroaltitude parameter. Hey does any of this sound familiar? If it does then you've done aircraft/gauge development for Microsoft FSX. While this isn't anywhere as deep, it's enough for us to be able to bundle new helicopters and even ground vehicles later on. I'll publish a list of available parameters later when I know the scope myself. MPDs and HUDs can be copied to specified entities using the name of the glass instrument output and the name of the surface you want it displayed on.


* edit*
This is pretty neat, I've now added a bit more flexibility to what we can do with the cockpit inputs. Each individual switch position may now have a delay (hold at this position n seconds before firing) and fire an additional command at that position.

* end edit*




The FFD (dynamics) data could be added too to describe how it flies/drives, that's to be look at later.

There's still a quantity of code required to determine message priority, client/server authority. but at some future time if we want to add "user roles" as a message filter to any control, this is flexible enough for us to drop that in and not rely so much on coded game logic. Filtration and authority of incoming messages are important for multi-crew vehicles in multiplayer, you need to be as lean as possible (I bake state flags into bit fields as much as practical). Not all switches need to be recorded or sent, some are vital (crew helmet positions need fast updates for the HUD and sensors), some (wipers/lights) can be delayed.

The "command" string in the cockpit switch data is sent to the messaging system, if it's a network level command it's forwarded to any needed clients via Raknet.

As our vehicles are 'portals' there isn't much physics going on for attached crews. As a gunner, your helo position comes from the pilot and interpolated, your sensor position is based this, and that in turn is relayed back to the pilot. So there is room for some weirdness but not too much I hope. The way the Apache works actually works in our favour. Since each weapon system has a designated 'crew in command', the game logic knows who's the shooter and the positional data from the client in authority is used. And if you're not targeting a visible entity (e.g tank) then you're aiming at an invisible one (a pivot). This reduces oddities caused by differences of position reported by actual and interpolated crew positions.

More HUD config options

Completed changes to the HUD section of the config file.
<HUD col="1.0, 0.8, 0.2" glow="0" shadow="1" breakoutfpi="1" />

I'm using the TinyXML lib for config functions, it's been fast efficient and easy to use. I added a new option today that was born out of looking at videos of games projected onto huge screens giving almost 1:1 scale. Before my tripplehead PC went pop I had a problem with virtual symbology relative to HUD size. The larger the screen, the smaller the HUD relatively. At it's worst, the effect was looking through a keyhole.

So I removed the keyhole, the "breakout" option in the HUD config will plot some indicators outside the HMD area and in a relative scale to the screen size. This makes it more useful at the expense of not being totally accurate, hence the option.

In the screenshot below  you'll note the user colour option for the HUD symbology in effect alongside the flightpath indicator outside the HUD buffer (right of the altitude bar in the hilly bits). This is easier to use on a laptop too where screens are not as bright and it's easier to pick up.

There's been an intermittent windows exception error when launching the game (release build). I tracked this down to the old controller config loading which uses IO streams to pull in a data-file. Something is going on there. I need to re-do the controller settings anyway using XML to store response curves and other tweaks you can't do right now. Just a pain as laptop drives are a touch on the slow side.

*update*

Symbology broken out of the HUD now match HUD blend FX. Corrected screen ratio. Adjusted pop-up scales and distances. Added config option to turn off HUD mode text (on by default). Continuing adding more map glyphs. Spent a little time just flying around. Found a bunch of weapon symbology already in the HUD code which I had totally forgotten about.

Tuesday - map almost completed

Spent a lot of time today house cleaning. No not code, literally the house. It's amazing what teenagers can do to your treasured Monty Python DVD collection, it's not funny. Stop that, it's silly.

I over-complicated the map drawing and stripped it down. Added functionality to the TSD page for controlling the map scale. I'm happy that it will work with 3rd party maps too. Oh I just noticed in the screen shots the scale index is off by one.

The green colour is from the low elevation range but I blend some of the terrain colour too which I should perhaps leave out since it gives a false impression. I'll add a button on the page to cycle map modes rather than have to go through a sub page perhaps. Otherwise it might get (more?) confusing. Hey, Longbow 2 had one button to cycle through NAV/ATK and BOTH....and no map unless you flew the Kiowa (I think).

So tonight I'll add the aircraft datum (the helo symbol on the map focal or point of rotation) and begin adding the glyphs for the waypoints and other symbols that we want to appear on the map. Should finish adding the waypoint data while I'm at it (ETA etc). I can't work out endurance time yet as the fuel data isn't yet present. It varies with payload and altitude, there's a table in the A model dash-10.

Would like to have an elegant algorithm to approximate it.

Tweaked the map levels to balance the contrast more...you're more interested in the symbology not the lumpy bits.

* update*

Adding more functions to the TSD, hand entering the vertices for each glyph (symbol) that will appear for various things. Dave updated my track texture so they are 'slightly' easier to spot but I think I'll have to think about reading road data and plotting it to the 'master map buffer' that's processed during game initialisation.

Need my TrackIR and (crumbling) pro-clip to get up close to see the detail properly.

* edit *

Another pic to show a bit more clearly the pit self-shadow which is not always obvious due to the shielded nature of the pit and my default sun position.

Also has experimental new baked AO on instruments.

Pit self-shadows indeed

AO work on the side panels, more subtle

Showing the new vector improvements on the ENG page

Vector font tweaks and HSI

Working on the tactical situation display elements, the vector font output was never quite as crisp as I'd hoped for but that's now fixed by keeping the 1:1 scale and changing the ortho projection matrix. Bigger works better than smaller when it comes to float accuracy with consumer level drivers that focus on games and performance I guess.

Still have the map scale to do, that's forming part of the mission terminal code. But the rest of the TSD is coming together. I need to put an upper limit on symbols otherwise some numpty crews might get a bit happy adding symbols to spell rude words or add smiley faces to the map.

Added a basic HSI rose function and added that to the TSD NAV mode. Everything seems to mask OK. Only issue so far is the pop-up repeaters, they are currently too dim/dark, see second image below.

You can see the vector fonts are much better defined in the above image even though it's a bit feint (and oversized for the window res I use on my laptop).

So far, the Apache avionics suite includes a basic navigation system, 5 radios, two almost complete HMD modes and a tactical system in progress. It's actually getting pretty fun to fly around now, some bugs notwithstanding. View system could use some love as well as the stabiliator to stop the nose-down pitching.

*update*

Dave made a new reflection map today which works much better I think.

It's probably a good idea to make a function to create these maps.

TSD started, avoiding work for a Split Second

Another little progress update but first a diversion. Yesterday I took some time-off to brush up on gaming skills and really enjoyed Disney Interactive's "Split Second", one of the few car games I keep going back to since I typically find racing games tedious (lack of skill and patience on my part). However this game is almost pure adrenaline and I find my self coming back to try and shave off 2 seconds while avoiding exploding aircraft and collapsing control towers. Split Second is actually the perfect arcade car game IMO and probably much overlooked in a busy genre. It screams for a post race replay option though.

Enough digression. Not much to show yet as I've only spent an hour or two on it this morning, I hadn't put in the VR cockpit data for the TSD buttons so went and put that data in. Had some color issues down to a mix of LE and OpenGL and sorted out the MPD scale for rendering the currently loaded nav map image.

TSD stands for Tactical Situation Display

It is the most complicated system in the helicopter. Which I will strip down to the bone for the first release otherwise I'll be at it for months. The TSD presents a 'Gods eye' view of your helicopter and your environment. Downloaded target information, friendly unit sightings, route navigation and more is presented here. It is a moving map system that can be frozen, panned and scaled.

I need to slim it down into something manageable. Also there are many functions that are desirable to use in the command HQ tent planner and also other helos in future.

Our TSD will feature

• Fire zones (aka PFZs, old school but everyone will want them)
• Route editing
• Threat, target and hazard objects
• Nav and Attack mode (PHASE)
• Freeze, panning, zoom
• Crewman cursor acquisition, click on map and point will be made virtual in the helmet display.

So there's a few things to do but also shared with the ground planning system on the HQ tent computer.

For the base map, it's using the TTerrain() object on the loaded terrain entity (I needed to cast it to get access to the height and normal map data otherwise it's considered a TEntity). A shader converts the normal map into an intensity multiplier ( float intensity = dot( normal , lightdir ) ) for the colourmap, multiply the diffuse and intensity and voila you get a shaded relief map just like the one in the Leadwerks editor (except I don't need the realtime light position and colour that the editor uses).

To this I'll add a colour lookup table from the heightmap and possible some contour lines. I've not used an "lut" function (look up table) in a shader yet so it will be a fun little exercise. Contour lines could be done by setting output colour if the heightmap value is a multiple of 10 (meters) or whatever value I pass to the shader. This just colours the pixel if the value is in that multiple, steep terrain might bypass that value so results will be a bit patchy depending on the source data. I'll look into a proper contour function.

Keep in mind the heightmap in terrain doesn't have a flipped y axis.

* edit *

Elevation bands added to map shader, can be turned on/off. Should be easy to throw in current altitude and have all points above in red. Probably tone down the shading a bit. Need to add masking to my MPD curvedbox function.

* update 2*

Need to clean up the vector font a bit to make it more crisp (tidy work), looks fine on a laptop screen though. I added the backfill to the MPD drawing functions, added a basic waypoint display and most of the buttons I'm going to use except for the scale selection (top right).

This is the NAV mode (toggle between NAV and Combat mode using the PHASE button).

Buttons on right are: CTR, FRZ, CAQ
These are CTR=CENTRE to toggle map centering, otherwise it rotates around your aircraft in the bottom 3rd.
FRZ to hold the map position update so you can pan (when I add that).
CAQ to take the next "MPD ACTION" input and set that as a Pilot or CPG marker the crew can use to say where to go or visualise a situation. The point will be displayed in the HMD virtually.

Buttons at the bottom are: PHASE, BAM, MAP, RTE and POINT

PHASE cycles the TSD modes
BAM is for input of PFZs/NFZs
MAP is for changing of map types (user maps and contour/elevation modes)
RTE is route selection (editing, waypoints since we only support one route)
POINT to allow crewmembers to insert/edit symbols into the nav system (control points, hazards)

A function to send aircraft nav data to other flights and HQ will be provided.

Static reflections or cubmapping

I was looking at the problem of glass again, reflections for cockpit instruments and improving the canopy and TADS optics. FSX manages to do so much with so little (a small 128x128 DDS) for shiny metal parts, such as chrome props it was time to look at adding cube mapping again.

I know this has been added to Leadwerks 2.40 but the corona problem doesn't seem to be fixed yet. Retro-fitting cube-maps to 2.31 is an easy task and the river mesh material was updated (we don't use the single height infinite plane as it doesn't work with real-world topography). As water goes it's not fancy, real-time reflection and surface animation for high-speed machines during the polish end-phase. River surface cube-mapping matches the environment lighting and thus provides a simple and economic effect. There's only one river that runs east-west.

Shiny chrome parts and subtle glass reflections should be trivial to add (when I get the alpha component sorted out).


*update*

Reflection base layer

Composite reflection and diffuse

Working a little more on the glass shader for the canopy, they need to have transparency and their diffuse layers blended together but I got rid of some problems with normals at certain light positions for the base reflection layer.


* update 2 *

Tummy flu today. Children do love to bring things home from school. Sitting in bed and working out how to add maps to the moving map display (and by extension the camp mission editor) Josh at Leadwerks was kind to provide insight into how his engines terrain editor created the composite view which was very nice of him.

Didn't take long to implement and have the new TSD class in-game render the loaded map ready to use as an underlay for symbology. It would be nice to switch to sat images or aviation maps but those things need licensing. What I'll do is leave the option for users to add their own maps as layers.

Theater map, sans objects, symbology and veg atm.

Major features are the mountain passes, the river running east/west where the main green zone runs.

More HUD readability

First of all, a sincere thanks for the feedback. It's not something to get too hung up about and it's easy to get the idea that we spend hours and hours on making HUDs pretty colours without getting anything else done. Yesterday was pretty intensive in terms of tweaks and adjustments to the HUD but not just in terms of colours.

We've added clipping regions (using glScissor() ) so items like the pitch ladder no longer intrude into areas it shouldn't, this declutters and improves overall readability. Also the acceleration cues are no longer available on the CRUISE mode symbology, again reducing clutter.

And the biggest headache which I'll come to in detail has been the flight path vector, that little circle with the stokes at  3, 9 and 12 o'clock. It presented a problem I hadn't anticipated. It's also difficult to explain but I'll try and sum it up.

The idea is that the FPV is drawn in the the direction you're moving, so if you are moving directly forwards it's in front of you. If you are performing a perfect sideways slip to the left, if you turned your head to look along your left shoulder you would see the marker in front of you.

The HMD or HUD represents a 30x40 degree field of view. However, the default field of view for the main 3D view at a resolution of 1024x768 is 90 degrees. The HUDs default scale is 512x512 and would need to map virtual symbols to a 45 degree field of view (512 being half of this example full screen resolution).

Now, if you have a much larger screen resolution, say with a super-wide monitor, or tripplehead (worst case) you're horizontal resolution can be around 3840 pixels across, the game FOV might be 120' and therefore to match the 3D world, the HUD symbology has a field of view as little as 16 degrees. That's tiny.

The result would have the flight path marker moving the HUD really quickly since it covers a smaller relative area. This would suck if you really needed it.

You can't scale the HUD to match the screen resolution as you loose the top and bottom off the screen. Well, answers on a postcard please. Chewing this one over.

Improving HUD readability

HUDs often used in simulators adopt a green hue and use an additive or alpha blend. It can be hard to read them in some conditions and this is something I was thinking about so I tried a few experiments, non of which I like fully.

First: To improving readability of heads up displays by down-sampling the HUD buffer to a smaller buffer (I called the hud_fx_buffer) with a texture filter, a poor-mans blur. Using the resulting 'fuzzy' version to reduce the intensity level of the background image.

Has potential, reduce the resolution of the hud_fx_buffer too much and you get a darkend 'strobe' effect around the symbology which is akin to what you see on video tapes. It think with a Gaussian blur effect and a higher res buffer it might be a winner.

Second experiment, the ubiquitous drop-shadow.

Yuck. Looks like a drop-shadow. It's the same down-sampled hud buffer with a small offset. It works though, can clearly see the symbology against the lighter parts of the horizon without resorting to 'orange' or black.

The hud 'clarity' will remain a user option, off by default.

*update*

One last toy, a twinkly hud glow. This is actually quite pretty in motion and again reminded me of some old HUD tape footage shot in old Jaguar aircraft.

Good for simulating what it's like to have certain eye-conditions. Another one for the cutting-room floor.

Finally, below we have hud glow mk2,  a more subtle variation which is just a glow applied, mipmaps help soften out the hud image.

Bank angle tweak

Green-hue drop-shadow with glow

Green drop-shadow with glow (max intensity)

Green drop-shadow no glow (good for projectors)

Virtual Waypoint Marker

The HMD of the new MTADS Apache comes with a number of 'virtual' items displayed to the pilot. The currently selected waypoint is made virtual in cruise and tranistion modes, the waypoint position is marked with a flat bottomed diamond with a dot in the centre. See the take-off point (W00) on the image below.

Flying with the flight path marker inside this symbol and you should head right to that spot.

Waypoint marker

*update*

Corrected scale of altitude readout, flight path vector no longer Russian (removed aircraft roll) and repositioned barometric altimeter to the TOP of the alt scale where it should be.