Flexman

Congratulations to ArtDave (AD, geddit) for scaring the poo out of me. He tells me he's been scripting the flare pen (Gyrojet), I'm so busy heads-down in game code I'm often grunting and throwing back idle comments and ideas to get his flare launching LUA code to work. Then he sends me his completed files. I'm taking a late afternoon break and thought I'd drop his new files into the project to have a look. So I pull over the gyrojet flare pen into the scene editor, I had no idea my speakers were on so loud. I thought a bomb had gone off, the almighty flash and bang/wheeeeeeeeeeee of the flare scared the **** out of me. This is just too much fun to play with. Animation, sound, lighting. Nicely scripted. Great work Dave, I suppose we're even for farmyard animal noises I put into your cockpit. Source

Quite a scrappy day. Installed Microsoft Flight Simulator X and the SDK, there's an interface I want to try and build as a gauge in FSX. I've used the Simconnect API to interface to my own radio panel, now I need to build a gauge to talk to the Simconnect DLL. I re-worked the avionics menu page using the new vector glyphs, adding some commands to toggle the chat console, about page for version information. The UTIL page sets the FMS channels (Flight Management System or FLCS FLight Control System) in the Helicopter State. FMS_AXIS_PITCH:Int = 1; FMS_AXIS_ROLL:Int = 2; FMS_AXIS_YAW:Int = 4; FMS_AXIS_COLL:Int = 8; FMS_AXIS_TRIM:Int = 16; FMS_AXIS_ALT:Int = 32; FMS_AXIS_HEADING:Int = 64; FMS_AXIS_HOVER:Int = 128; These are bitwise settings as we need to be efficient sending helicopter stability settings over the network, seems sensible to use a single byte to do this. There's a lot of data needed to set up a complete helicopter if you're coming in over a network and jump into one ready to take-off. Console states won't be updated that often but when we do, we don't want a bottleneck. Time to sit back and examine the feature list, clear up where are priorities are and how far away are we from the major milestones. It's important to get this bird ready for some serious flight testing, there's the terrain LOD system to work out as we don't want ugly popping, Raleigh Scattering for the sky dome, additional fog and integrating FFD (FreeFlight dynamics tm) flight model. We might strip down the FCR a bit, the TSD we'll keep on a par with Longbow 2. There are lots of things it can do for designating fire zones and splitting them into groups which we just don't need for this version of the game. Even considering dropping the MPD cursors as they won't do much except mark areas on the TSD. I learned something interesting today, In 1980 Ken Perlin of Perlin Noise fame worked at Magi, the company that worked on Disney's film "TRON". His paper on a function to generate non-random "noise" was publish in 1985 and is often the basis of many shader techniques today. I read this today when looking at how we might introduce more ground detail into surface textures. That's the problem with shader programming, once you start, it's difficult to stop. Good job Dave knows when to stamp on my toes. Source

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

Video underlays are working as intended (more or less). I split the MPD buffers into two, symbologyBuffer and compositeBuffer. The symbology buffer is texturestage2 and rendered by the shader at full brightness. If the underlay is active the TADS/PNVS buffer is copied to outputbuffer which is texturestage0 (the simple diffuse buffer). The two are mixed by the material shader which is applied to each MPD screen. The mix works well, providing enough contrast between video and symbology even when the video is quite bright. I did a version that mixed symbology and the video buffer into a single composite via a shader but the mix was often overbright and hard to read. A good case for adding a working video level control? Maybe in version 1.5. The final modification is to use the TADS/PNVS postbuffer instead of the raw camera render. Source

Ouch

Is there any Entity.SetKey(...) callback for helping to sync entities? When it receives a key locally it can decide to pass it through the network? I'm currently doing this via MessageReceiveCallback(..) which has a wee bit of code to decide what to send where. On the whole that seems like a good place for it but sometimes you just want a couple of keys to sync.

