Flexman

I'm not in a position to test this myself. But are there any issues with Leadwerks Engine and SLi/Crossfire hardware? Any special considerations or setup required?

The bridge is modelled on one that isn't exactly an oil painting. http://commondatastorage.googleapis.com/static.panoramio.com/photos/original/11421583.jpg

Dave sent me his first bridge work for crossing the Death Star trench across our terrain. Pictured below is an editor scene showing it in place with some of our other 3D assets rolling across it. Five brickwork textures were used to break up the surface detail with colour matching used to make it blend with the terrain textures. Last night I finished playing around with the cockpit night lighting thanks to Bushmaster and his reference photos and nudging to fix the colours. Three rotary controls by the pilots left side control levels of the panel lights, dome light and backlighting. Having an little issue with the backlighting levels as I'm setting the levels by sending a uniform float to adjust levels of the glow shader, with mixed results, I'm doing something wrong. Have some details on the MPDs and navigation to sort out. The direct-to menu to add on the "M" key, rocket submode and the master arm on/off. I've borrowed some nice bullet code that I plan to adapt to the chain gun when these pages start driving me crazy again. The next month will have me looking at our iPhone game which is a way of supporting longer term development by using existing 3D assets in a two-minute finger shooter. We've been experimenting with the dev kits just to get a feel for the workflow and HID considerations. Our game is not ambitious, take-it out, play, spank some bad-guys. The platform is capable of a whopping 6k-8k polys with around 30 draw calls per frame, which is a little smaller than the typical 250k-500k poly scenes in Combat-Helo. Here's a parting shot of the CP/G station with panel lights and backlighting, again with the mock TADS image from another game (image supplied by Gary Wright). Hopefully it won't be too long before we get ours in place. Source

All actions relating to the AH64D go though a message receiver. Player mount, dismount, ground crew arming, lights, AI commanding and (getting to the point) virtual cockpit interactions. The MPD button naming convention of "MPD_1_17" refering to MPD 1 (pilot left) and key 17 (counting from top left) that gets sent to the input handler for that MPD. Key messages can originate from the client or network. I had to add a source ID to account for situations where one person in the same vehicle has authority over some function. The keys and knobs are all working well, interacting with the avionics. I've removed some of the more obscure items and checking authenticity of some elements. Had to simplify a few things just because it's not intuitive. CTRL-G (default mapping) will switch to guns. ALT-G cycles gun round burst mode between 10, 20, 50, 100 and full. Burst is the number of chain gun rounds fired with each trigger pull. MODE is the method of gun tracking. It cycles between HMD (helmet mounted display, this is TrackIR or mouselook, where you are looking) FXD is fixed forward TADS is the current TADS position. This is a fairly important mode distinction, particually in co-op play as the pilot controls gun/rockets and the the co-pilot/gunner operates TADS and other weapons such as the AGMs (air to ground missiles). This I think neatly simplifies operation and easy to understand. For most situations you will want to leave it in TADS mode so you can quickly deploy cannon or AGMs against ground targets. MAN RNG adjusts the ballistics trajectory. Cycles between fixed ranges given in meters. It's there for completeness without adding complexity. It's a candidate for removal. AGM sub mode coming next unless something really cool happens Source

Well thanks for documenting and a teasing look at what an embedded web server could do. It certainly got me excited about how such things might be used to export non-critical information from combat simulations. At the very least I would find this just useful for debugging a campaign system which has 200 units dotted around a 40km2 area and would need to inspect a few stats from each. Eliminates the need to use debug builds or write special code for inspection. I'm with PixelPerfect, looking forward to seeing what else you do with Leadwerks.

I used to used to use Trillian which is like Digsby. Some of the more interesting apps I have on my XP desktop: XML Notepad 2007 Notepad ++ (its just fast and flexible) FileZilla FTP Client, free and feature rich UMLet for quick diagrams 7-Zip handles 7z, rar etc. Otherwise my Programs menu is close to yours. I haven't used MS Office in years. OpenOffice has been good to me. I wish is was not so difficult to locate funding here in the UK. It's like pulling teeth, the avenues are not obvious, even European grants are available. The UK now offers tax breaks to game developers. Regards

