- jedd_no_rway.PNG (589.05 KiB) Viewed 1360 times
- sortfix.PNG (181.26 KiB) Viewed 1360 times
That missing runway at Jeddah
That missing runway at Jeddah
Regarding that runway that can only be seen at certain angles:
...I was looking at that old Virtek documentation, and I can see that they used a 'sortfix' command to handle this, but I don't know if that would help TFXplorer at all.
Re: That missing runway at Jeddah
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:
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.
Re: That missing runway at Jeddah
The first word of the 3 file looks like it's 'parameter n' and maybe the 0093 Opcode is the actual command.
It's fairly obvious that they used this for TAW even though Virtek and DID had parted ways some years before that document came out.
I suspected it wouldn't be relevant for TFXplorer, but thanks for the explanation (probably again) of how you go about it.
It's fairly obvious that they used this for TAW even though Virtek and DID had parted ways some years before that document came out.
I suspected it wouldn't be relevant for TFXplorer, but thanks for the explanation (probably again) of how you go about it.