Flexman

I've used Luabind myself, didn't have any problems with it at the time (was a couple of years ago). I liked it anyway, seemed easy enough.

Just to let you know I'm taking a few days off Easter Holiday. Back up to speed in a couple of days. Source

Most of the IHADSS modes are complete except for a couple of elements in hover and bobup, and the flight-path indicator in TRANS mode. Also added for Dave's benefit a small map which I'll use later as a background underlay for a tactical situation display (TSD) and easy nav mode. RichP has supplied an authentic start-up sequence complete with appropriate caution and warning signalling that fits our bird nicely. Once we're done with the arming set-up I'll get back on the cockpit sequencing. There will be an easy start option but you'll like the complexity of starting your own chopper. Modern helicopters with computers are pretty easy to start though. A new version of the 3D engine is in the works which has a new improved Octree, vegetation culling and I think lets us do a little more with terrain texture blending. Might lets us squeeze out higher detailed areas. So there's a lot of stuff being worked on at the same time. Not much time for big blog updates or making new videos. I suspect the next video will be the cockpit startup when it's ready followed by a short test flight *edit* I also made some improvements over the past day or so to lift calculations, by no means complete but much better handling during turns. Managed a roll and a loop (unloaded helo, only hit the ground once). Blade stress isn't calculated yet. But you can get sucked out of the sky if you descend too quickly. Source

It's more to do with floating point errors when you have smaller details on objects with polys quite close to each other, and the camera has to move. Just make a map of 2048 with 10m per tile and place some objects near the edge. Move the camera with a mouselook or position cam function and they will 'flutter'. Objects with children will appear to shake and it gets worse the greater the distance from the origin. Using really short near and far camera distances can't fix it either. It's not a z-buffer issue. I made a world with such camera (1 to 5) for an object and it exhibited the same behaviour although the shadows were not so bad. One way I fixed it was (I'm not using this, I tried it though) was to create a "render-horse" world and position the object at 0,0,0, copied that render to the main buffer. No jitter. But you don't get the lighting to match up and it's not very practical. So I'm not sure what the best way to do it might be. Other engines will exhibit this behaviour too. I wrote a space game in Ogre3D, any space game will run into issues of scale, there are different approaches to this. What I did was move everything (the whole scene) inversely to the camera. So the Camera was always at the origin and the space sector moved (As Scotty from StarTrek 2009 would say, "it never occurred to me to think of space as the thing that was moving"). Worked like a charm. But that was a simple game. No idea how you would do that in Leadwerks Engine, or even if it's practical. Increasing the scale of the objects will help, moving surfaces apart from each other, playing around with the shadow offsets for your light source. Just offering my thoughts on recent investigations into this. Still looking for a decent solution and keep the nice lighting system.

This entry is not about the life of pioneer George Stephenson. The pylons seem capable of configuring themselves, got some elevation in there for aim assist if/when we add that. I removed the LUA based weapon loading, it wasn't working out the way I hoped it might. There's a level of disconnect between LUA and the game-engine which added to the complexity of something that is already complex, when it didn't need to be. Can finally get started on the arming now. Got a little sidetracked with testing what I call compound entities which seemed like a good idea but don't actually work outside of the editor due to some engine bug. It would have been a great way to make villages but we've adopted a different approach. Both would give us destructible buildings. * update * Stores jettison is working too well. The whole things comes off the rail...and drops through the floor. All corrected. Rail and pod weights are effecting the centre of gravity a little too well, that's going to require a bit of tweaking to correct. I need to check my notes on stores weights and extrapolate how heavy these pods and rails are when empty. Then I had to create a custom physical shape to fit flush with the Hellfire rails as the connectors and actuator were causing collision events to trigger. And it turned out that my function to set those collisions was never called, it was removed after the 2.31 engine update. Restoring the function worked a treat. Now I need to add to the SFX required list, store jettison and stores hitting ground. Overall it's been a frustrating evening but a result at the end. Lots of fixing up to do to complete the arming, might take until the end of the weekend before it's fully functional. End of April is pencilled in as the blowing things up milestone, the campaign map is well under construction and I think we're almost at the point where the campaign data that sits on the map can start going in. It's bloody hard work, often tedious but the results make it almost worthwhile. Tomorrow however I have to face a reality I've not been looking forward to. And it might scupper everything. Source