I think adding a callback for LoadScene() would be a nice to have, something like "CallBackLoadSceneFlip()" to keep the window alive instead of Windows thinking the app is "not responding". Loading map layers and veg can take a few seconds, long enough to 'grey' a window making a user think it's crashed.

I think this is awesome. Well done. This can be really useful.

Oh goodness Dave. That's an interesting thought. If that's the case inserting "sleep for 10ms" into the main loop to help keep things cool might help. During long development sessions my room gets pretty warm. Star Trek Online had a fair few users with overheating problems. You can scan their forums for things like "STO killed my PC" or simply "overheating". Cheers Dave

Quick update. Busy working on a lot of small things. We have a cockpit update coming to update MPDs, internal and external night lighting. MPDs taking to the TStores class and working towards having a number of cockpit functions up and ready for the start-up. Dave added the CP/G throttle panel too (which removes the power switch and engine startup). Experiencing a problem with fps slowdown over time again. Mostly down to repeatedly running combat-helo, stop, edit, re-run. FPS drops to single figures. I'm not seeing main memory leaks and it doesn't effect other games. I'm not clear what is happening, a reboot fixes it. I wanted to see what the TEDAC would look like later so I was cheeky and borrowed a still from another game as temp background. Source

Just to chime in. If you use the LE shaders for glow such as "mesh_diffuse_glow.frag" then you need to provide a glowmap in texture stage 2 and use the glow post-filter. The glowmap can be the same texture as your colourmap if you want. Look at the example "cagebulb" which is part of the cagelight in the underground level... texture0="abstract::cagebulb.dds" texture2="abstract::cagebulb.dds" castshadows=0 collisiontype=0 color=1.0,0.9,0.6,1.0 shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse_glow.frag" Glow is rendered as a post-process, so unless you're using a glow post-process effect that you won't see any glow effects from these materials. Just try it in the editor, turn the glow option on and off with the object in front of you. If you don't want to do that for whatever reason you might have to fake it the old fashioned way using a corona or an additive blended version of your laserbolt.

Stages sounds like a nice way to do things like Megaparticles which I was having a look at recently. Plus it would make my cockpit problems go-away if you could reset the camera matrix back to zero for a final stage. camera.Render(1);// draw transparent objects MatrixReset(camera); camera.Render(2);// draw cockpit object camera.EndRender();

Only an artist would spot that. With all the BLOOM you won't see a thing, nope, not a thing Those panels (except the forward one) don't exist in the real helicopter. They are just a conceit to add some means to quickly adjust game options. May or may not work. I think it's too fiddly and probably better to have a popup menu. It was really hard to optimise the cockpit. When you are positioned in the rear seat you have all the front seat displays switches and buttons just out of sight but not culled. So all the parts that are not visible from the other seat are grouped under a single parent. And when you change seats it hides the other parent and thus all the children. Made a difference in performance. Not a big difference which was a supprise, Leadwerks chews through polys like a Velociraptor. If you have a head tracker device you can scoot down under the seat and see the odd easter egg. One plate reads "The good, the bad and the ugly". Nothing offensive.

mesh_diffuse_billboard.frag ?

Yes exactly. I'd post of shot of what the diplsyas look like with bloom but it's way ott. It's like having an eye condition. Can justify it for night vision otherwise I'll leave it as a user option. We're experimenting with having a popup panel for all the effects....

BLOOOM! Bloom is an actual effect of using night vision, you get a lot of bleeding from high-intensity light sources with that equipment. Even some clipping. Personally it's among the first things I turn off in any game. The pit lights with bloom do indeed look more like the photo reference. I'm just pleased that it was a quick task to create the night lights. texture0="abstract::apache_pit_instr_02_skin.dds" texture1="abstract::apache_pit_instr_02_normal.dds" texture2="abstract::apache_pit_instr_02_glow_skin.dds" ... ... shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse_bumpmap_specular_glow.frag" The "glow_skin.dds" files are black with just contain the areas to light-up (all the back-lit text labels and lines). It's about a five to ten mimute job to add the effect if you have a Photoshop file with the original artwork.