Not quite there yet. What I'm trying to do is copy the raw TADS buffer into the diffuse COLOR0 buffer and render the symbology into the same bugger but into channel 2 (COLOR2). Texture channel 2 is used by the "fullbright" shader and mixes at full intensity. The net effect being a normal diffuse texture with full-bright symbology painted over it. At the moment it's not working as intended. I need to go through the shader to check it's doing what I think it's supposed to do. And see if I need to just use multiple buffers and mix them instead of trying to draw directly into different stages. I'm probably missing an OpenGL command to set the texture target correctly. It's getting late and I've had to do a lot or changes, our cockpit MPDs only have two knobs, the photos and source material I've been using to layout have three knobs. So there's a slight shift in positioning required. Non of this does anything yet except the "VID" button that toggles the current TADS buffer. This is the new vector font/glyph system in use. I've yet to add the various button "specials" such as menu nagivation arrows, but the toggles work. The FOV shouldn't be in the raw TADS buffer, need to switch that. The FMS toggles on the left will interface to the flight model. I have to say the bitmap fonts looked just as good, if not slightly better when used at the same size. It was a pain adding new glyphs though, here I can add anything I can code with GL commands. TrackIR remains a tangled mess of wires but I managed to assemble it to test and discovered that I'd not added the Track offsets to the cockpit cam. Quickly fixed that. Source

Added a simple frame-skip to MPD draw method, they don't need to be updated every single frame and it squeezes out a little extra. Found a "toob" video in which you get a couple of frames of the UTIL page. Anti-ice and FMS options, presumably this is where you can toggle pitch roll and yaw augmentation. Well seems like a good place to add that and we will need to flag some FMCS values for HTR which can auto-trim. Turning that off in the UTIL page will be handy. Looks like "NOE?" at the bottom too. No idea what channel that's supposed to be. Got some strange problem with my matricies with the new vector glyph render, fixing that this morning. Will update with a screen-shot when fixed. Noooo, a totally numb-nutz error. My old OpenGL line macro uses integer verts, switching to floats. Oh man, how dumb. PC froze unexpectedly this morning. It hasn't done that in ages. Source

My chair's really bad and falling apart. Went looking online, some nice ones that might be good for my back but I saw this one,from Amazon.co.uk oh boy, to bad it doesn't come with Kevlar plates and a cup-holder. This one is quite nice too...bloody expensive though... Guess I'll end up with this one... Source

Monday was one of those email days. Future Tech As director I'm looking beyond Combat-Helo, the future of the game and where we want to make improvements. One major improvement I'd like to see is the terrain rendering part of the engine. Make it more flexible, scalable and efficient. We've been looking at different engines and technologies, none of them are suited for flight-simulation out of the box. As much as we'd like to license those for use in a future commercial project they are either not ready or unavailable for license. To satisfy requirements post Combat-Helo we require the ability to model the whole of the earth and stream in data for ground detail. There's potential to do that with the current engine by paging in ground object data with a curved terrain mesh (think of a skybox that's curved into a sphere, but used for terrain). There are several interpolated LOD methods. The Terrain Augmentation Program is to be an ongoing side-project and not to interfere with Combat-Helo development. Vector Graphics and Display Lists I was looking over our Apache MPD (multi-page display) code, there are items I left out simply because I didn't have a handy symbol or character. Also the amount of updating required is a little inefficient. MPD updates were scheduled to be part of an optimisation pass later in the project but since I was adding the FCR and TADS symbology I feel justified in bringing that forward to make it easier. Currently the MPDs use a co-ordinate system with 0,0 in the centre of the screen, with -1.0 being the left edge, +1.0 the right side. With +1.0 and -1.0 top and bottom respectively. This allows for resolution independent rendering. However some elements such as the Leadwerks bitmap fonts required converting to a standard co-ordinate system. Bitmap fonts don't scale well. I've just completed coding a complete alpha-numeric font with symbols that mimic closely the current Apache MPD looks. All using vectors and OpenGL Display Lists (which are sort of pre-compiled commands), runs pretty fast and looks not too shabby. The MPD text and symbols are now fully scalable, also being pure OpenGL they are freed from needing the 3D engine and will run on a modest laptop. Things left to do,convert existing code to use new VectorFont class, use more Display Lists for page elements. I was adding the FCR (back) into the game while I was away last week but it's aged so much it's worth starting over. Sensors and Equipment Regardless of the current Apache capabilities which are not in the public-domain, our Apache will track and classify up to 256 objects (thank you AABB for making it so easy). It's currently magic, meaning instant and no regard for signal strength or LOS. This will be sorted out later. Just needed something to display on the TSD, FCR etc. David has been looking at the crews survival equipment. Something you can whip out to find out where you are. We know we'll want to have at least one weapon (a sidearm) and smoke signal flares for dropping a coloured smoke emitter. Source

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

