Nailed it 👍 That probably really is the fix! And it nicely explains the distance for the 1st LOD in shape headers (which is always negative and most likely the negated
SORTFIX).
It will be hard, however, to apply it to TFXplorer:
ADF/TAW has a very limited range of sight; something like 15 km or eight terrain tiles. It gathers all tile supershapes in visible range (could be 8 × 4 = 32), then all shapes from these supershapes. This would make roughly 100–200 shapes, plus a few planes.
Then it sorts all these shapes with the help of
SORTFIX and renders them to the screen (hopefully without invalid occlusion).
TFXplorer OTOH has a maximum range of sight of ~100 km. I think it was 49 tiles. That makes for 49 × 25 = 1225 tile supershapes, ~6000 shapes – plus planes and contrails. For distance-based sorting 60 times per second, that’s quite a lot – it leaves a budget of 3.5 GHz / (60 * 6000) = ~9700 cycles per shape for
everything – executing the .3 bytecode, sending the vertices to the GPU … and we’d like to do gameplay/simulation, too!
I think this is the reason I opted out of rendering the whole world sorted and went a pre-computed path through visible tiles instead:
This renders tiles strictly according to their distance (far-to-near). It treats tiles as independent from one another, but that reduces the problem from
“collect + sort 6000 shapes” to
“1225 times sort 1–10 shapes and forget them right away”, which is
a lot easier on the CPU.
Unfortunately, this ignores
SORTFIX of neighboring tiles because they are rendered independent from one another. This ultimately causes Jeddah’s runway to disappear.
To give an impression of the performance problem, in 2015 I changed the path through tiles for rendering from the above picture to this:
This drastically improved temporal locality: If there is a patch of sea, then neighboring sea tiles will be rendered one after another most of time, as opposed to doing a roundtrip along mountains + desert + etc. This utilizes the CPU better, yielding a 20 % performance improvement for the
whole program, including gameplay.
So, due to the nature of my terrain rendering, it is nothing that I can quickly change/fix. Two facts make me optimistic that we will see a fix at some point in the future though:
- At some point, I’d like to re-write our shape renderer and I have a promising way of making it 10× faster. That would leave us more time for doing things right instead of fast.
- With the new API that had been introduced last year, that terrain rendering is contained entirely in the DIDtoUAW F22 extension and changing it would not break other extensions, like Ace Combat 3.