TFX on a PiStorm32

[Captain_ Kal]

There is a Japanese version of TFX, for psx. If anyone is interested in it, I can upload it to the Zone!!

[Karlos]

Originally Posted by paraj

Sorry, yes, that was for Tornado (not sure how I got them mixed up).

TFX uses the blitter a bit, but not too much. It also plots directly in planar mode using the CPU but is clearly optimized to reduce the number of chip accesses (always doing longword accesses). This is OK, but I think it would be faster if it just operated on a fast ram buffer and copied that to chip mem (maybe only parts that have been changed).

TFX.040 includes quite a number of symbols, so it's not too hard to figure out what is going on.

How is it doing the plotting though? Plotting any horizontal span of pixels (except where all are the same) is going to require reading the long from chip, setting/clearing the appropriate bits and the writing the updated long back to chip, as many times as there are planes.

This is actually worse than c2p, where you have the simplest possible byte pet pixel plotting to your chunky buffer followed by the C2P step which is a very mature proposition today.

If TFX is doing it's various shaded polygon plotting directly to chip ram in the planar domain I'm not surprised it crawls.

[paraj]

Originally Posted by Karlos

How is it doing the plotting though? Plotting any horizontal span of pixels (except where all are the same) is going to require reading the long from chip, setting/clearing the appropriate bits and the writing the updated long back to chip, as many times as there are planes.

This is actually worse than c2p, where you have the simplest possible byte pet pixel plotting to your chunky buffer followed by the C2P step which is a very mature proposition today.

If TFX is doing it's various shaded polygon plotting directly to chip ram in the planar domain I'm not surprised it crawls.

Yes, it's as bad as you suspect.

Flat polys:

Short spans (and/or depending on color):

        AND.L   D6,(-24000,A1)
        AND.L   D6,(-16000,A1)
        AND.L   D6,(-8000,A1)
        OR.L    D2,(A1)
        OR.L    D2,(8000,A1)
        OR.L    D2,(16000,A1)
        OR.L    D2,(24000,A1)
        OR.L    D2,(32000,A1)
        JMP     (A6)

