TFX on a PiStorm32

[alexh]

Karlos says, double buffering in FastRAM should get approx 32 FPS if the game is not CPU limited? The limitation being by the copy speed of the 6bpl screen from FastRAM to ChipRAM?

The 680x0 CPU in PiStorm32 running Emu68 is significantly faster than any PC of the day.

[Karlos]

Originally Posted by alexh

Karlos says, double buffering in FastRAM should get approx 32 FPS if the game is not CPU limited? The limitation being by the copy speed of the 6bpl screen from FastRAM to ChipRAM?

The 680x0 CPU in PiStorm32 running Emu68 is significantly faster than any PC of the day.

CPU speed definitely should not be a factor. I assumed, being a PC port, the game uses some form of C2P. Perhaps it uses some other approach that's more dependent on R/W access to chip memory.

If the game runs fine in UAE, where chip memory access speed penalty can be eliminated, then it's almost certainly something like that.

[tomcat666]

Originally Posted by jotd

so all has been done to make the game as fast as possible.

Are you sure. Authors of Pistorm's FW have optimised it now to hit the theoretical MAX of chip ram write transfer rate:





Yes, that is the max amiga's chip ram is capable of, but we still get very low refresh rates and when I run the performance test inside the TFX configuration utility I get VERY slow transfer rates of 1.4Mb/s , while the system is actually capable of transfering 7Mb to chip ram:



I wonder if the game ever run smooth on ANY accelerator ?

[alexh]

I think it has to do 32-bit long word access to get 7mbs

[Karlos]

The speed of TFX leads me to believe there's something fundamentally wrong with it on the Amiga I doubt that it's CPU bound given how the PiStorm utterly crushes other CPU bound tasks.

I'd be looking for artificial frame caps, dodgy game timer code, trying to be clever with interrupts or something else like that.

[sokolovic]

Originally Posted by Karlos

The speed of TFX leads me to believe there's something fundamentally wrong with it on the Amiga I doubt that it's CPU bound given how the PiStorm utterly crushes other CPU bound tasks.

I'd be looking for artificial frame caps, dodgy game timer code, trying to be clever with interrupts or something else like that.

If the source code is available maybe you could check it like you've done for AB3D : TKG

[Karlos]

First, and most obviously, how does it perform under UAE,and which emulation parameters affect performance most strongly?

[tomcat666]

Originally Posted by Karlos

First, and most obviously, how does it perform under UAE,and which emulation parameters affect performance most strongly?

On UAE it is fast as it can get But WinUAE has chip ram speed on the max... not sure if one can lower chip ram speed to be the same as on A1200 ? Config test on WinUAE (very unrealistic chip ram speed )

[Karlos]

Well, that tells us something about what's wrong with it. What happens if you use cycle exact mode? I believe memory delays are modelled on 020+


I've not read all the threads around tfx but my guess is, it's got data in chip ram that shouldn't be there.

[tomcat666]

Originally Posted by Karlos

Well, that tells us something about what's wrong with it. What happens if you use cycle exact mode? I believe memory delays are modelled on 020+


I've not read all the threads around tfx but my guess is, it's got data in chip ram that shouldn't be there.

Yes, it is even worse with WinUAE and Cycle Exact mode than with pistorm32 It gets around 430Kbytes/s even with the fastest CPU possible...

[Karlos]

This sounds like a job for someone with a good disassembler/reassembler suite. The mis-located data could be almost anything, it could be lookup tables, meshes, whatever. The only thing that should be in chip ram is the on screen graphics and sounds (assuming it just uses vanilla Paula playback).

Lol, I must be going senile. I said the same thing a few posts further up.

[jotd]

The latest version of TFX needs data in chipmem (bad hunk merging), but it could probably be relocated in fastmem, with exceptions done for copperlists, ... Not really a big job.

But not all executables have this particular issue. For instance the 040 compatible one (the one which has symbols) is okay.

[Reynolds]

I wonder why never an RTG version was released. It would solve certain issues for sure, including low bandwith of Chipram.

[jotd]

very few games had a RTG version... Devs targetted a wide audience. TFX can run on a 68020...

[Reynolds]

I know that but nowadays when Chip ram is more likely a bottleneck and several rtg based configs are all around it would worth it to release one... not all games really deserves an RTG versions, but something with this gfx-environment would deserve one. If I compare RTG vs AGA in games like Doom and other fps ports, framerate is significantly better on RTG, due to the obvious reason of the advantages of the gfx cards.
But this is just an idea of mine.

[alexh]

The Amiga source code is lost. Arguably the game was never completed (certainly never sold). I imagine shoe-horning RTG back into a pre-compiled binary isn't trivial.

As to why they never did it back in the day... because RTG cost the equivalent of £1000+

[Reynolds]

AFAIK there was a pack of new executables a few years(?) back, so I presume someone still has the codes. But that needs to be checked to be sure.

Yes, noone ever believed that RTG will be so common as nowdays.

[alexh]

Originally Posted by Reynolds

AFAIK there was a pack of new executables a few years(?) back, so I presume someone still has the codes. But that needs to be checked to be sure.

There is another thread here that JOTD did as he examined all the files and determined why the newer ones crash and the older ones don't.

The source code was never released.

[Angus]

Originally Posted by jotd

code is already running in fast ram. Only data segment is in chip for some version.

Is that the same thing happening with Digital Integration's Tornado?

[jotd]

nope. Tornado is full fastmem. It's just too ambitious.