Friday 29 October 2010

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 26 October 2010

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

Monday 25 October 2010

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.

Saturday 23 October 2010

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.

Wednesday 20 October 2010

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.

Wednesday 13 October 2010

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.

Monday 11 October 2010

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)


Friday 8 October 2010

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.


Gamenavigator (ru) press

Thanks to "GrViper", bit of Russian press coverage courtesy of "Game Navigator". I think I like the intro about raining  fire and brimestone? I had to have a Russian friend in Siberia read it out to me over Teamspeak after which he asked, "so you're interested in flight simulation then?" 


Work update

Last night I added the waypoint/navigation system which is rudimentary but has the needed functions for other bits of code to insert them into an aircrafts avionics. It's a linked list with some methods for management and selection.  Once the HMD and MFD gets the steering cues for the current waypoint it should make it easier to navigate around our game theater.

Also I worked on the flight path vector which is a little confusing since it's 'virtualised' in the helmet sight (adopts real world position regardless of your head rotation), but the artifical horizon is not.

How *I* currently made it work (which is slightly different from how it will finish) is a magnitude of vertical speed and horizontal displacement (sideslip) which is how I think it works in a 2D format for MPDs (the little square screens in the cockpit). For the HMD virtualised mode it's a matter of using angular velocities (HeloBodyOmega) to estimate where the nose is going to be in 3D space and add the pilots view position and rotation. 

Fred put it more simply, offset from nose = angular velocity * coefficient etc. Well the devil is in the detail :) working out what the etc. is and doing it in the right order.

Flight path vector - circled

Nav symbology will be done today. I'd like to thank Toshiba for the Qosmio X300, the most ugly laptop ever made but certainly a powerful machine.

Wednesday 6 October 2010

Little update on work - flight model mk2

Spending time working on my laptop here, which now has some reliable memory from Kingston has proved to be a fantastic little work platform for developing with Leadwerks.

The FFD or Free flight dynamics physics engine is still a little rough around the edges for putting into Combat-Helo proper so I'm working on a small test platform which hooks into the Leadwerks entity update callback and calls the FFD update.

I'm not sure if this is a good method of doing it, FFD is just a flight model and doesn't handle ground collisions. Originally intended for Microsoft Flight Simulator it releases control when the object is on the ground. Which serves me well, switching over to Newton physics at that point.

I've been going through correcting some type assignments and now the FFD engine seems to be working except for some unexplained force in one direction so I'll have to go through it with Fred and see if we can't find out what's up with that.

Thanks for all the offers and suggestions with regard to my dead motherboard (it truly was gone).

Saturday 2 October 2010

Not a good sign - drive IO failiure


Another disaster strikes, PC wont boot at all. Strange thing happens on the BIOS screen, the moment any attempt to detect any drives (and I tried a few different drives that I know were fine), a bright underscore character appears under the circled comma (picture above).

So apart from my laptop I'm now without a working PC and no means to fix it atm :/


*update*

HDD controller on the board seems to be kaput. So until I can afford a new one don't expect any updates from me in a while :/

Out of the blue a nice fella from Foxconn has offered some help sorting out my hardware needs. I'd like to extend a big thank you to him and Foxconn.

So with any luck we'll be un and running again soon.

Friday 1 October 2010

HMD flight symbology

More flight symbology added today. Raining almost non-stop and my cars wiper motor has failed, so wasn't going anywhere.


We added a couple of items that make it possible to do some precise flying.

  • Velocity Vector
  • Acceleration Cue
The Velocity Vector is the blob on the stick that originates from the cross in the centre of the HMD. This is a representation of the direction and speed of your aircraft. Think of these as "top down" views with your aircraft in the middle, forwards movement is up, sideslip left and right. It's scaled so that the top of the HMD (below the heading tape) represents 60 knots. This scale changes depending on the mode but for now I'll stick to the TRANS (transition) which is the most used.


Floating around the end of the "stick" is a circle, that's the Acceleration Cue which shows your helicopters acceleration. Generally the blob on the stick will steer towards the Acceleration Cue as you manoeuvre the aircraft.

Using these cues it's possible to perform some precision flying and arrest unintended movement before it becomes a problem. Learning how to read these will improve slow speed manoeuvres approaches and landings.

I also changed the rate of climb indicator to a solid pointer, slip ball is currently being added. And basic waypoints and steering cues will probably be done this weekend. Especially if the weather is still lousy.