Flexman

Just be aware if you're making a multi-player game, be careful using pointers in entity user data. A remote machine won't be able to match the pointer to anything valid. Just something to be aware of.

Spac3Rat sent in a nice new game icon as well as two editions of his Rotorwash magazine from 2006 to read. Fascinating look at building helos for FSX, one thing we learned about FSX models, they don't work too well for our kind of real-time work. But fascinating all the same. Dave is busy in 3DMAX building something that looks very much like a Chinook. I'm making incremental improvements to the GUI system, panels can now be roughly dragged around without risk of "mouse droppings" (the window/item being dropped off the mouse during aggressive mousing). Buttons and input fields are getting focus and their classes respond to events OK. Running two Combat-Helo instances side by side isn't recommended but doable, solves the logistics problem for network testing until I can persuade my wife to maybe set-up a virtual machine with 3D acceleration like she has on her desktop. The gui system is linked list of active TGUIPanels (base type) which maintain their own linked list of user controls (TGUIItem), each control having a simple drawing function. They keep track of what's got focus, what's been clicked on and dragged around. It's only going to be used for a few things but it makes it easier to add checklists if needed. And they just make use of a couple of base textures and existing game fonts (of which there are about 5). The IHADSS or HMD has a problem that has been bugging for some time since the early flight tests and a recent personal message confirmed it. Look over your shoulder and how the hell can you tell which way up you are when the artificial horizon vanishes? So we're going to fix that to work as it should as soon as we can. It's also supposed to be quite low resolution but that would look really ugly when it's constantly in your face, I can't bring myself to reduce it to VGA res. Dave has learned that Chinooks are round, very round. I learned how to pronounce it correctly (Shin-uk) thanks to my Canadian wife who repeatedly laughed at my attempts. Finally, Red Dead Redpemtion has been a fantastic game, the open-world and amoral nature of Grand Theft Auto games applied to the old West (USA, 1903 era) fits perfectly. And you get to play a protagonist you can like. Amazing inverse kinematic system meaning character movement seems quite natural compared to traditional baked animations. A world that is just fun to roam around in, a magnificent achievement. I spent an hour in a saloon just playing Blackjack. Which reminds me, I'm out of Whiskey. Source

oh, I just saw the date of his last post :/

To me it just seems like a lot of stuff between you and your game. I've been seeing a logo/trademark recently I hadn't come across before, "Scaleform", like Awesomium I had to Google it. Scaleform is another GUI system but uses Flash at the design stage. Seems very popular (600+ titles many of which I AM familiar with). I don't really have a use for it as I only use LUA for trivial entity level housekeeping. But LUA is lacking a workable GUI interface, if there was such a thing maybe we'd see more sophisticated use of it. Niosop you're in a better position to judge as you're enabling cool stuff to be done with it.

I don't think you can get around it. We ran into a similar need and got around it by having two meshes. Swapping them in/out was quite fast (same model with bits chopped out using same materials). Not quite the same thing as yours though. Perhaps you could paint the parent entity with the "invisible" material when you want to hide it, and paint it with it's normal material when you want to display it again. PaintEntity(entity,"abstract::invisible.mat",0) Where 0 means "non recursive". ?? Just a thought.

Worked a treat. The Zone is looking pretty awesome so far. I love those track textures. I'd like to get at them just to see the details of how to go about making my own desert tracks.

These near/medium/far ranges are displayed where? In our game, anything closer than 20m is probably under you. Object distances are typically 50m to 6,000m at tree-top level (variable according to camera zoom mode).

This isn't a practical suggestion, just something that I think is pretty cool. Horizontal Displacement mapping. Using shaders to apply fractal noise maps to pull out natural looking surface detail. Pretty advanced stuff, like a lot of things in GPU Gems (available for free in HTML format here) it leaves me scratching my head. http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=503094 Clicking on this next link may induce a feeling of apathy and weeping (Gamedev journal showing recent progress). As mentioned in an above post, some good rock models (Pure3D has a selection in his store) can be used to create nice cliff sections. See the for an example of what can be done. Pretty amazing.