That's quite interesting Lum. It sounds like you've been doing some mesh > terrain work. Are you working on a paged terrain system? The floating-point issue is as you say something that might be partially solved by changing positional values to doubles then converting back to 32s for sending to the GPU. Ideally with a paged terrain system you can move everything relative to the camera, that way it shouldn't be a problem. Just trying to work out some options here.

While looking at ways of extending the visible horizon by layering the scene I thought about "Imposters". Something used in rendering space scenes and also the "Infinity - The Quest for Earth" project. I remember an article on Gamasutra - Dynamic 2D Imposters. Then I saw this ... Patenstorm - Dynamic 2D Imposters from Microsoft So, am I to take it that rendering 3D elements to billboards is covered by a patent? Any rational thoughts once the red-haze has subsided? Someone please pinch me and tell me it doesn't apply.

I'm trying to nail down a price for the source but need to nail down how we're going to mod the terrain system. I'm in Tuscany atm talking about different engines, mods, some new ideas for planetary rendering and what we can do. I've just been shown some impressive terrain tech by Quadsoftware that was used in Blazing Angels 2. We'd love to add a new paged terrain renderer and mod the engine to translate entities relative to the camera instead of the other way around. But if we end up going DirectX for the sequel I'll have to re-write all the rendering functions for the vehicles. Which frankly leaves me feeling MEH!. But I'll do whatever is necessary.

Today I added a postbuffer pixel shader to do light amplification for ETADS. Based on Geeks3D lightamp shader and modified for Leadwerks Engine it actually performs amplification by sampling the source pixel and if it's below a threshold, boosts the pixel intensity. Pretty neat. These are tests, the left half is the amplified area, right side is ambient light. The the first greyscale image has the polarity reversed. Into the mix I added a scanline mask with animated noise. The ETADS mask looks pretty good although I'm using a 'scope' mask here which more interesting visually. The last shot shows more of the noise distortion that makes the image 'buzz'. This is almost ready to drop into the TADS class. As for thermal imaging, we would need to add heatmaps as secondary UVs or fake it using some heat lookup. This is adding a level of complexity I don't want to pursue at this time as we could spend years throwing in tiny amounts of detail most gamers are not going to need. This amplification shader allows us to give some threshold and boost control to the gunner so they can apply some measure of skill in finding ground units visually in poor lighting conditions. *edit* After some consideration I think some attention to thermal signatures would be good after-all. This could be done by adding an "objectname_intensity.dds" map to texture channel 4 or 5. Then modify the base Leadwerks pixel shader to boost the intensity of the pixel from that channel. It shouldn't be too hard to take an existing diffuse texture map, desaturate and reduce the brightness to almost nothing then airbrush in some intensity levels. This would work well with the light-amplification post processing shader too. Source

As I sat down to implement the generic event system I was reading Game Coding Complete which discusses something similar, the Actor class. I was reinventing the wheel...badly. The wheel is overrated as an invention. By far the greatest invention was the second wheel, lets face it, the unicycle isn't the most practical form of transport. I digress. Actors. If you want to know more about them see Actor model at Wikipeadia Then I came across this public domain implementation by Otus which also has a remote sockets version. Should work nicely as we need these to fire n-times every t-seconds for displaying alerts. Also David worked on analogue flight gauges. There's different ways you can implement gauges. Did we want lighting? A glass face? My initial though was to build them like real instruments with different layered discs (hi-res textures with alpha) rather than 3D objects. Looks like we're going 3D for now, the kinds of instruments we have don't need anything complicated. Source

That seems reasonable. It's almost possible to get it to work in the current editor by having an entity load an SBX and parent it to that object. But it doesn't work in code, tends to crash. Leadwerks is in desperate need of some near game-ready tools, prefabs, greater control over painting. Things that both SDKers and drag-n-droppers can use. Something that can build and assemble joints for testing. Good stuff.

Bet that was a shock. Well good luck getting that replaced. Keep a fire-extinguisher by your PC I had a bad solder weld come loose with heat once, the whole heatsink popped off as a result. As for the Zone, I really wish we could afford that kind of detail in our project. It's superb.

