at a loss with Red Zone framerate

jotd · 31 January 2021, 00:38

I'm struggling on this for years...
We all agree that the framerate of Red Zone is just terrible. On my 68060 it's maybe 2 or 3 frames per second. And also slow on 68000 which probably explains why the game was a flop

BUT, surprisingly, if you run it on winuae, standard A1200 speed, the framerate is super smooth!

So, what the hell, lets' configure winuae to "fastest possible" and here after & second of smooth framerate, back to slow motion: the framerate is horrible again. Standard A1200 speed again => good framerate.

I've checked vertical blank, code, a lot, and I don't understand what's going on. It's possible that part of the issue on 68060 is that, the other part is that the code runs in chipmem, but that part I'm taking care of.

My guess is that framerate regulation went wrong, game is too fast and something unexpected happens like zero division avoidance that puts a wrong refresh rate value or someting, but I can't find the proof of that.

Someone has an idea? I've zoned the partially resourced "object.s" game source code file.

jotd · 31 January 2021, 14:10

How to investigate on the wasted time? there are 2 sections between which the time is half a second when it crawls, and almost instant when it works properly.

I've tried "vhc" but same results in both cases (the results are hard to understand anyway). Maybe cpu history?

TjLaZer · 31 January 2021, 20:02

Tried it on my Vampire 1200 and it runs pretty well. Almost smooth.

jotd · 31 January 2021, 20:24

thanks for testing. Problem is with "fastest possible". But with 500% it's okay...

I suppose that some operation goes too fast and something becomes negative and goes in a DBF loop...

I'd like the game to run properly on a 68060, but the code running in chipmem is a problem. I relocated a lot of the game parts. Got to test more. But I'm pretty fed up by this damn game.

found a way to slow the game down slightly now the bug doesn't appear anymore... ok, not the main issue. If the game was running in full fastmem it would be fast. Instead of that framerate still sucks on 68060. But that's fixable, by relocating more code into fastmem

to be continued.

Aardvark · 31 January 2021, 22:51

Quote:

Originally Posted by jotd

BUT, surprisingly, if you run it on winuae, standard A1200 speed, the framerate is super smooth!

So, what the hell, lets' configure winuae to "fastest possible" and here after & second of smooth framerate, back to slow motion: the framerate is horrible again. Standard A1200 speed again => good framerate.

Totally different behavior than what I get on WinUAE. A1200 speed (cycle exact) = 5fps, and "fastest possible" (cycle exact off) stays smooth and doesn't drop back to slow motion.
Using WinUAE 4.4.0, Quickstart A1200 config.

Edit: "fastest possible" slowdown only happens if "CPU idle" slider is anything but all the way left.

jotd · 31 January 2021, 23:08

yeah, you're right, probably related to CPU idle. Cycle exact also kills the fun, AFAIR. How did they implement their framerate regulation is a mystery...

Angus · 01 February 2021, 23:53

Dan Gallagher (the coder) also wrote Infestation and Voyager. They have been WHDLoad patched, (Abaddon and Graham) would there be any clues to how the guy works there?

A500 · 10 February 2021, 20:16

Interesting subject, keep us posted!

jotd · 10 February 2021, 20:46

I relocated a lot of the code in fast memory (because running a 3D game with code in chipmem is just horribly slow), but the framerate is still very poor on 68060. On an emulator with "A1200 speed" it's very good.

I wonder where the hold up lies. The game doesn't use the blitter at all to draw/fill the polygons, only the CPU.

Don_Adan · 10 February 2021, 20:57

Quote:

Originally Posted by jotd

I relocated a lot of the code in fast memory (because running a 3D game with code in chipmem is just horribly slow), but the framerate is still very poor on 68060. On an emulator with "A1200 speed" it's very good.

I wonder where the hold up lies. The game doesn't use the blitter at all to draw/fill the polygons, only the CPU.

I dont know if this is same issue, but copying data from chip to chip or from fast to chip is very slow if MMU is active. I tested/find this with first version of Mugician II replayer. On my A4000 playing Mugician II modules was much slowest than on A1200. When i disabled MMU from my A4000 (renamed 68040.library) it works/plays very fast.

jotd · 10 February 2021, 21:47

Yes it's probably something like that that happens on the real machine. Unfortunately, there's no way around copying memory, since the game doesn't use the blitter.

And I didn't see any memory copy, rather a lot of OR and AND, with self modifying code.

Game is 16 colors and updates all 4 bitplanes with the CPU all the time. Not the best job the amiga does....

There's a similar never solved slowdown issue with SWOS IIRC...

I"ll try whdload with NOMMU and will report back.

Angus · 26 February 2021, 21:13

Okay, that's 2 weeks with no word back from Jean-Francois - I'll give it another couple of days then I'm issuing a Code Red and activating Blitter Team!

Let's get Funky!

[ Show youtube player ]

jotd · 26 February 2021, 22:03

I'm sorry why this game is so slow is a complete mystery to me, even after reworking it / relocating main parts, etc...

