Category: gsb2

These DrawPrimUP calls are a pain, must find a way to reduce those…

 

 

 

May have to do some reading to work out the significance of some of this, but draw calls is definitely too high…

This is a screenshot of GSB2 (click to enlarge). Nothing particularly impressive, but when looking at it, and then stepping into code to see whats going on, it’s clear that the engine is kinda pushing against limits for hardware on laptops etc (This is with graphical detail at maximum, so that will be less of an issue eventually).

I think that ultimately, I’m making too many draw calls, and lesser hardware can’t handle it. because of the nature of the engine, those draw calls are vastly higher than the amount of actual objects on screen, because there is depth, and lightmaps and other trickery that magnifies the effect of, for example, just rendering a single sprite of a fighter ship. That fighter ship probably involves more like a dozen draw calls :(. In the scene shown, we have 915 3D objects (most are not onscreen), 266 depth objects, 648 lightmap objects, 89 ‘splats’, 372 effects and 216 saturated effects. Thats clearly a lot :(

I’ve seen the game do 5,000 or more draw calls in one frame, and thats kinda bad, so the way I see it my approach to optimization could take various paths:

1) degrade some less important stuff when we exceed a certain number of calls / drop below 60 FPS. Not ideal, but a brute force way to fix it.

2) Further optimize some stuff that is currently done in single draw calls, like parts of the GUI, to get the general number of calls down.

3) Slot in a layer between my current engine and DirectX, which caches states yada, and collapses draw calls into fewer calls where the texture/shader/render states are the same.

Theoretically 3) is vastly better than the rest, but I fear that I’m adding another ‘layer’ here which could in fact be slower, and also that I’m keeping poorly optimized code and fixing it after the event. After all, the best solutions to speedups are always algorithmic, not close-to-the-metal; tweaking. However, another benefit of 3) would be that such an abstraction layer makes the job of porting the game slightly easier. I’m considering implementing it anyway, so I can at least see how often such a ‘collapse’ of draw calls can happen. In other words, would this reduce the count by 5% or 90%?

So that means replacing the DrawPrimitve() calls with a macro, maintaining a cache of the render states (or maybe just letting any RS change flush the buffer? and just (for now) initially keeping track of the collapsible draw calls. I’m going to give that a go… Or maybe I should see what the hell all those objects are first…

Getting explosions right is HARD. Explosions are (obviously) a big part of Gratuitous Space Battles 2, and I want the GBS2 ones to be better than GBS1 by a noticeable margin. They already are, but I’m aiming for greater heights. Currently the explosions look like this:

And this: (smaller ones)

Which is ‘ok’, but I’d like them to be better, which means spending a lot of time looking at video of space battles (oh the things I have to suffer), freeze framing, stroking my chin and looking at code. There are a number of things people assume about this task which I’ve found not to be true.

Assumption #1: You can do it all on the graphics card. Not so, because different people have different cards, whose capabilities may vary dramatically. I want GSB2 to be playable on a standard laptop, not demand a DX11 driver and card. Plus a lot of these techniques assume Directx11, and you then need a DX9 backup for people who still have windows XP anyway so….

Assumption #2: it’s simply about the number of particles. Not so. I have a fairly efficient particle system that can handle lots, but I have found more does not always equal better. In short, it doesn’t seem to be how many particles you have, but how they interact, what textures they use, and how they move. Render modes (additive vs normal) also factors in a lot.

Generally, my approach has been to have a bunch of particle emitters all clustered together into one explosion. I have some big black clouds that build slowly, some firey small particles that fade out quickly (additive ones), some flame-texture particles that are additive, and some not additive, and I render them in a deliberate order and it looks like the stuff you see above, which is fine, up to a point.

The thing I haven’t managed to really convey is the ‘billowing’ effect of an explosion. Here are some of my reference images…

This sort of thing is very hard to get right ‘in-motion’ because it involves some 3D movement of frankly millions of particles, so obviously the first question is how on earth to ‘cheat at it’ and get it looking vaguely right. In Gratuitous Stank Battles I tried a complex system where particles had #heat’ assigned to them, and cross-faded between white hot to black smoke (and different textures) over time. it looked ok, but probably not enough difference to warrant a bucket of extra code that was associated with it.

I am starting to think that decent explosions are 90% physics, 10% graphics. What I need is some more complex control over the movement of individual particles, rather than just more of them. With the explosion at the bottom, I’m thinking that there are a bunch of different ‘focal points’ of the explosion, different ‘billow-centers’, if you will. There has obviously been a central ‘bang’ and this has ‘spawned’ a bunch of airborne ‘flame emitters’ which continue to create new burst of flames which are created, balloon up, and then down and dissipate.

Currently I have zero support for such a system. An explosion is a single event, which may have a bunch of timed emitters with it, but it has a single focal point. Secondly, a particle has a single growth variable, which means it either is spawned and gets bigger over time, or it gets smaller over time. What I may need is the capacity to associate a timed sinewave with the size of a particle.

So my latest explosion todo list (fun stuff I do when I’m not busy) is something like this…

Add support to particle configs for a ‘sinewave-based’ growth variable, with starting size, max size and duration.

Create a new class of object called a GUI_SubExplosion, which can be spawned by an explosion and drift off from the central point slowly over time. Have that sub-explosion itself contain a list of particle emitters that it manages.

Should be worth a try anyway… In the meantime here is the latest big pharma blog video. and a nice article on showmethegames about banished.