There are shadows but sometimes they are pulled up close to maintain fps. We're finding ways to improve performance all the time. When you're running around on the ground it's fine apart from the lack of veg detailing which we don't have the memory for unless we can add some procedural scrub. At medium altitudes, well I'm sure you'll agree it's hard to push shadows out very far. With only 3 shadow ranges and if you push the third one out too far it looks quite 'diffuse'. Some kind of distant shadow layer would be a good, perhaps by baking them onto a texture layer. Baking some ground AO onto the buildings would help too. If I was clever I'd have them sitting on a floor mesh upon which I could update a single shadow. There's three compounds at different orientations so it might work.

I updated my work-map today with a more recent one and still in the process of fixing up missing objects. I think I have half of a city missing. The cockpit is now in it's own world space resting at the origin and no longer effected by floating point error, but I did leave in some rotation 'noise' to give the cockpit a vibration effect. I pushed the tree LOD out a bit more which you might see in the following screens. If you have an uber PC you'll be able to render some really sweet scenes. The ETADS has a temporary green tint because I've not yet added the desaturation filter, it's on the to-do list. Some of the systems such as the helmet mounted display are not operational as it thinks the power is off. I only just found the ground radar mode from September. It's amazing some of the things you forget you added. One day soon there's going to be ZSUs in those tree-lines. I'm missing a chunk of city here. There should be rows of stores and back alleyways around the urban compounds. I have the models installed so I don't know what's going on yet, I suspect they are missing from the SBX. Gets awful lonely out in the plains. Stopped for a photo-op. With the cockpit rendering modification almost complete it's back to core systems. Source

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

Just to add. Performance depends greatly on what version of LE you're using. The latest 2.32 uses a quadtree to cull entities and is better for large numbers of entities. 2.31 is a little different. You don't just count the number of models, but also the number of child objects in each model. In our project for example we have 500 compounds alone, each compound had 15 objects (walls and out buildings). Even though it was just 500 buildings there were in fact 7500. By collapsing LODs into single objects performance doubled in 2.31 alone. This had no effect in 2.32 which shows how well the quadtree system works. Big terrains can take a long time to load. So take my advice, save often, multiple backups. And if you think the editor has crashed, just wait and leave it, chances are it's just busy.

No joints on the tracks, it's too computationally expensive. The tracks are made so they can be animated by scrolling the UV co-ordinates. I don't yet have a shader to do that. Needs to take the vertex colour of the track and turn that into the necessary offset. I did have an APC with full vehicle physics, just the wheels though, in grass at speed with dust you couldn't really tell if they were moving or not. If you want to give the shader a go I'll throw some tanks at you to play with.

My Dennis Norden bit. Out-takes from today. Most programmers we have a few wilco tango foxtrot moments from time to time. Here's a few from today. Starting with "How not to render lights to a buffer." The canopy glass makes for an interesting effect. Next, an interesting effect you REALLY don't want to see....ARRRRGHHHH.... This is me getting a transform wrong. You can almost see the join between the high detail cockpit and the Apache exterior model. Mind the gap? I did fix this by correcting the TForm and resetting the camera back to the origin. Still have the lighting to correct but it's almost ready. The cockpit is rendered after the world, the zbuffer cleared and the pit is drawn at the world origin so zbuffer and floating point error is nil. All games have hacks to make them work, didn't you know? Speaking of hacks I highly recommend "Game Coding Complete" by Mike McShaffry. Full of funny developer anecdotes and a brief history of Ultima which is fascinating. As well as many best-practice approaches to game programming. Moving on, Dave was back to polishing the textures and models. More AO baking, backfaces, specular tweaks. Here's a selection of views from today. (Leaving out the rude England footy twitter jokes, some of which were priceless). Source

Indeed, use mono audio files only. EmitSound returns a TSource. You might want to store that to adjust volume and pitch. Here's some code from my CH47 model... class.soundcompressor = LoadSound("abstract::ch47_compressor_loop.ogg") ... ... object.source_compressor = object.model:EmitSound(class.soundcompressor,75,1,1) SetSourceVolume(object.source_compressor,0.5); That should be all there is to it.