Chase HQ : how did they manage ?

[cpcitor]

Hi,

This question is more or less related to Fastest cycles/byte memory write rate : is better than 1.5µs/byte possible ? (which was mainly about filling memory).

Some driving games are remarkable (for the CPC capabilities), for example :
Crazy Car on Roland emulator
Crazy Car 2 on Roland emulator
Chase HQ on Roland emulator

Chase HQ, in this context, has a shockingly good animation. There are so many moving objects that it looks like the whole screen area must be repainted at every frame. For example, in part 2 below, you can see a helicopter flying above, and areas with archs above the highway.

Xyphoe's Vids - [AMSTRAD CPC] Chase HQ - Review & Longplay (Part 1 of 2)
Xyphoe's Vids - [AMSTRAD CPC] Chase HQ - Review & Longplay (Part 1 of 2)
Xyphoe's Vids - [AMSTRAD CPC] Chase HQ - Review & Longplay (Part 2 of 2)
Xyphoe's Vids - [AMSTRAD CPC] Chase HQ - Review & Longplay (Part 2 of 2)

Now my question : does anyone know how they achieved such a framerate ? There are probably a few core tricks.

A (modified ?) emulator could dump Z80 instructions between two frames, for analysis. Has anyone done that already ?

[TFM]

Well, some ideas are...
 
- Use double buffering (draw next picture, while showing the last one)
 
- Only delete/redraw objects that have been moved
 
- Use programs to draw sprites instead of sprite routines using data (hardcoded sprites).
 
Be creative 

[ervin]

Also, the actual playing area is quite small.
If it is repainting the entire playing area each frame, it's probably only doing 8K or so (that's just a rough guess!).
That would be where a lot of its speed comes from (as well as excellent programming).

[arnoldemu]

Also, the actual playing area is quite small.
If it is repainting the entire playing area each frame, it's probably only doing 8K or so (that's just a rough guess!).
That would be where a lot of its speed comes from (as well as excellent programming).

Yes.

they use double buffer to minimize flicker only.

they redraw the screen each time because potentially everything could move on that frame, road, mountains in the background and the cars.
it avoids the cost of working out what to redraw and is simpler.

also by redrawing in a fixed order they can get the relative z/depth correct .

EDIT: They use PUSH to draw the road, two different patterns depending on the sides or the middle and stripe or not.
car is drawn from bottom to top (sprite is stored this way).

[TFM]

...it avoids the cost of working out what to redraw and is simpler.

Well, I disagree with that. With one of my games I did a complete redraw at the beginning, but later on I move to 'working out what to redraw'. That made the whole game 1-2 frames more quick. And the max. number of sprites is about 70 or a couple more.
You just need a smart algoritm.
 
BTW: Per FRAME you only have a bit less than 20.000 ys. Now even when using PUSH it takes already 32700 ys to fill the 16 KB. To be realistic: In games you more often use stuff like LD HL,XXXX:PUSH HL. Now this are already 3.5 ys per byte. So for 8 KB you would need 28600 ys. And that's more than a frame. Therefore I doubt that they redraw everything. (and I doubt the 'each frame').
 

[arnoldemu]

Well, I disagree with that.

For a racing game it works well for others it doesn't

[cpcitor]

BTW: Per FRAME you only have a bit less than 20.000 ys. Now even when using PUSH it takes already 32700 ys to fill the 16 KB. To be realistic: In games you more often use stuff like LD HL,XXXX:PUSH HL. Now this are already 3.5 ys per byte. So for 8 KB you would need 28600 ys. And that's more than a frame. Therefore I doubt that they redraw everything. (and I doubt the 'each frame').

You're demonstrating that it can't be 50fps and you're right about this.
Actual fps is about 12.5fps, at that fps you have 80000 NOPs to draw a frame. That's credible.

[db6128]

In games you more often use stuff like LD HL,XXXX:PUSH HL. Now this are already 3.5 ys per byte. So for 8 KB you would need 28600 ys. And that's more than a frame. Therefore I doubt that they redraw everything. (and I doubt the 'each frame').

But, especially in games like this with lots of solid lines, you don’t need to LD HL every time before PUSHing. You can load it once and push that multiple times.
You can’t just apply a blanket rule like this to a complex screen made of multiple layers and elements. If you’re going to compare methods, at least try to be fair.

[TFM]

The complexity of the screen is exactly what screws up the PUSH idea. Even the street moves right and left, or even divides. So you can PUSH maybe (in mean) about... 10 times, which is not bad. BUT you do need a lot of calculations around it, and this may/does need a lot of time.
 
 

[arnoldemu]

The complexity of the screen is exactly what screws up the PUSH idea. Even the street moves right and left, or even divides. So you can PUSH maybe (in mean) about... 10 times, which is not bad. BUT you do need a lot of calculations around it, and this may/does need a lot of time.

I am confident it uses pushes to draw the road. I analysed the code a few years ago.
it has more than one routine, it jumps to a place in the routine to skip/add pixels to the right of the screen and to draw a fixed width road, then has extra pushes at the end for the other side.
when it's done that, it then draws the kurb stones over the top.

at least continental circus does this too, and it's really nice and smooth.

[sigh]

Is  Martech's "Nigel Mansells Grand Prix" using the same method? This game is smoother and faster than both Continental Circus and Chase HQ.

[TFM]

Also compared to Burnin Rubber??

[sigh]

Also compared to Burnin Rubber??