In our project we're currently creating city blocks and rural compounds, as there are lots of these compounds dotted around the landscape I tried making a 'template' by building one in the editor (at the origin), removed the terrain, default lights, environment. Saved it as a scene, "template_compound_01.sbx". Using the old "info_playerstart" entity as a startpoint, called it "Compound01" ,I gave it an icon and used the following short LUA script... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.scene = LoadScene("abstract::template_compound_01.sbx") if object.scene~=nil then object.scene:SetParent(object.model); end end Restarted the editor (to refresh the abstract file system and the object browser) and dragged "Compound01" into the scene it worked perfectly. Dragging all the buildings and walls around. Makes dressing complex maps a bit easier. Quite fitting that it's called a compound entity. I wondered if there might be any problems using this? Or benefit to adding an AABB box for Octree culling? Entities in SBX files have IDs, is there any chance or issue around duplicated IDs from using this method? *** EDIT *** Well I found one problem, it doesn't work in a compiled BMX program, crashes at LoadScene.bmx line 417 in the engine source.

Last night we added rotor blade coning which resulted in realising the helo was just a little slightly off axis, now corrected. The Apache has been attacked by an angle grinder on more than a few occasions, might be showing signs of wear. Some LUA issues came up which erroded confidence in relying on it for so much. I've ditched arming through scripting. It's prone to misuse. The pylons are now ready to take the 3D models of the assigned loadouts leaving the final stage of the arming process and then the WEP page for the avionics which I can't wait to get back to. Dave has been working on compounds for the region... And he gave the scoop on the campaign we are featuring in what I hope is the first of many... Herat is a very pro-Iranian province and historically Iran has long believed it to be a province of their own. The local warlords are all Iranian funded. Most of the natives of the area are Tajiks, they speak Persian. When the Taliban came to power, and attacked Herat, Iran very nearly invaded Afghanistan. They had apparently massed along the borders back in 2000. They canned the plans after the NATO invasion of 2001. Our campaign follows on from the current real world conflict in Helmand province. The concept is that should the Taliban retreat, they might choose to retreat north-west into Herat. NATO forces would follow, expanding their position at camp stone south of Herat, and begin engaging Taliban positions. Local Tajik civilians get caught in the crossfire, Iran decides to move in to backup their warlords, and secure the civilian population. One too many stray arty rounds and NATO is in a full blown conflict with Iranian armoured forces. That's it for now. Source

Still working on the loadout system, as it happens I totally forgot to do the pylon classes. While I'm working on polymorphic classes to deal with that (lot of cases to think about). During lunch I played with some more dust effects, this time for rotor downwash. This uses the roaddust pixel shader so it picks up the colour of the terrain it's currently over. With no wind vector applied, brown-outs, where the crew can't see outside are occurring. Not sure why the canopy isn't blending as it should, it's located in the same transparency world as the dust particles. I'll have to check the shader settings in the material. Back to pylons. Source

That is odd. Now you mention it I've had a random issues in the editor, meshes that are loaded via LUA code by a parent entity sometimes take on a random heading (pitch and yaw remain stable). Only in the editor though.

I was thinking over some official forum posts and one gentleman indicated that they were partly colour-blind. Accessibility issues are something I think about whenever I'm writing software or web site design work so I kicked myself when I didn't apply that to the interface. I added some GUI elements that link current selection to the tooltip, this should avoid ambiguity in the menu system. So that's all working as it should, just have to fix up the weapon selection system which will be based loosely around this mock-up... We has some debate about walking around in ground mode clicking on weapons displayed on the ground like in the above picture. Or some other mechanism involving a fixed camera that cycles through each pylon and a vertical list to choose from. On the whole, there's not much difference in workload, both are fairly trivial to implement. It's become a style choice. But I'm torn between traditional as above, or flashy console panning cam and up/down list. Either way it's a far cry from Gunship 2000...or is it? Which method will I implement? Stay tuned for the next thrilling blog post when all will be revealed. Source

Writing this up for reference later. Thinking about players, names, callsigns, current rank, medals, changing characters. The 3D base metaphor avoids a lot of GUI work. Using 3D lockers (since I have one to hand) is perfect. As it turns out, as easy as setting user keys on Locker entities. Simple. Source

Ribbon emitters, are a kind of particle that are used to leave trails behind things, like swords, or spaceships (see Homeworld), aircraft wingtips. They are sometimes called other things, Ogre3D has them except they call them Ribbon Trails. They are a low rent way of doing what I think you're trying to do. Problem with using normal particles for exhaust trails is you need a lot of them for a decent effect which is spoiled as soon as the source is moving at speed, they can thin out till you see the individual particles. And if you use a lot of particles the fill rate can go through the roof. I had a little go making ribbons in LE (using GL_QUAD_STRIPS) as I need them for something later, had to move on to something else. But I found this which might be useful Basic Ribbon Trails. It would be a cool addition to the emitter system.

