TFX on a PiStorm32

[Seiya]

the game is slow mainly for the numbers of triangles of every polygons. Then Amiga hardware is not ideal for this type of games that are developed in chunky also on Amiga that is planar.
If TFX was developed in Planar (like Virtual GP) it would be very fast and smoth on 68030.

[Karlos]

Originally Posted by Seiya

the game is slow mainly for the numbers of triangles of every polygons. Then Amiga hardware is not ideal for this type of games that are developed in chunky also on Amiga that is planar.
If TFX was developed in Planar (like Virtual GP) it would be very fast and smoth on 68030.

It was developed in planar. The basic triangles are directly plotted to bitplanes. Paraj has improved the performance by moving the bitplanes the engine renders to into fast ram and copying them back to chip ram for display.

Given that most c2p routines today hit copyspeed, there would likely be no loss in performance rewriting the polygon rendering as chunky. In fact, it may run faster because generating pixels, especially when shaded and texture becomes that much easier.

[alexh]

Originally Posted by Seiya

Amiga hardware is not ideal for this type of games that are developed in chunky also on Amiga that is planar. If TFX was developed in Planar (like Virtual GP) it would be very fast and smooth on 68030.

Interesting interpretation. Did you read the whole thread? TFX WAS developed "in Planar" which is why it is still slower than it could be. Multi-colour 3D rasterisation does not lend itself to planar because you have to do small read-modify-writes.

[viddi]

Very fast on my V1200!

Thank you!!

[coder76]

Originally Posted by Karlos

The horizon gradient is properly perpendicular to the horizon. How many blitter operations to fill the horizon at a 45 degree roll angle?

Depends on the detail level, how thick and how many color gradient colors you have in horizon. If you use blitter fill mode, its like treating each of these areas like a simple polygon. If you have 25 FPS as frame rate you can spend two entire frames on the horizon drawing with blitter, should be enough time.

[sokolovic]

Isn't it the technique used in Guardian ?

[Karlos]

A point that has been missed here is that the game wasn't written for the Amiga. It was written for the PC, with an Amiga conversion. I don't think this approach lends itself to having the most tightly optimised blitter rendering.

And even if it did, we'd all still be complaining it was too slow on accelerated machines. There's a reason everyone uses tools like FBlit on faster non-RTG machines.

[Angus]

Originally Posted by Karlos

A point that has been missed here is that the game wasn't written for the Amiga. It was written for the PC, with an Amiga conversion. I don't think this approach lends itself to having the most tightly optimised blitter rendering.

Much like Tornado which was what, a mid '94 release? So the Amiga's influence was waning with Commodore bankrupt. I called up Digital Integration at the time because I was excited about the forthcoming release and came away with the distinct impression (certainly with the guy I spoke to) that the Amiga version was a bit of a nuisance to them and was unlikely to shine.

I don't know much about FBlit, would it still function within a WHDLoad game?

[jotd]

Originally Posted by Angus

I don't know much about FBlit, would it still function within a WHDLoad game?

no. whdload takes over the system. And FBlit probably patches the OS functions, that most games don't use anyway

[Karlos]

The point about fblit was to illustrate that for faster CPUs, the blitter is just a hindrance.

[paraj]

Lot's of replies, so maybe missed something, but some info.