I wasn't going to add a complete gui system, we don't need anything complex. The address book needs to accept input from mouse and keyboard and when I thought about it, the planned map viewer/editor will require it too. It had to be a simple gui system with input focus and keyboard entry. Since the chat console had functions for filtering keys and the input mapper directed keyboard input into it when active it was simple enough to change it to send to a gui class and whatever control input had focus. GUI drawing and input handling is as far as I got this evening. Should be functional by late evening tomorrow. Address book will store entries as XML, not sure if passwords should be stored or not. My professional hat says no, my lazy hat says yes. It's non-critical so it seems reasonable to store the last used password no? Source

We've been using the black and orange diamond logo for some time, it needed to reflect the game colour palette. As a 90's homage to sims of that era, a saturated colour scheme with the GUI elements using 90'-45' angles, black and orange. Two contrasting colours that are visible against most backgrounds. It wasn't until after I had designed and coded a number of elements that I noticed other military games using the same colours. Why bother with stuff like splash screens at this stage? They set a tone and expectation when showing demos, fix the colours and facilitate feedback on identity early on when things are still fluid. In our case, we have possible issues of copyright and licensing, issues that came about through the process of establishing identity. Matters that are hardly trivial. Plus the above vignette style works much better on multi-screen monitors when centred than the old one which was stretched. This has better overall presentation. Logo is still in flux but overall colours and shape are there and reflected through the whole game in every interface element. Source

They are fun to listen to, like an LE podcast. If you're taking ideas for advanced tutorial topics in the future, video examples of different kinds of joints would be nice. Moth AI and suchlike

Ah I see what you mean. It's not quite the same model, two compounds built the same way, different exporters. I'd really like to know what the big size difference is about, there's a performance hit too, noticeable with a 30k poly cockpit.

Alas were it so simple. Roads are a bit odd actually. Out at the near 20k unit region, they do wibble a lot (I like that word), in the middle distance they appear steady. I'm quite intrigued by that. We're able to mitigate some effects using LODs and object visibility range settings, 2.32 has more options we'll be using. But still have depth issues as we have up close objects everything in between for 6,000 or so units. It all goes to hell when you have something like a sniper-scope though. You're rendering a narrow frustum with objects up close and everything out to several km. There's also the issue of floating point accuracy which an accurate zbuffer can't fix and needs Ogre3D style camera relative rendering. My workaround for that is to simply not have the cockpit occupy the same world and fake lighting to match; after the main world render, clear the z-buffer then render the cockpit with ambient/sun light. Live with the other visual artefacts, which it has to be said can be seen in other games to a lesser extent. I've been chatting with the Outerra engine designer about his technology, very nice chap, it's currently OpenGL, surface to whole planet rendering. Way way beyond the scope of what we need for our current game. 40x40km is the biggest LE lets you make which is spot-on perfect for our game. I just want it to look steady, as best as we can. If it's reasonably straight forward to add your own z-buffer shader function to improve shadow rendering and depth resolution then great. But there has to be a catch?

Today was spent working on reliable interface network client/server connections. It's apparent I need to add some additional items to the top of the screen: Current world time Mission Time (as offset of world time) Connection status indicators (connecting/connected/ping status) These to sit alongside the current game mode, camera mode and have a suitable background image. Testing is proving difficult logistically. I would like a fairly inexpensive second PC with small form factor capable of running the Leadwerks engine at a reasonable speed. Something that can sit on top of/or next to my main PC. Password protection seems to work with servers rejecting connections appropriately. Facebook I'm told everyone and their app has a Facebook page so here is the Combat-Helo Facebook entry. There is something of a virtual Apache walk-around with an internal one coming later, a collection of screen-shots in the galleries so you don't have to hunt around for them. Source

You make everything else look bad I mean bravo, inspirational I'm still not clear how this blend shader is supposed to work. It's blending another texture with bumpmap onto stage0 and stage1 using the models vertext colours as a blend factor? And does that not affect the colour or intensity of the model? Or can you still still set the colour of a model? I'm so confused now.

Is it really a Dexsoft/model issue though? When I started last year looking at model import/export I tried a Dexsoft pack or two and UU3D and got similar results. Two different packs by different authors. I used the official exporter in 3DS MAX and all those problems went away. Everything I exported with UU3D was terrible. But it doesn't stop there...take the two 3DSMax exporters..here is the same model side by side. Arbuz's unoffical exporter on the left and the offical Leadwerks export on the right...(see image below) Quite a difference there too. And that's trying to use matching settings (I'm having cockpit export issues and working out why I get different qualities and sizes using the different MAX exporters). But UU3D always gave me problems, I stopped using it for anything other than quick placement. I think the GMF exporter it needs updating or something.