On the whole, I'm starting to warm to using text for user options, the nineties style. Dave showed me some icon screenshots from ArmA and remembered why I didn't like them. Is that a steering wheel? Desk fan? Below is an in-game shot showing the menu and data displays for helicopters. Not unlike something you might have seen in older games using pre-rendered art. All interactive objects around the base will have these. If you don't want the floaty status text, CTRL L (for labels) is your friend. Eventually each helo flight will pull it's call-signs from a datafile (Twodogs, Ugly, Badman, Goody etc.) which will go in placed to the current auto-generated ID. Status refers to the ground crews work time to prepare the helo for it's next sortie. Fuelling and weaponeering. The play process is typically pick-mission, go to aircraft, pick weapons if default not to liking, hit the fly button. It's been the same in games from Wing Commander to Black Shark. Pretty much universal. And we don't want to break that. Reading how UK operations conduct Apache helicopter turnaround, the Apache lands, is guided into an arming bay and re-armed immediately so it's ready for the next flight whenever that may be. No hanging around waiting for a bird to be armed if you're urgently needed in a support action. To facilitate this into the traditional game flow, brief>arm>fly, the ground crew servicing timer starts after landing and shutdown. But as the player may change weapons seconds before flight and we don't want to delay, we'll let the players arming choice count as the arming done after landing. With a realism option in to have "Real-time arming" for sim pilots who love to thrash themselves with birch-twigs - metaphorically speaking. Source

After scene = LoadScene(....) call a function that uses an iterator to go through all the entities and process them as you wish. The following code (not tested as I hacked it out from a failing memory) should be enough to demonstrate one solution. It goes through all the scene entities, finds one that's called 'light_directional_1' (use any name you have assigned in the editor), it creates a pivot object and parents the directional light to it. You can then rotate the pivot to rotate the light, hence move the apparent sun position across the sky. ' CREATE A PIVOT FOR ROTATING THE SUN ENTITY ' Global sunpivot:TPivot ' ASSUMES scene IS GLOBAL AND MAP HAS BEEN LOADED ' Function ProcessSceneInfo(scene:TEntity) Local entity:TEntity Local name:String; For entity = EachIn scene.kids name = entity.GetKey("name", "") Select name ' FIND OR SUN USE THE NAME OF THE DIRECTIONAL LIGHT HERE ' Case "light_directional_1" sunpivot = CreatePivot() ; entity.SetParent(sunpivot) ; End Select Next End Function And you can use this as the basis to do other useful things.

I had a couple of hours with Just Cause 2 which I hesitate to recommend, it a really fun game but you're stuck playing an unlikeable character. Cheesy dialogue abounds and that's no bad thing in games, I scripted plenty of cheese for Longbow Combat Helo. Think about the lines of dialogue from old games you might remember. The Playstation 3 was needed by the children for Final Fanstasy n so Rico, Scorpio (whatever the slab of MDF you play is called) was parked for the evening. So back to doing some little things on the project. There's an expectation of standards, a language of gaming to follow. To guide players through the work-flow by implementing cues and guides, can something be too obvious? I think so. I might expect to see the following (see picture below) on an XBOX or PS3 title but not a Combat Sim. Maybe some funky looking icon suggesting "mount". The advantage of icons over text is that they don't need to be localised. English, French, German, one icon says it all, even if you don't understand apparent meaning the first time, you associate the action with the icon afterwards. So I think we'll go down that route. So what is the internationally recognised symbol for "Board Helicopter"? Agghh, just stick any old **** in there, people are smart, they'll work it out. Source

Are you talking about 3D ribbons maybe?

Check off the list, working external canopy doors, flip up/down, will indicate available crew position as well as letting you chat to your mounted team-mate while you're on foot. You could even arm the pilots chopper for him. Internal doors and wipers next followed by external lighting system. Hopefully we'll have the cold start-up sequence in a few days, we need that so we can get on with more vital systems. (I just noticed the text on the rail is reversed) Source

No work will be done tomorrow. Just Cause 2 PS3 is released. The acting sucks, the actual game doesn't seem all that hot from the demo either, but the stunt playground aspect is brilliant. Source

DrawImage() is good enough for loading a texture and putting it on screen. No need to use OpenGL for that.

I'm really pumped by Michael offering his vegetation for sale and the coming veg system update. What's been the performance increase using this scene? And how long does this take to load? It does look rather dense and lush. One another comment, I don't know if it's just the visual language of video games or my personal tastes but real foliage in sunlight is almost radiant, bright greens, yet it looks much better when using darker tones.