code in chipmem, absolute addresses (not relocatable), self-modifying code all over the place, no use of the blitter ... just the worst design ever.

CFou! · 26 February 2021, 22:54

Salut Jeff,
Je ne suis pas chez moi pour une semaine donc je ne peux pas regarder.
Si j'ai bien compris ton problème est sur 060.
Est ce que le code de Red Zone n'utiliserai pas à excès des instructions 68000 qui n'existent pas sur 60060?
Si c'est le cas les instructions étant 'émulées' par whdload via l'exception Access fault je suppose que ça pourrait énormément ralentir sur 060.
Sinon j'ai pas trop d'idée sorry!

BippyM · 26 February 2021, 22:57

Quote:

Originally Posted by CFOU!

Hi Jeff,
I'm not home for a week so I can't watch.
If I understood correctly your problem is on 060.
Won't the Red Zone code over-use 68000 instructions that don't exist on 60060?
If this is the case the instructions being 'emulated' by whdload via the Access fault exception I guess it could slow down enormously on 060.
Otherwise I have not too much idea sorry!

English Amiga Board please CFOU!

DamienD · 26 February 2021, 23:18

Quote:

Originally Posted by CFOU!

Salut Jeff,
Je ne suis pas chez moi pour une semaine donc je ne peux pas regarder.
Si j'ai bien compris ton problème est sur 060.
Est ce que le code de Red Zone n'utiliserai pas à excès des instructions 68000 qui n'existent pas sur 60060?
Si c'est le cas les instructions étant 'émulées' par whdload via l'exception Access fault je suppose que ça pourrait énormément ralentir sur 060.
Sinon j'ai pas trop d'idée sorry!

Quote:

Originally Posted by BippyM

English Amiga Board please CFOU!

I'll do it for you CFOU!

Hi Jeff,
I'm not home for a week so I can't watch.
If I understood correctly your problem is on 060.
Won't the Red Zone code overuse 68000 instructions that don't exist on 68060?
If this is the case the instructions being 'emulated' by whdload via the Access fault exception I suppose it could slow down enormously on 060.
Otherwise I don't have too many ideas, sorry!

BippyM · 27 February 2021, 00:10

Read my quote of his post

Quote:

Originally Posted by DamienD

I'll do it for you CFOU!

Hi Jeff,
I'm not home for a week so I can't watch.
If I understood correctly your problem is on 060.
Won't the Red Zone code overuse 68000 instructions that don't exist on 68060?
If this is the case the instructions being 'emulated' by whdload via the Access fault exception I suppose it could slow down enormously on 060.
Otherwise I don't have too many ideas, sorry!

jotd · 27 February 2021, 09:55

CFou Interesting idea but I don't think that there are any MOVEP instructions in the code.

I have surgically relocated a lot of code so it runs in fast memory (not improving the speed, I may say...) and didn't notice any moveps.

Angus · 27 February 2021, 16:54

I had a go (without success) to contact the author, Dan Gallagher. I hadn't realised that he wrote the C64 version of the official Star Wars game as a schoolboy!

[ Show youtube player ]

I found the following mention of Red Zone on his CV, which may cause a chuckle (or not)

Psygnosis June 1, 1992

A motor racing bike simulator for the Commodore Amiga. It won a prize in an Italian Magazine for best simulator of that year. The game was designed for high end Amiga Workstations though still ran (albeit slower) on the Standard domestic Amiga computers. Co-designed and 100% programmed by myself.

jotd · 27 February 2021, 17:14

The game was designed for high end Amiga Workstations ... like WinUAE ... where executing code in chipmem doesn't trigger any latency.

thanks for the laugh Angus

31 January 2021, 00:38	#1
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	at a loss with Red Zone framerate I'm struggling on this for years... We all agree that the framerate of Red Zone is just terrible. On my 68060 it's maybe 2 or 3 frames per second. And also slow on 68000 which probably explains why the game was a flop BUT, surprisingly, if you run it on winuae, standard A1200 speed, the framerate is super smooth! So, what the hell, lets' configure winuae to "fastest possible" and here after & second of smooth framerate, back to slow motion: the framerate is horrible again. Standard A1200 speed again => good framerate. I've checked vertical blank, code, a lot, and I don't understand what's going on. It's possible that part of the issue on 68060 is that, the other part is that the code runs in chipmem, but that part I'm taking care of. My guess is that framerate regulation went wrong, game is too fast and something unexpected happens like zero division avoidance that puts a wrong refresh rate value or someting, but I can't find the proof of that. Someone has an idea? I've zoned the partially resourced "object.s" game source code file.

31 January 2021, 20:24	#4
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	thanks for testing. Problem is with "fastest possible". But with 500% it's okay... I suppose that some operation goes too fast and something becomes negative and goes in a DBF loop... I'd like the game to run properly on a 68060, but the code running in chipmem is a problem. I relocated a lot of the game parts. Got to test more. But I'm pretty fed up by this damn game. found a way to slow the game down slightly now the bug doesn't appear anymore... ok, not the main issue. If the game was running in full fastmem it would be fast. Instead of that framerate still sucks on 68060. But that's fixable, by relocating more code into fastmem to be continued. Last edited by jotd; 31 January 2021 at 22:43.