Longer spans (middle MOVE.L's are unrolled)

        MOVE.W  #$e0c0,D2
        CMP.W   #$0020,D4
        BEQ.W   LAB_3569
        ADD.W   D1,D1
LAB_355E:
        SUBX.L  D6,D6
        BFINS   D6,(A1){D3:D4}
        MOVE.L  D6,(4,A1)
        MOVE.L  D6,(8,A1)
        BFINS   D6,(12,A1){0:D5}
        ADDA.W  D2,A1
        ADD.W   D1,D1
        BNE.S   LAB_355E
        JMP     (A6)

For gouraud shaded and textured polys it first renders the scanline to a chunky buffer, and then converts it using code that looks like:

        BFINS   D3,D4{D1:1} ; D1 = bit position
        LSR.B   #1,D3       ; D3 = chunky pixel
        BFINS   D3,D5{D1:1}
        LSR.B   #1,D3
    ; repeat for each plane

Loading/saving a longword when it's every 32 pixels (with special handling for the first and last longword).

Another hot function is a sprite blitting function that uses the CPU (for sprites not in chip RAM, or if the source pointer isn't word-aligned (???)).

[Karlos]

Is the code in a buildable state?

[jotd]

I suppose the disassembly re-assembles to something that runs

[paraj]

I mostly looked at it in Ghidra, and just threw it through IRA. The output from that produces an invalid relocation from:

    LEA    (PlotColour.L,ZPC,D0.W),A3 ;4cfa4: 47fb01b000099edc

and a suspicious warning (looks like it's disassembled some data):

warning 2007 in line 152864 of "TFX.040.s": displacement at bad position
>       CMPA.W  (ZA2,A3.W*8,-1203914524.L),A3 ;7116e: b6f2b797b83db8e4

Probably wouldn't be too much work to fix stuff like that, but you'd want to make sure that it assembles to something that when loaded is the same before making any changes (unlike absolute binaries this comparison is slightly more tricky).

After that you'd have ~100K lines of uncommented assembly code (symbols help a lot, sure). Maybe easier to do a surgical strike with whdload patching. Most drawing seems to go through a few key functions (_MaskSprite/ScanFillDown etc.) that could be targeted without a complete rebuild. Though other parts could probably do with some optimizations as well.

If you feel like taking on the job of revamping another huge assembly source base (this time without most labels), I'll gladly give more hints

[Karlos]

If you build it*, they will come**.


*As in get it into buildable state.
** Terms and conditions apply.

There must be a few demo coders on this forum that can make flat and shaded polygons fly

[paraj]

Feel like I'm being nerd sniped into looking at it But as usual, I've only played the game for 2 minutes, and don't really have any affinity towards it.

Think course of action (still not saying I'd be involved) would be:
1. Stay bitplane based for now.
2. Get rid of all blitter usage. Think sprite drawing can already be easily replaced by existing CPU function. Replace blitter based line drawing routine by standard Bresnham one (probably not called much, so OK if a bit slow).
3. Move screen buffer to fast RAM, and copy it to chip RAM only when flipping.
4. This should be fast enough for PIstorm. Profit.
5. Get roped into further improvements because it's not fast on "real" 040/060's.
6. Draw to chunky buffer and do normal C2P stuff
7. Don't profit because you've spent time optimizing a game nobody plays, and could have made a fortune marketing a "web3.0" shitcoin instead.

[Karlos]

Nerd snipe someone, moi?

[tomcat666]

Originally Posted by paraj

7. Don't profit because you've spent time optimizing a game nobody plays, and could have made a fortune marketing a "web3.0" shitcoin instead.

I think TFX is actually the most advanced Flight Simulator on amiga
"In 1994, PC Gamer UK named TFX the 26th best computer game of all time. The editors called it "one of the best flight sims out on the PC and, with a bit of effort, a hugely playable game"."

Would certainly be nice to see it play with nice FPS on our miggy... even if it takes a pistorm or vampire to do it.

[Seiya]

yes, esthetically more advanced, but for gameplay the best is, imho, Combat Air Patrol.

[Karlos]

Has anyone tried TFX for PC in an emulator on PiStorm? I bet PCTask or PCx would manage it fine. The Pi4 is already much faster than any desktop 68K or x86 of the era.

[tomcat666]

Originally Posted by Karlos

Has anyone tried TFX for PC in an emulator on PiStorm? I bet PCTask or PCx would manage it fine. The Pi4 is already much faster than any desktop 68K or x86 of the era.

Yes, unfortunetly the JIT of Emu68 is not really very well suited for dynamic compilation of PCTask and PCx compatibility is not that high, so most of the things don't run that well. Couldn't get TFX to run under those two. In DOSBox it runs but it is very slow (slower than Amiga version).

[Karlos]

What about running PCTask as an interpreter? Depending on the emergent effects of many factors, this might be faster than the JIT.

[tomcat666]

Originally Posted by Karlos

What about running PCTask as an interpreter? Depending on the emergent effects of many factors, this might be faster than the JIT.

That almost never works for some reason. It is WAY faster when it works, but normally none of the memory extenders (like dos4gw) work with it. Don't think I got any serious game working with the interpreter version of PCTask.

[Seiya]

Originally Posted by Captain_ Kal

There is a Japanese version of TFX, for psx. If anyone is interested in it, I can upload it to the Zone!!

i'm interested

[Karlos]

You know, given the game renders flat and Gouraud polygons only, it's an ideal target for a hardware rasteriser...

[Angus]

Originally Posted by Seiya

yes, esthetically more advanced, but for gameplay the best is, imho, Combat Air Patrol.

Interesting. For some reason, I never quite got into it. Possibly I was too impatient. Any chance you could say what it's appeal was?

[mschulz]

Originally Posted by paraj

Yes, it's as bad as you suspect.

…

Another hot function is a sprite blitting function that uses the CPU (for sprites not in chip RAM, or if the source pointer isn't word-aligned (???)).

Short spans are horrible in terms of performance (read/modify/write for every plane of every pixel) just as is the gouraud shaded conversion. Long spans are better, but combination of this all is a perfect way to waste at least of 50% bandwidth of chip memory.

Since you look at disassembly - can you have a look if maybe tfx is using data cache on chip memory? If it had did that in copy back mode and if it had flushed it regularly then it would have a chance to work reasonably good after enabling data cache for chip in Emu68 …

[Seiya]

Originally Posted by Angus

Interesting. For some reason, I never quite got into it. Possibly I was too impatient. Any chance you could say what it's appeal was?

i like the system flight, the general graphics even if simple polygon and flat world, but at maximun detail your aircraft has weapon visibile. But a part graphics, general gameplay.

CAP is released also on PC with mega texture and scenery mountains hils very realistic like modern games, but Amiga version is much much much better.