To answer your specific queries about what you want to do. - Yes, this engine will handle a terrain of 18km2 - You level typically is loaded upfront. No native streaming support, roll your own. Complex maps will take a while to load. - Physics and audio are well integrated. See controllers on the Wiki - Input is rudimentary but enough to get on with. - Networking is a bit mysterious, there's a library but not much in the way of examples. But if you've written your own networking code before then you might get on with it. - The engine is GPU intensive, high initial resource cost that doesn't rise as much with complexity (as compared to other engines). LUA code at the model level allows for some pretty interesting stuff, really speeds up prototyping things once you're used to how it works. There's some interesing things being done with LUA, Thingoids and such, pretty cool.

This is using the 2D method, drawing to an offscreen buffer. Draw to the buffer AFTER calling Render(). Look into CreateBuffer(Width, Height, BUFFER_COLOR), the buffer it returns you can use to draw using 2D commands. Here's a little pseudo-code to give you an idea. // save current buffer tempBuffer = CurrentBuffer() ; myhudbuffer = CreateBuffer(Width, Height, BUFFER_COLOR) ; SetBuffer(myhudbuffer) ; // We can give it a variable transparency or background colour by filling with a colour and alpha SetColor(Vec4(red, green, blue, alpha)) ; DrawRect(0, 0, width, height) ; // Do lots of interesting drawing here... // even OpengGL if it takes your fancy // Done drawing so lets paste it at some screen co-ordinates DrawImage(GetColorBuffer(myhudbuffer), x, y, width, height); // restore original buffer so we don't upset anything SetBuffer(tempBuffer) ; That should be enough to get you going for your specific needs. You might want to assign a material to the buffer. Or use a smoothing filter. After creating the buffer... material = CreateMaterial() ; SetMaterialTexture(material, GetColorBuffer(myhudbuffer)) ; TextureFilter(material.GetTexture(), TEXFILTER_SMOOTH) ; Even use shaders on with the material too.

The vegetation performance increase sounds promising. Have you approached it in a similar way to your lighting optimisation? I must say though, vegetation rendering speed hasn't been a big issue for us, nothing that really high fill rates wouldn't fix. Really looking forward to collisions being added to the mix. I'll scratch my head over what to do about the corn. Probably best mask it with something else and have it go at a near range. I spend the day examining the issue of detailed objects "vibrating" or "z fighting" like crazy at camera positions like Vec3(10000,2,10000) and beyond. What I did was create a new world, a cockpit_world just for the cockpit, it needs it's own space to prevent intrusion by Main.world objects. Setting the camera range for the cockpit_world to something really close (near range 1, far rage 20) didn't help much, it seems just as bad. So I can only conclude that this vibration is simply down to floating point errors at these distances. Consider that some buttons are offset from their surface by 0.05 world units. Scaling the cockpit to a factor of 20 pretty much eliminated *all* traces of the problem. Great....make it 20 times bigger and move the thing 20 times further away. However, I've no idea how to match up main_world shadows+lighting with the cockpit_world (on the gigantor cockpit). The other thing I tried was having the cockpit in it's own world at 0,0,0 and matching the camera moves to it, which also worked but the same problem again. How to match up lighting from one world to another spatially offset. Heh, video games, "some assembly required".

He's really sweet. Looks like the sort of game my kids would enjoy, whacking bugs over the head with a giant bat. Repeatedly.

That's really sound advice. Never thought to tint ambient light. After having a little go with what you suggested it really improved the feel of the landscape. I'll link some images of current wip. We've been trying to improve the vegetation look too. Taking the auto-generated billboards and applying a little shading to the bottom of the texture... The fields are pretty nice up close, the billboard not so good. Maybe matching the ground colour to the field would mask that, colour tinting is not an option though. I'm getting happier with the results, for a huge map (remember this is 40x40km) there are 8 such zones. The load times are not too bad, around a min and a half. In our game there's no map swapping as you're persistantly there, all game options and mission planning is done on the ground using objects you interact with, whiteboards and projector screens in tents that have an offscreen buffer mapped to them. Seems to work quite well. Auto generated vegetation cover, the editor will crash doing a terrain this big however we found setting the desity to 35 worked. So lower the density, the less memory allocated I guess. The auto generated veg layer doubled the load time and added a 60mb data file. So we took that out. It's too much just for a thin scattering of scrub over the hills. A procedural routine to throw grass/rocks down on certain texture layers would be way more efficient.