Fast Red Zone and other fastmem-relocated projects

[jotd]

Zoned a fastmem relocated whd beta for Fighter Bomber for everyone to test.

paraj says that it could be improved even more by doing the same processing as he did for Killing Cloud, this hasn't been done yet.

Issues:

- needs NOCACHE else there are gfx glitches (but it's slower)
- even with NOCACHE there are gfx glitches
- maybe sound is bogus

otherwise okay

[Reynolds]

Tried on my A1200s but on both it failed to load. Will make shots about them.

In the meantime I've tried out Killing Cloud and Flight of the Intruder.

[ Show youtube player ]

[ Show youtube player ]

[jotd]

paraj could start Fighter Bomber on his 060. He's working on a speedup right now

So Killing Cloud looks more playable at least
For Flight of the Intruder I'm not going to do anything 1) Psygore slave 2) probably already running in fastmem

[paraj]

Originally Posted by jotd

paraj could start Fighter Bomber on his 060. He's working on a speedup right now

I may not be able to contribute much as you've already done most of the work with the relocation. A big speedup in killing cloud came from moving the stacks to fast ram, but fighter bomber seems to run all the time in supervisor mode and the "LEA lb_00500,A7" in the beginning already covers that.


Some FPS figures from my 060 from free flight start at Mt. Rushmore:

running from chip:              1.34
running from chip (fmode=3):    1.42
running from fast:              4.53
running from fast (fmode=3)     4.98

We'll have to see how far this can go with reasonable effort

[Galahad/FLT]

Fighter Bomber is mostly blitter drawn isn't it?

Or did they just modify the original ST cpu code?

[paraj]

Originally Posted by Galahad/FLT

Fighter Bomber is mostly blitter drawn isn't it?

Or did they just modify the original ST cpu code?

Haven't dug too much into FB yet, but yes, I think it's mostly blitter drawn. No idea how the original ST code works.

Assuming it works like killing cloud it uses the blitter in an unconventional way for polygon drawing. The CPU is used to generate an edge list for the polygon and then the blitter is used to fill it by copying in parts of a pre-rendered interleaved colored row with bltcon0=$07ca (i.e. the source data is always constant and the blit height is always 4=number of bitplanes).

The hope was that this could be done faster (on a 060) by avoid reading from the colored row data in chip mem using the CPU. In my offline tests it is (slightly) faster, but at least for killing cloud the rendered spans a quite short so there isn't much gain. What really helped there was not having most of the data in chipmem.


If I had infinite time to fix things, I think a good option for both games would be to use the CPU to render to a fastram buffer and only copy it later.

[jotd]

Originally Posted by paraj

Some FPS figures from my 060 from free flight start at Mt. Rushmore:

running from chip: 1.34
running from chip (fmode=3): 1.42
running from fast: 4.53
running from fast (fmode=3) 4.98

What? 1.3 FPS running from chip? that game is a joke! How many FPS with an A500/68000???

We'll have to see how far this can go with reasonable effort

Yes, stay reasonable. It must remain a hobby and a pleasure, with challenge

[Reynolds]

Originally Posted by jotd

What? 1.3 FPS running from chip? that game is a joke! How many FPS with an A500/68000???

Joke, especially in comparison with Combat Air Patrol on an A500. And albeit it could be a really good game, the lack of fps just kills that too. Vector Grafix should have had to get the name Slideshow grafix instead, way back.

Microprose's F-15 SE II and Knights of the sky are more detailed and faster games. Fighter Bomber has some magic still as I'd love to play it. Maybe it is just pure nostalgia as that was the very first simulation where I had some success

[Reynolds]

Originally Posted by jotd

paraj could start Fighter Bomber on his 060. He's working on a speedup right now

So Killing Cloud looks more playable at least
For Flight of the Intruder I'm not going to do anything 1) Psygore slave 2) probably already running in fastmem

Killing Cloud definitely runs faster than before. Dunno if it would be ever possible, but I wonder how it would perform with Frontier's code.
Also, besides with FPS count a polygon counter would be interesting. In Frontier there are several small details like clock on a church's tower, but also in KC there are detailed buildings with chinese style rooftops, chimneys, etc.

Regarding Frontier, I got a Quit/Restart/Coredump window right after the game was started on one machine, while on the other the WHDLoad complained about disk.1 being XPK compressed. Will give it a go later, maybe today or tomorrow.

[saimon69]

Originally Posted by jotd

What? 1.3 FPS running from chip? that game is a joke! How many FPS with an A500/68000???

With your routines not sure but i remember i did try figher bomber on my 500 and the Mount Rushmore scene was in frames per MINUTE

[paraj]

Some more fighter bomber findings. The game actually uses the CPU to draw quite a bit of stuff (mostly the HUD ), but it appears that unlike killing cloud it's not limited by drawing speed. Disabling all CPU rendering and actual blitting only improved fps by 1-2!!

Did some very basic profiling, and the SMC fixes (which currently just means flushing the cache an insane amount of times) probably account for maybe ~30% of the time spent. Trying to see where the rest of it goes, and hoping it's not just death by a thousand cuts. With some luck we can find a few hot spots to improve/rewrite, but let's see...

[jotd]

I have written a simple profiler that works really good for the invested time (like 1 hour ) BTW what are you using?

Maybe flushing cache isn't the thing to do in some cases, better use indirect addressing instead for instance / traps to get the opcode and interpret it. Flushcache could mean first check CPU then maybe use a trap and so on, a lot of overhead depending on the frequency of the calls.

I fixed a few SMC issues in the past, and I tried NOT to use flushcache that's cheating But that makes fixes much harder.

[paraj]

Not sure I've seen your profiler, might be much easier I just quickly hacked something together by modifying WinUAE. Sampling what the program counter is do_cycles_slow and outputting the results to console regularly. Probably not highly accurate, but gives a good idea of where time is spent. Used the chip only version for easier referencing with the disassembly.

Might also do something similar to see if there are any crucial data structures that should/can be moved to fast ram. I did that for killing cloud to see where the CPU was often accessing chip ram.

[jotd]

hacking WinUAE is way more powerful, that's true. I'd like to know which longwords are accessed as words to detect wrong relocs for instance. Memory watchpoints filtered with size info, in a nutshell

My profiler can run on an amiga. It hooks on VBL (trivial on kickemu games) and logs PC each VBlank interrupt (that's how gprof works, more or less). Then a post-processing python script tries to group the addresses.

[paraj]

Originally Posted by jotd

hacking WinUAE is way more powerful, that's true. I'd like to know which longwords are accessed as words to detect wrong relocs for instance. Memory watchpoints filtered with size info, in a nutshell

I guess a scripting interface for WinUAE debugging stuff would be useful. Might be a nice project for the next pandemic lockdown

Originally Posted by jotd

My profiler can run on an amiga. It hooks on VBL (trivial on kickemu games) and logs PC each VBlank interrupt (that's how gprof works, more or less). Then a post-processing python script tries to group the addresses.

Nice, and would also work on real HW (where it's more interesting) for some games I guess a CIA-timer could be used for better precision, though it obviously changes timing...


For fighter bomber, I think my immediate plan is to reduce the number of cache flushes/use of trap in key areas. Eliminating one made did give like ~10% fps (4.98->5.53) so I think that's the way to go for now.

[jotd]

[QUOTE=paraj;1580104]I guess a scripting interface for WinUAE debugging stuff would be useful. Might be a nice project for the next pandemic lockdown

I'd rather debug by hand than getting another lockdown...

I don't master CIA interrupts but yes, of course. On real hardware you'd still need HRTMon to dump the data. Or a special key in the slave to do the same.

That's very cool. 5.5 FPS wow the devs were visionaires who knew that we could reach that crazy framerate in 2022 with 060+fastmem!


But good result anyways. Keep it up!!!

[jotd]

I asked ChatGPT about how to improve 3D amiga games and it's rather disappointing

how to increase framerate of 3D amiga games running from chipmem ?

I'm sorry, but I'm not able to browse the internet, so I don't have access to information about specific methods for increasing the frame rate of 3D Amiga games running from chipmem. However, there are a few general tips you can try that may help improve the performance of your games:

Make sure you have the latest version of the game and the latest version of the operating system installed.
Check the game's settings and make sure it is set to run in the highest performance mode possible.
Close any other programs or processes that may be running in the background, as these can consume system resources and slow down the game.
If you have multiple applications open, try to run the game on its own, without any other programs running at the same time.
If you are using a controller, make sure it is properly configured and working correctly.
If the game is running slowly on your computer, you may need to upgrade your hardware to improve performance. This could include upgrading your CPU, GPU, or RAM.

I hope these tips help improve the performance of your 3D Amiga games. Good luck!

Well done bot!

[Reynolds]

Originally Posted by jotd

I asked ChatGPT about how to improve 3D amiga games and it's rather disappointing



Well done bot!

[paraj]

The next version will know to "simply" relocate the code to fast ram after reading this thread

FPS is now at 10 after eliminating most of the cache flushes. There were quite a few of them (more than 1200) each frame since it's using SMC for silly stuff in critical loops. Will see if there are any more easy optimization opportunities, but we're probably close to the point where focus should be on fixing for the remaining problems.

[jotd]

that's very good! There's still a problem when rolling the plane. Happens only when relocated so must be some vicious shit. I'll try to find the issue.

I don't know if that game deserves so much work but...