We finally sourced a a reasonably good infantry soldier, low poly model, rigged, animated and exported. We can fill the screen with dozens of these guys, falling, shooting prone, grenade tossing. We'll give them a couple of weapons they can swap between and a range of helmets swapped in by setting an entity key. To initially test animation sequences I populated a drop-down control for the editor dialog with the following LUA, chopped up for readability. But lets you pick which frames to loop by name (or number). This is quite compact for AI troops which need to be lightweight in processing terms, this means non-use of character controllers. class.anim = { {"Idle",0,49}, {"Stand and Fire",50,89}, {"Running",90,111}, {"Walking",112,147}, {"Grenade Throw",148,187}, {"Take Cover",188,213}, {"Stand to Squat",214,241}, {"Fire from Squat",242,291}, {"Squat to Stand",292,313}, {"Go Prone",314,359}, {"Fire from Prone",360,379}, {"Stand Up",380,425}, {"Death Forwards",426,532}, {"Death Backwards",533,568}, {"Jump",569,614} } function class:InitDialog(grid) local choices = "" local total = table.getn(class.anim) for i=1,total do choices = choices .. class.anim[1] if (i < total) then choices = choices .."," end end self.super:InitDialog(grid) group=grid:AddGroup("Animation") group:AddProperty("sequence",PROPERTY_CHOICE, choices , "Animation") group:Expand(1) end function object:SetKey(key,value) if key=="sequence" then object.framestart = class.anim[value+1][2] object.frameend = class.anim[value+1][3] end return self.super:SetKey(key,value) end Source

AI cars yes. We have a bunch of civilian vehicles that will follow paths set to the roads. The city is going to be straight forward, it's mostly a grid with not many bends. My plan is to hand place nodes and have a fixed number of AI vehicles cycle between two locations via a route. Rural roads don't have much traffic. I need to keep it simple and because of the sensor capability (x10 zoom) and the need to keep traffic consistent between clients I can't easily generate dynamic traffic. Just needs to be enough to give the impression of road traffic. People I'm not so sure about. Not yet found a humanoid character that checks all the boxes.

You might need to explain a little more about what this second window is. Is it a "picture in picture" a rectangle showing another camera view, or a an O/S type window, or an app window with multiple viewports like a 3D editor?

Another update of map progress on the SimHQ Combat Helo forums. Showing how the City of Herat as a sprawl of densely packed compounds and commerce is being built. Using blocks of prefabs and arranged on a grid. This is a selection of my favourite. Meant to be viewed from a low altitude, the prefabs do a good job of keeping the eye busy. Here is half a city already with parks and minarets to add. All built to be frame-rate friendly. And a mini-game for your base, the "Hello World" of physics engine programming, shooting hoops. Camp Stone has it's very own half-court. Source

The larger scale maps you're able to create with Leadwerks engine are a little over 40km x 40km assuming 1m per unit and a terrain of 4096x4092 with 10m per tile. If you've ever tried positioning object with small details at positions more that 10,000 delta from the origin you begin to run into z-buffer artifacts. It's a problem common to most engines. A good explanation of this can be found in Steve Baker's document on Loving your Z-buffer. This is something we have problems with. Even roads, large as they are flicker towards the outer areas of the map. Then someone pointed me towards a blog post about using a Logarithmic Depth Buffer. In which he references Steve Baker's doc and an interesting solution which allows his 3D engine to render near and far objects with impressive resolution. A similar kind of z-buffer in LE would fix some of the ugly z-fighting you get further out. This YouTube video of is just nuts. Looks highly specialised, but cool.

I like to pad out columns with lots of numbers to take in the width of worst case, hence "8000" That would be a bad day to play. And you're right, I totally forgot the bloody join button, cheers.

Before I code the address book, what do you think of this arrangement? I'm trying to keep interface items as simple as possible as I hate coding fiddly bits. But these things are mandatory for modern multi-player games. Source

That's pretty cool. I like the uneven floor and ripped tiles. Great touches, small details.

Dexsoft's Middle East City pack has been tweaked by the Dave-9000 supercomputer and has produced a low poly high density city block of 1038 polys. Requiring heavy edits of UV co-ordinates and placing all the textures onto a single surface for blinding performance. Perfect for iPhone and as a building block of the high-density city of Herat. Source