Hi,
This question is more or less related to Fastest cycles/byte memory write rate : is better than 1.5µs/byte possible ? (http://www.cpcwiki.eu/forum/programming/fastest-cyclesbyte-memory-write-rate/) (which was mainly about filling memory).
Some driving games are remarkable (for the CPC capabilities), for example :
Crazy Car on Roland emulator (http://roland.retrolandia.net/664s?crazycar.dsk/run%22crazy)
Crazy Car 2 on Roland emulator (http://roland.retrolandia.net/664s?crazyca2.dsk/run%22cc2)
Chase HQ on Roland emulator (http://roland.retrolandia.net/6128s?chasehq.dsk/run%22disc)
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) (http://www.cpcwiki.eu/forum/longplays/xyphoe%27s-vids-(amstrad-cpc)-chase-hq-review-longplay-(part-1-of-2)/)
Xyphoe's Vids - [AMSTRAD CPC] Chase HQ - Review & Longplay (Part 2 of 2) (http://www.cpcwiki.eu/forum/longplays/xyphoe%27s-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 ?
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 ;) 8)
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).
Quote from: ervin on 22:57, 14 January 13
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).
Quote from: arnoldemu on 10:11, 15 January 13
...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').
Quote from: TFM/FS on 20:57, 15 January 13
Well, I disagree with that.
For a racing game it works well for others it doesn't ;)
Quote from: TFM/FS on 20:57, 15 January 13
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.
Quote from: TFM/FS on 20:57, 15 January 13In 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.
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.
Quote from: TFM/FS on 19:19, 16 January 13
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.
Is Martech's "Nigel Mansells Grand Prix" using the same method? This game is smoother and faster than both Continental Circus and Chase HQ.
Also compared to Burnin Rubber??
Quote from: TFM/FS on 23:24, 17 January 13
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!!
Quote from: TFM/FS on 23:24, 17 January 13
Also compared to Burnin Rubber??
I believe Burnin' Rubber is made by the same coder as Chase HQ and Wec Le Mans.
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 ;)
Quote from: TFM/FS on 21:00, 22 January 13
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*
Not really, back to topic ;D
Quote from: TFM/FS on 21:00, 22 January 13
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?
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!)
8)
I always like Mansell's smooth scrolling backdrop though.
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?
Quote from: sigh on 14:41, 15 February 13
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 ;D
Quote from: sigh on 14:41, 15 February 13
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!
Quote from: ervin on 11:39, 17 February 13
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.
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!
Quote from: ervin on 23:34, 17 February 13
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?
Quote from: sigh on 18:52, 18 February 13
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?
I don't think that is really possible for a game like Chase HQ, without dropping the frame rate. You have all the maths of scaling the object on top of the maths of rendering the result to screen memory.
Compared to drawing a lot of small tiles that make up a larger object, anyway.
Vertical scaling is fairly easy however. Maybe that would explain the way objects grow in Chase HQ? (I still think it's just rendering lots of smaller tiles as quickly as it can)
It is doable, just use pre-calculations. However you will need A LOT of memory. Bye, bye CPC464 and 555 then.
Quote from: TFM/FS on 21:39, 18 February 13
It is doable, just use pre-calculations. However you will need A LOT of memory. Bye, bye CPC464 and 555 then.
So - 128kb only then :)
The objects are prescaled in chase hq.
the road is drawn a line at a time using push.
no idea about the scrolling background.
Quote from: sigh on 09:49, 19 February 13
So - 128kb only then :)
That would be a fair compromise between speed and memory-usage. However to make it really quick I think about 256 KB or even more.
As an example. Once I did a 3D ego shooter for CPC (using 16 KB screen RAM). It runs quick (about 18 fps.), because it needs 512 KB (sic) RAM. Pretty much everything is precalculated (screen elements, not whole screens ;-)). But it's not really usable, if you have to boot from disc. Well...
Quote from: TFM/FS on 21:53, 19 February 13
However to make it really quick I think about 256 KB or even more.
Imagine the tables you could fit into a 512kb cartridge.
I always try and do calculations bit wise if I can but sometimes you can't beat a page-aligned table. However, fitting them into a 16kb game might pose a bit of a challenge 8)
Back to topic though - I think that Chase HQ is a remarkable feat, but also it also relies heavily on the illusion of speed - you can see this if you focus on one part of the playing area and look at the frame-rate an actually what you see being drawn.
I'd like to know if the programmer did this by 'seeing' if it looked fast or if he actually did some real life calculations on perspective etc and then incorporate this into the game.
Nice to see you "back" / more often here again! :)
Quote from: TFM/FS on 21:53, 19 February 13
That would be a fair compromise between speed and memory-usage. However to make it really quick I think about 256 KB or even more.
As an example. Once I did a 3D ego shooter for CPC (using 16 KB screen RAM). It runs quick (about 18 fps.), because it needs 512 KB (sic) RAM. Pretty much everything is precalculated (screen elements, not whole screens ;-)). But it's not really usable, if you have to boot from disc. Well...
is this shooter released?
I would like to see it.
Or, if it's not complete, I would like to play a demo version of it.
Quote from: redbox on 22:13, 19 February 13
Imagine the tables you could fit into a 512kb cartridge.
I'd love for game-developers to do a 512kb cartridge game-development competition. :-D
But is such a thing even possible?
Quote from: redbox on 22:13, 19 February 13
I think that Chase HQ is a remarkable feat, but also it also relies heavily on the illusion of speed - you can see this if you focus on one part of the playing area and look at the frame-rate an actually what you see being drawn.
I'd like to know if the programmer did this by 'seeing' if it looked fast or if he actually did some real life calculations on perspective etc and then incorporate this into the game.
This I find the most important aspect of any racing game regardless of the techniques used. I was watching 3D Grand Prix on the CPC and that feels very fast due to the smooth and rapid red and white lines round the edges of the road. If you look at Enduro Racer, the lines around the edges hardly look as though they are moving, so it gives it a slow feeling.
Quote from: arnoldemu on 10:23, 20 February 13
is this shooter released?
I would like to see it.
Or, if it's not complete, I would like to play a demo version of it.
Stopped it long time ago, because the gfx are ugly and it has some pixel errors, and I just don't know why. So it was too frustrating and new projects always make more fun. I may come back to it though, if I can get some better gfx (which is basicly walls ;-))
Quote from: mr_lou on 15:10, 20 February 13
I'd love for game-developers to do a 512kb cartridge game-development competition. :-D
But is such a thing even possible?
Depends how you define it? 512 KB RAM or ROM? And ... what's the price? ;D
Quote from: TFM/FS on 22:21, 20 February 13
Depends how you define it? 512 KB RAM or ROM? And ... what's the price? ;D
I define it as "a cartridge that can just be plugged into a CPC+ or GX4000", so ROM.
Ah, ok. So the classical standart Cartridge for the CPC Plus or GX4000.
Well, the Plus has 128 KB RAM which could be an advantage over the 64 KB of the GX4000 - when using double buffering and overscan. I just mention it :)
For such an contest you need a real teasing price and at least two years of time - IMHO. ;)
All good as long as someone has 512K in their real CPC. :D
Quote from: mr_lou on 22:24, 20 February 13
I define it as "a cartridge that can just be plugged into a CPC+ or GX4000", so ROM.
Let's see how the 16k rom game competition goes first. Then this could be also done.
one year 16k rom competition, other year, plus cart competition.
Quote from: TFM/FS on 21:30, 20 February 13
Stopped it long time ago, because the gfx are ugly and it has some pixel errors, and I just don't know why. So it was too frustrating and new projects always make more fun. I may come back to it though, if I can get some better gfx (which is basicly walls ;-))
release it now in it's ugly state and forget about it... clear your mind.
Quote from: TFM/FS on 21:30, 20 February 13
Stopped it long time ago, because the gfx are ugly and it has some pixel errors, and I just don't know why. So it was too frustrating and new projects always make more fun. I may come back to it though, if I can get some better gfx (which is basicly walls ;-))
What sort of wall do you need? I'm very busy with the beatem up project but if it's just a simple wall texture to get you going then I can do that for you.
Thanks!!! I keep that in mind. But first let's finish the 16 KB ROM game thingy :)
Quote from: arnoldemu on 10:19, 21 February 13
release it now in it's ugly state and forget about it... clear your mind.
Ah no. We here at the FutureSoft headquarters have a quality standart and QC is not left to the customer :laugh: . And further... it will be the ideal candidate for Mr. Lou's 512 KB Cart. compo ;)
Knowing that the CPC version is a spectrum port and that the game manages a very fast pace - how much faster would it have been if it was coded from scratch? Would the difference be huge or neglible? Would we have been able to get Martech's Nigel Mansell/Super cycle smoothness with the hills and dips?
In this case it really matters if you work with 64 KB only or with 128 KB.
...and whether it was the 48k or the 128k version that was ported depending if there are any differences between them apart from speech and music.