I think that Burning Rubber is using whatever Wec Le mans is using? Both Burning Rubber and Wec Le mans has the same feeling of speed and frame rate of Continental Circus.
Nigel Mansell's Grand Prix seems to be using whatever SuperCycle is using, but in a much better way as it doesn't have the "going backwards" effect that happens in SuperCycle when you reach top speed.

Seriously - though I know very little about programming, Nigel Mansell's Grand Prix is truly out of this world!!

[arnoldemu]

Also compared to Burnin Rubber??

I believe Burnin' Rubber is made by the same coder as Chase HQ and Wec Le Mans.

[TFM]

Nigel Mansells has no up/down, that saves a lot of cpu power.
 
Would be nice to do such a game, but in overscan and not in such little windows people did it up to now. With some smart algorithm you only alter what needs to be altered. And... use some double buffering, made smart, even fewers things must be altered every frame.
 
Would be a nice project, and such a big one 

[arnoldemu]

Nigel Mansells has no up/down, that saves a lot of cpu power.
 
Would be nice to do such a game, but in overscan and not in such little windows people did it up to now. With some smart algorithm you only alter what needs to be altered. And... use some double buffering, made smart, even fewers things must be altered every frame.
 
Would be a nice project, and such a big one 

speaking of projects, any updates on your games?






*runs off*

[TFM]

Not really, back to topic

[sigh]

Nigel Mansells has no up/down, that saves a lot of cpu power.
 
Would be nice to do such a game, but in overscan and not in such little windows people did it up to now. With some smart algorithm you only alter what needs to be altered. And... use some double buffering, made smart, even fewers things must be altered every frame.
 
Would be a nice project, and such a big one 

So if the Mansell game engine had the up and down, would the same smoothness and speed still be achievable?

[ervin]

Having messed around with an undulating road idea, I can confidently say that including up/down movement wouldn't make too much of a noticeable difference.
Lookup tables could be used to quickly calculate a road line's vertical position.

Incidentally, it's not really fair to compare Mansell's framerate to Chase HQ's.
Chase HQ has MANY more road-side objects to process each frame, and yet still manages to be very playable.

Also, Mansell uses a play area of 160x83 mode 0 pixels, which is just over 6.5KB of screen area (I'm not counting the instrument panel in this comparison).
Interestingly, Mansell doesn't use a spectrum-sized screen - it uses the full cpc screen width.

Chase HQ on the other hand uses a play area of 128x128 mode 0 pixels, which equals exactly 8KB.
Considering how much stuff it is throwing around the screen, it's a remarkable effort.

(I'm starting to sound like MacDeath here!)
 

I always like Mansell's smooth scrolling backdrop though.

[sigh]

It's good to know that the up/down movement wouldn't impact on gameplay.
Chase HQ indeed has huge side objects including some that you can actually knock over too. Amazing programming. I wonder if all the sprite scaling is a mixture of drawn sprites with sprite scaling code?

[redbox]

Amazing programming.

It truly is.  Just watched the video of it again today and am still amazed by it.

Made all the sweeter by the fact the C64 version is such a huge pile of sh*te 

[ervin]

Chase HQ indeed has huge side objects including some that you can actually knock over too. Amazing programming. I wonder if all the sprite scaling is a mixture of drawn sprites with sprite scaling code?

I'm fairly certain that it doesn't contain sprite scaling, apart from picking the right pre-drawn sprite to draw in a particular location on-screen.
However, the game does do something a bit unusual.

Some large roadside objects appear to "grow" vertically in a rather strange way - check out the big trees on level 1, or the big stone walls on level 2.
For example, the jump from the second-to-largest tree to the largest tree appears to be an increase in height done by putting an extra row of tiles into the body of the tree.

It that's the case, it's a very clever way of saving memory.
Looking further into a playthrough video, it appears that most (if not all) of the tall objects in the game could indeed have been drawn with tiling techniques, thereby massively reducing their memory footprints.

Marvellous stuff!

[sigh]

Some large roadside objects appear to "grow" vertically in a rather strange way - check out the big trees on level 1, or the big stone walls on level 2.
For example, the jump from the second-to-largest tree to the largest tree appears to be an increase in height done by putting an extra row of tiles into the body of the tree.

I was thinking of something similar as this approach makes perfect sense. I did wonder if some program techniques used in scaling for the game "Pit Fighter" was used (not a great game, but I was very impressed by the scaling.) I wonder if a combination of sprite scaling and code scaling would even be possible to get something moving as smoothly as Chase HQ/Mansell.

[ervin]

Pit Fighter could've/should've been a lot faster.
 
It's only using around 6KB for the play area, so there's not a huge amount of screen area to update each frame.
The culprit has gotta be either the scaling code or the sprite processing code.
So disappointing - I really enjoyed this game in the arcades back in the day.
 
It is possible to create fast real-time sprite scaling on the CPC (I've got it working in my Chunky Pixel Collision project), but I can imagine back in the 80s, without the benefit of the fast cross-dev we have today, writing such code would have been very difficult!
 

[sigh]

It is possible to create fast real-time sprite scaling on the CPC (I've got it working in my Chunky Pixel Collision project), but I can imagine back in the 80s, without the benefit of the fast cross-dev we have today, writing such code would have been very difficult!

Interesting. So am I right to assume that if one were to design a racing game, that real-time sprite scaling would be more preferable than drawing the sprites individually?