Fast Red Zone and other fastmem-relocated projects

[jotd]

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

[Reynolds]

This is really interesting. Red Zone could be the bikers' F1GP, with decent framerate.

[alexh]

Originally Posted by Reynolds

This is really interesting. Red Zone could be the bikers' F1GP, with decent framerate.

That would be No Second Prize wouldn't it?

[Galahad/FLT]

Originally Posted by jotd

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.

Sounds super complicated way of achieving what I did for Stun Runner.

I didn't use complicated scripts and stuff, I firstly search for all absolute JSR's and JMP's.

Then I searched for all LEA's that were absolute, ignored obvious stuff like $dff000 and $bfe001.

I then searched for typical instructions used for calling routines in tables, and then processed those by hand.

I was probably luckier than you in that I had no self modifying code to deal with, but that brought about results right away for me.

But well done, its nice to see attempts to make what was a crap game actually something worth playing, because it was obvious that the engine underlying Red Zone was very good, i'm just stunned they locked it to 68000 so much when the benefits of it running quicker on faster processors would have given it the gameplay boost it needed.

Team Suzuki suffers the same fate as well.

In both cases, a good game is struggling to get released from the confines of 68000

[jotd]

It was slightly more complex in Red Zone yes

For instance, the main draw table consisted of blocks like: a routine (reloc needed), plus parameters that depended of the routine and which could be word, long or pointer... I had to use a python script to decode all that crap and generate proper tables.

lb_fa94:
	dc.l	lb_e1f8	;0fa94
	dc.w	$0002	;0fa98
	dc.w	$0004	;0fa9a
	dc.w	$0006	;0fa9c
	dc.w	$0008	;0fa9e
	dc.w	$ffff	;0faa0
lb_faa2:
	dc.l	lb_dde0	;0faa2
	dc.w	$0006	;0faa6
	dc.w	$20ca	;0faa8
	dc.w	$0004	;0faaa
	dc.w	$0002	;0faac
	dc.w	$0008	;0faae
	dc.w	$0006	;0fab0
	dc.w	$ffff	;0fab2
	dc.l	$ffffffff	;0fab4
lb_fab8:
	dc.l	lb_d458	;0fab8
	dc.w	$012c	;0fabc
lb_fabe:
	dc.l	lb_e496	;0fabe
lb_fac2:
	dc.l	lb_4d64a	;0fac2
lb_fac6:
	dc.l	lb_4d64c	;0fac6
lb_faca:
	dc.l	lb_4d64e	;0faca
	dc.w	$0000	;0face

Note: the table is 32k in size!!! good luck doing that by hand.

Plus the coders were really inconsistent in their coding, using either movea.l #address,another_address or lea address,A0 (depending on the mood?). LEAs are translated to labels, but moveas could very well be data...

The trick was to use winuae and read/write watchpoint on the whole program (previous location) and work from there to be sure not to miss anything.

It's not over yet, but looking good.

[jotd]

game now running from relocated memory. Got to test more but looks promising.

[Seiya]

Originally Posted by jotd

Anyone remembers the infamous Red Zone by Psygnosis?

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.

I tried on WinUAE and in emulation A500 is jerky, impossibile to drive with that frame rate.
on stock A1200 WinUAE config is better, surely not smoother, but the gameplay is better.
Your problem is that you have 68060 that is very bad on old 3D games as they don't support such processor, totally risc in integer and floating point instructions.
For curiosity i tried to launch the game with 68060 config, but the game crash at boot because 68060 require 68060.library loaded before launching the game. Of course with boot disk you cannot do it

[CFou!]

Originally Posted by jotd

Anyone remembers the infamous Red Zone by Psygnosis?

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

in style, No Second Prize is pretty good. but probably fewer objects to manage...

[jotd]

I don't think it's a 68060 instruction issue. Got to check that but it's more like 3D cpu intensive (and non FPU) executing in chipmem. Also no blitter to fill surfaces. Everything is done 100% with the CPU. Accelerators hate that setting.

I'll check my version on my A1200/060 this week. I hope the speed is good. So many hours spent trying to make that game work...

If you know of other 3D games that could be sped up, please mention them (not TFX). If game runs in chipmem, relocating it could do the trick.

[kremiso]

interesting, if we can finally have a joystick controlled No Second Prize rival

Originally Posted by Galahad/FLT

...Team Suzuki suffers the same fate as well

i prefer the training disk than the final release of that one
the controls are much more responsive, and the game itself little smooth
strangely better, not just easier imo

[Aardvark]

Originally Posted by jotd

If you know of other 3D games that could be sped up, please mention them (not TFX). If game runs in chipmem, relocating it could do the trick.

Red Baron. Very good simulator on DOS and Mac, but the Amiga version can only run smooth on UAE with Immediate Blitter setting enabled.

[alexh]

Originally Posted by CFou!

No Second Prize is pretty good. but probably fewer objects to manage...

I'm not sure that's true? The NSP 3D engine by Chris Jungen was widely considered to be the fastest at the time.

[meynaf]

There is another possibility to properly resource code at absolute location.
Try to find a different version of same program. As soon as code size changes, all subsequent addresses also change and you can get some reloc table out of this. I used this trick for Back to the Golden Age.

[CFou!]

Originally Posted by alexh

I'm not sure that's true? The NSP 3D engine by Chris Jungen was widely considered to be the fastest at the time.

I wrote 'probably'
because I never played Red Zone. On the other hand, I played the excellent NSP a lot!

[jotd]

Originally Posted by Aardvark

Red Baron. Very good simulator on DOS and Mac, but the Amiga version can only run smooth on UAE with Immediate Blitter setting enabled.

Red Baron already runs from fastmem with caches. Probably not a lot to optimize

There is another possibility to properly resource code at absolute location.
Try to find a different version of same program. As soon as code size changes, all subsequent addresses also change and you can get some reloc table out of this. I used this trick for Back to the Golden Age.

There isn't any other version of this game. I used that trick when game (I don't remember which one) is pre-relocated at $80000 and $C0000 depending on the memory layout. They were so lazy they prefered including 2 copies of the program instead of a proper reloc system.

[Aardvark]

Originally Posted by jotd

Red Baron already runs from fastmem with caches. Probably not a lot to optimize

Wonder why it's so slow then on TF1260 at 100mhz. The Mac version via Shapeshifter is much faster and that one runs on 256 color interlaced hires mode.

[jotd]

The program (Red Baron) seems to call graphics OwnBlitter/DisownBlitter a lot. Maybe it's stupid and slow to do that all the time...

Removing them doesn't change a thing. But for me the game runs smoothly already.

[jotd]

Could check the fast relocated version of Red Zone on my 1200/060 and the framerate is MUCH better. It's even good I think I get 20 fps instead of lame 10 fps I have with original.

There are graphical issues that I'm investigating (wrong polygon drawing, probably my mistake) but it really looks good!

[Aardvark]

Originally Posted by jotd

The program (Red Baron) seems to call graphics OwnBlitter/DisownBlitter a lot. Maybe it's stupid and slow to do that all the time...

Removing them doesn't change a thing. But for me the game runs smoothly already.

Runs quite poorly on my 060, especially compared to the Mac version on the same machine. [ Show youtube player ]

Hunter is another game which has really fast 3D on WinUAE when disabling Cycle-exact, but doesn't benefit from faster CPU's on real machines.

[jotd]

ah Hunter is another candidate!