27 February 2021, 16:54	#19
Angus Amiga Games Database Join Date: Jun 2006 Location: South West England Posts: 1,240	I had a go (without success) to contact the author, Dan Gallagher. I hadn't realised that he wrote the C64 version of the official Star Wars game as a schoolboy! [ Show youtube player ] I found the following mention of Red Zone on his CV, which may cause a chuckle (or not) Psygnosis June 1, 1992 A motor racing bike simulator for the Commodore Amiga. It won a prize in an Italian Magazine for best simulator of that year. The game was designed for high end Amiga Workstations though still ran (albeit slower) on the Standard domestic Amiga computers. Co-designed and 100% programmed by myself. Last edited by Angus; 27 February 2021 at 17:18.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Cover Disk: Red Zone demo - Freezeframe?	Angus	support.Games	10	06 May 2020 16:09
Red Zone?	mikey2002kent	support.Games	0	26 February 2014 22:06
Loss of video on 4000T	videofx	support.Hardware	0	13 February 2013 17:52
AmigaNCP = At a loss!	Demonitron	support.Apps	1	29 September 2011 17:14
Red Zone demo on The One cover disk?	Angus	Retrogaming General Discussion	7	08 November 2006 11:13

31 January 2021, 14:10	#2
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	How to investigate on the wasted time? there are 2 sections between which the time is half a second when it crawls, and almost instant when it works properly. I've tried "vhc" but same results in both cases (the results are hard to understand anyway). Maybe cpu history?

31 January 2021, 20:02	#3
TjLaZer Registered User Join Date: Sep 2004 Location: Tacoma, WA USA Age: 52 Posts: 1,915	Tried it on my Vampire 1200 and it runs pretty well. Almost smooth.

31 January 2021, 23:08	#6
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	yeah, you're right, probably related to CPU idle. Cycle exact also kills the fun, AFAIR. How did they implement their framerate regulation is a mystery...

01 February 2021, 23:53	#7
Angus Amiga Games Database Join Date: Jun 2006 Location: South West England Posts: 1,240	Dan Gallagher (the coder) also wrote Infestation and Voyager. They have been WHDLoad patched, (Abaddon and Graham) would there be any clues to how the guy works there?

10 February 2021, 20:16	#8
A500 Registered User Join Date: Jun 2017 Location: Finland Posts: 361	Interesting subject, keep us posted!

10 February 2021, 20:46	#9
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	I relocated a lot of the code in fast memory (because running a 3D game with code in chipmem is just horribly slow), but the framerate is still very poor on 68060. On an emulator with "A1200 speed" it's very good. I wonder where the hold up lies. The game doesn't use the blitter at all to draw/fill the polygons, only the CPU.

10 February 2021, 21:47	#11
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	Yes it's probably something like that that happens on the real machine. Unfortunately, there's no way around copying memory, since the game doesn't use the blitter. And I didn't see any memory copy, rather a lot of OR and AND, with self modifying code. Game is 16 colors and updates all 4 bitplanes with the CPU all the time. Not the best job the amiga does.... There's a similar never solved slowdown issue with SWOS IIRC... I"ll try whdload with NOMMU and will report back.

26 February 2021, 21:13	#12
Angus Amiga Games Database Join Date: Jun 2006 Location: South West England Posts: 1,240	Okay, that's 2 weeks with no word back from Jean-Francois - I'll give it another couple of days then I'm issuing a Code Red and activating Blitter Team! Let's get Funky! [ Show youtube player ]

26 February 2021, 22:03	#13
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	I'm sorry why this game is so slow is a complete mystery to me, even after reworking it / relocating main parts, etc... code in chipmem, absolute addresses (not relocatable), self-modifying code all over the place, no use of the blitter ... just the worst design ever.

26 February 2021, 22:54	#14
CFou! Moderator Join Date: Sep 2004 Location: France Age: 50 Posts: 4,277	Salut Jeff, Je ne suis pas chez moi pour une semaine donc je ne peux pas regarder. Si j'ai bien compris ton problème est sur 060. Est ce que le code de Red Zone n'utiliserai pas à excès des instructions 68000 qui n'existent pas sur 60060? Si c'est le cas les instructions étant 'émulées' par whdload via l'exception Access fault je suppose que ça pourrait énormément ralentir sur 060. Sinon j'ai pas trop d'idée sorry!

27 February 2021, 09:55	#18
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	CFou Interesting idea but I don't think that there are any MOVEP instructions in the code. I have surgically relocated a lot of code so it runs in fast memory (not improving the speed, I may say...) and didn't notice any moveps.

27 February 2021, 17:14	#20
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,162	The game was designed for high end Amiga Workstations ... like WinUAE ... where executing code in chipmem doesn't trigger any latency. thanks for the laugh Angus

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)