Yes, the art pipeline is the monkey on the back for any engine. The first thing I did was go through lots of old forum posts about materials, shaders, animations, anything on exporting and I cut and pasted snippets into a single document. Complete with screenshots. It took a little compiling but worked as a guidebook and helped learning. And I found that just using one format, GMF for models and DDS for textures makes organising assets far less messy, no JPGs or BMPs, TGAs. As for MAX exporting, we have some pretty complicated models. We're having issues using the non-official one, highly detail cockpits and helicopters exported with it kill frame-rates. So we're stuck with using the official one till we know why. Ultimate Unwrap was pretty good for casual exporting but Dexsoft models would often have shading issues with it. Exports from different exporters are consistently different

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

Maybe you've fallen through the ground? When you run the script and the camera is positioned close to the terrain it can drop through. It's a great script, quite complex. I just added a third person cam to my game and using a place-holder but I might try using this with the soldier for now. I notice that LODs in Leadwerks don't like animating in LUA, I suspect you have to interrogate the currently used LOD level and animate that mesh instead. You can try it yourself by commenting out the call to the 3rdPersonCam function and move the character away. I have the same behaviour in static vehicles/objects that rotate child entities (tank turrets and such).

This is OpenGL, vector based rendered to an offscreen buffer, now with added mipmaps. I'll try and detail the functions of these pages and sub-modes as I go and allow you to submit corrections early on. The WEP (weapons) MFD page Pictured below shoing the gun sub-mode. Main feature is the bust limit selector on the left side indicating the number of rounds fired when the pilot commands. The bottom MFD buttons marked GUN, MSL and RKT will switch the weapons and display rounds and options. Stores and gun rounds to add to the display. Will complete tomorrow. The only other notable feature is the ACQ option (R6) to switch the gun aiming between fixed and TADS. The buttons marked with and arrow above (see top row) are for navigating to different pages. The bottom right button indicates the current page (WEP boxed). Next to that the selected sub mode (GUN boxed). Source

That's really fascinating. I never gave thought as to how you get textures from plants. So how do you do it with your fabulous trees? They must be difficult to get onto the carpet?

All looking first rate, moody and atmospheric. The last screen-shot with all the trees, if there was some kind of far-shadow shader or something to darken the terrain under the trees, that would improve middle distance scenes in the engine a lot I think. I can almost imagine what it sounds like to wander around this zone, wind, creaking doors. *edit* The screenshot script doesn't work for me either, the terrain seems to come out white.

AD has been finishing more of the villages and green zones around the region. You can read more about it here... SimHQ Dev Diary update This is "Dara" in the Northern region (See map below) Source

Just to add, this is a post-process technique that blurs the edges a little. I was wondering about a technique that uses a buffer larger than the viewport, then drawing that buffer into the viewport. Wouldn't that achieve sub-pixel accuracy? I think this is how Gran Turison 2 on PS2 handled full screen AA. The disadvantage is the bigger memory requirement when all the various buffers are quite large already. The different buffer stages don't need to be the same size though do they? Just a thought.

I'm in the process of adding the weapon systems; avionics and links to the stores. While that's coming along at a steady pace I often come across a bit of code and think "I could quickly do this..." So I just quickly added the third-person cam; as we don't yet have any character models I'm having to use this laughable code generated place-holder. Character height is 1.8m. We're going to require a rigged humanoid with a number of animations for sitting, prone, kneeling, aiming, running, walking, waving etc. We have a list on animations somewhere, I'll try and dig it out. This is "Marshall" from BBi collectibles range (now discontinued). He's a great model, but the wrong sort Source