English Amiga Board - View Single Post - Fast Red Zone and other fastmem-relocated projects

jotd · 01 May 2022, 15:30

Anyone remembers the infamous Red Zone by Psygnosis?

Good graphics good sound good intro and awful frame rate? Probably too ambitious on a 68000.

Well, for 17+ years I've been trying to speed that game up for high end amigas, even if I don't particularly like the genre, I always thought that that was a shame that the game had such a low FPS (and Angus repeatedly wanted to bump this subject too)

After analysis, game doesn't use blitter (can be handy but not necessarily for a 3D game) and a lot of self-modifying code (to speed game up probably on a 68000, but it failed)

Fun fact: game is very smooth on WinUAE, probably because winuae doesn't care about chipmem latency when code is running in chip. But it's dead slow on my A1200/060.

Biggest problem: game runs in chipmem. Well, just relocate it in fastmem, well easier said than done because the "executable" isn't one, it's just a block of code assembled at a fixed location.

Ok, then disassemble it, reassemble it somewhere else and you're good... Yes, but no, as the game uses a lot of tables, containing addresses...

For years I've tried to relocate the original code in fastmem by detecting the reloc offsets in the exe using various scripts. It worked to some extent, but I always seemed to miss something... Well now, I' ve changed my strategy.

I decided to try to reassemble the game to an executable file, and then track all read/writes to the original chipmem area (using Winuae) until the 3D section shows up (my old strategy was just to copy the exe in fast, but leave it in chip too just in case the game reads from chip, which was a big mistake as it didn't track down all hidden address tables...)

Today after 1 week of hard work, various python scripts (some pretty intricate), it showed up

I didn't have the opportunity to test on real hardware but I'll do in the week.

I'm sure it will be slightly faster, but maybe now that the "source" is assembleable, I can start to hack into it. I suspect that the EORing/ORing and ANDing direclty in chipmem is also darn slow compared to doing that on a backbuffer in fastmem and just copy the whole planes afterwards.

I'll keep you posted on the project.

current status here:

https://docs.google.com/spreadsheets...it?pli=1#gid=0

01 May 2022, 15:30	#1
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,196	Fast Red Zone and other fastmem-relocated projects Anyone remembers the infamous Red Zone by Psygnosis? Good graphics good sound good intro and awful frame rate? Probably too ambitious on a 68000. Well, for 17+ years I've been trying to speed that game up for high end amigas, even if I don't particularly like the genre, I always thought that that was a shame that the game had such a low FPS (and Angus repeatedly wanted to bump this subject too) After analysis, game doesn't use blitter (can be handy but not necessarily for a 3D game) and a lot of self-modifying code (to speed game up probably on a 68000, but it failed) Fun fact: game is very smooth on WinUAE, probably because winuae doesn't care about chipmem latency when code is running in chip. But it's dead slow on my A1200/060. Biggest problem: game runs in chipmem. Well, just relocate it in fastmem, well easier said than done because the "executable" isn't one, it's just a block of code assembled at a fixed location. Ok, then disassemble it, reassemble it somewhere else and you're good... Yes, but no, as the game uses a lot of tables, containing addresses... For years I've tried to relocate the original code in fastmem by detecting the reloc offsets in the exe using various scripts. It worked to some extent, but I always seemed to miss something... Well now, I' ve changed my strategy. I decided to try to reassemble the game to an executable file, and then track all read/writes to the original chipmem area (using Winuae) until the 3D section shows up (my old strategy was just to copy the exe in fast, but leave it in chip too just in case the game reads from chip, which was a big mistake as it didn't track down all hidden address tables...) Today after 1 week of hard work, various python scripts (some pretty intricate), it showed up I didn't have the opportunity to test on real hardware but I'll do in the week. I'm sure it will be slightly faster, but maybe now that the "source" is assembleable, I can start to hack into it. I suspect that the EORing/ORing and ANDing direclty in chipmem is also darn slow compared to doing that on a backbuffer in fastmem and just copy the whole planes afterwards. I'll keep you posted on the project. current status here: https://docs.google.com/spreadsheets...it?pli=1#gid=0 Last edited by jotd; 28 May 2023 at 17:26.