65 – To the tech demo mobile

Finally, I managed to solve the problems that I was having with buffers. I ended up with an extremely complex pooling and life cycle management system for these buffers that still was not enough and did not cover all the cases, so occasionally the game would crash. I needed to create an even more complex system to solve it. I'm sorry, but there are some things that I just won't do! That's what she said!

So I ended up scratching everything and went with a brute force approach. I need the complex system to fool Irrlicht into doing something I wanted for which it had no support. And since this workaround/hack was both to complex and did not work too well, I ended up doing the only other logical thing: modify Irrlicht sources! This raises an interesting issue with licenses: Irrlicht has a permissive license that allows me to modify it and I am using dynamic linking, but this does not matter because thanks to the... "magic" of C++ the Irrlicht DLL was not modified. I do not mean that I recompiled and ended up with the same binary. I did not recompile. I modified the sources but I did not recompile Irrlicht and am running and out of the box Irrlicht. I can imagine the copyright dispute. Did I modify the sources? Yes? Is it derived software? Yes. Do I have binary evidence for this modification? No. As I said for years, current licenses are too vague and incomplete, plus a real hassle for non-lawyer folk to decipher.

I also fixed the memory leaks, except for 4. I still have 4 memory leaks, meaning that exactly 4 blocks get allocated and are never freed. I'll fix this, but this is not a real issue.

Here is a screenshot with a distant view of a field full of different objects with different colors:

Color is not a global property for all objects. The performance is still good but lower than before. The scene is saturated with a large number of high poly meshes that abide by the 64k rule so their number is bigger than before. Edit: and because I am stupid and had v-sync on for those screenshots. Anyway, performance is lower under this higher strain. No real game situation should have such a density of objects and at this view point LOD switching kicks in. Actually, this is implemented and used in the above screenshot, but because I only have low LOD models for some of the objects and did not want to differentiate between objects that have all LOD levels or not (a temporary differentiation because all objects will be required to have two LOD levels), I made it that the high LOD is used for low LOD rendering too. As you move around the map, LOD levels are changed dynamically, but because both sets are identical this does not reduce the strain on the GPU. A good stress test. Because of the high work load of high LOD meshes, camera movement encounters some small snags in debug mode. Normally, most of the LOD switching is reserved for changing low to high, not high to high, but now we get the same mesh recreated with the same detail taking up unnecessary CPU time. In optimal mode snags are gone and once all low models are in switching should be super fast.

Here is a closer view point on the scene:

As you can see objects are rendered with full detail and this becomes more and more apparent the closer you get. Even from this distance you can tell that there are metal plates on the table (not the middle circle, that is the pattern; the plates are more to the south). I won't zoom in even closer because then you'll notice that not all the objects are fully modeled :).

And because of my v-sync blooper, here is comparable screen where FPS goes a little over 60:

And one where object density is not that high:

And a final one with very low object density (but still at high LOD) so you can get an idea how the performance scales:

Now I can sit all day and wallow in ignorance by just testing on the computers I have access to, but in order to get some real results I need a large number of people with whatever setup they have to test if it runs for them. So I'll be doing official tech demos a few posts from now.

Now you may have been spoiled by what big companies call tech demos of public betas: often these are a little more than glorified publicity stunts created to generate hype and get you excited and interested in the game. But not with me. My tech demos will be real tech demos, where things will break and blow up (DISCALIMER: THINGS WILL ACTUALLY NOT BLOW UP. NO FIRE HAZARD HERE). Each tech demo will have a strict agenda of things I need to test to assure some general compatibility with the computers out there. You won't get hyped for the game by trying the tech demos because all gameplay (at least in the first tech demos) will be striped out. If some gameplay remains in the first version this is considered a bug and I expect a bug report. Which brings me to the main point: you will have no reason to download and try the first tech demos unless you are curious to see if the engine runs on your computer. If you are curious and willing to help, a very short report on you setup and what FPS you got, how smooth it was and if it seemed to work like intended would be greatly appreciated.

I'll post more info about the goals for the tech demo as it gets closer. To better facilitate the process I created this launcher for the game:

The empty rectangle is where the log will go. Very old school! Pressing "Launch Editor" will launch the editor you know and love. The editor will probably not make it into tech demo 1 which will be strictly a "will it run/blend" scenario, but by TD2-3 it will be included. The editor will be always free (this is not a legally binding guarantee :P) so it won't be a premium or what not feature. Since it is a custom tool I'm thinking it will do the most amount of good if it has maximal availability.

The options button will open the game options, where you will choose resolution and other setting. An in game options panel will also be available, but for starters the options that need the reinitialization of the entire game context (all the 3D stuff) will be only changeable from the launcher (or the INI file). This is not the most consumer friendly solution, but it is practical. The options dialog should be done by the next post.