What I did is (assuming old drawing code isn't enabled):
- Make sure the blitter isn't used at all. This was only in a few places: Line drawing, rectangle filling and sprite blitting in some cases. This meant adding some new CPU replacement functions (that could certainly be optimized).
- At the start of each (in game only) frame I replace the pointer to the screen buffer (originally in chip mem) with one pointing to fast mem. (From the great testing by especially tomcat, I found that this needed to be after keyboard handling that can put up the map/menus).
- Game runs as normal with now all rendering done by CPU (this was already mostly the case)
- When the game wants to present the newly drawn frame I copy the fast buffer to chip mem and update the copper pointer (without waiting for end of frame like the original code, since the displayed frame can't be corrupted by the rendering)

Latest update also has a few extra tweaks for plain 020 version:
- A frequently accessed variable is moved to fast mem
- Frequently used unimplemented 060 integer instructions (32x32->64 mul, 64/32 div) are handled without having to go through exception handler (from previous measurements this saves >3000 cycles each time)

Major caveat: These optimizations were done to benefit very fast Amigas only. I have a real 68060/050 I can test on, and feel fairly confident in my ability to do something for that, so that's my target. PI storm (which was the original challenge naturally benefits as well).

I don't know, and can't test, to what extend these changes matter for better or worse on systems with those CPUs. I'm fairly sure it's a benefit on 040, but doubtful to the extend on 030.

General notes:
- The game doesn't explicitly clear the screen buffer as the complete view is rebuilt every frame
- Code mostly seems fine. Probably 95% C code compiled with a decent compiler, and the handwritten assembly functions are written with care, targeting the right areas.
- Profiling was not easy back then, and like conjectured already, maybe they hadn't come to that point in the development cycle

Considering the hypothetical "why didn't they use C2P"
- Were good C2P routines *that could be used commercially* available when the project started?
- For commercial reasons they probably needed to target low-end 020 systems, and for those I'm not sure a C2P based solution will be faster
- Even if they did realize it would be faster, making that change would require rewriting many functions. While the important functions (polygon filling) could be rewritten quite fast, there's lots of other stuff that I didn't touch like the HUD (text, etc. etc.)
- Maybe there was a bit of 90ies PC mindset (not necessarily from the developers) to release something that could on paper run on ancient machines, but really required a machine that wasn't realized yet, and let Moore's law do it's work (not realizing this wouldn't help).

[Karlos]

Never mind all that, when can I play it on my 1MB OCS A500?!

[sokolovic]

Originally Posted by Karlos

Never mind all that, when can I play it on my 1MB OCS A500?!

1MB Amiga 500 is cheating ! You should ask for a 512Kb version running from floppy disk !

[Karlos]

Originally Posted by sokolovic

1MB Amiga 500 is cheating ! You should ask for a 512Kb version running from floppy disk !

Don't be silly, you need an upgraded system to run a game like this!

[sokolovic]

Originally Posted by Karlos

Don't be silly, you need an upgraded system to run a game like this!

A Megadrive could probably run it flawlessly.

[Karlos]

Reflecting on @paraj longer post, I'm pretty sure efficient software C2P was not a common technique in 1993 or 1994. The first practical example I recall was in Breathless, which was 1995 I think. The technique overall was known and Akiko was doing it in hardware on the CD32, but back when DID was working on TFX it was likely considered too slow for any machine they might be realistically targeting.

It's interesting how such notions change. Looking at TKG, for example, the C2P time is basically an irrelevance on 060. RTG graphics cards aren't faster because they don't skip the C2P, they are faster because they generally have faster write speeds that chip ram. I'm sure if you found an old Zorro II card you could end up with a lower frame rate than on AGA for a fast enough CPU.

[paraj]

Last ditch effort attempt at push for 1 frame on PI storm. In the zone is "TFXAGA_custom3=4_only_test.7z" as description says it ONLY works with custom3=4 (TFX.040). This one also moves sprite buffers to fast ram.

@Karlos: And one of the first thing I remember from the TKG thread was the immediate improvement of replacing the existing C2P with a modern (Kalms) one.

[tomcat666]

Originally Posted by paraj

Last ditch effort attempt at push for 1 frame on PI storm. In the zone is "TFXAGA_custom3=4_only_test.7z" as description says it ONLY works with custom3=4 (TFX.040). This one also moves sprite buffers to fast ram.

Unfortunetly not in 1 frame, but it is a solid 2 frames now when in cockpit view (was flickering between 2 and 3 before), so definetly an improvement.

Video:

[ Show youtube player ]

[Karlos]

Originally Posted by paraj

Last ditch effort attempt at push for 1 frame on PI storm. In the zone is "TFXAGA_custom3=4_only_test.7z" as description says it ONLY works with custom3=4 (TFX.040). This one also moves sprite buffers to fast ram.

@Karlos: And one of the first thing I remember from the TKG thread was the immediate improvement of replacing the existing C2P with a modern (Kalms) one.

Yeah, it really does hit copy speed, or as close to as makes no difference.

[paraj]

Originally Posted by tomcat666

Unfortunetly not in 1 frame, but it is a solid 2 frames now when in cockpit view (was flickering between 2 and 3 before), so definetly an improvement.

Video:

[ Show youtube player ]

Thanks for testing! I'll apply this to all versions (also seems to at least be no worse on 060). Maybe a some more chip writes can be avoided... Might as well exhaust all (simple) opportunities while I'm at it

EDIT: TFXAGA_RC2.7z in the zone (no optimizations, but all versions supported with sprite buffer in fast mem)-