Gauntlet.How come CPC version manages to run without sluggish sprites?

[Puresox]

Could someone give an explanation for a layman , on why Gauntlet runs very well on the CPC, when you find many games on the Amstrad very sluggish when numerous sprites are on screen.  Are games like Gauntlet, Renegade ,Operation Wolf , Afterburner. Just very well programmed games . Or is it to do with some other reason?
Also could someone explain the 16k dedicated screen memory , Pro's and Cons .
Thanks

[andycadley]

If you look carefully, you'll notice a few things:

• Sprites never overlap anything
• The background is a single, solid colour
• Everything is, effectively, square

All of these things allow you to greatly simplify what needs to be drawn to draw (and delete) sprites from the screen. Using such tricks makes it possible to handle more sprites on screen without dropping the frame rate.

As to the 16K screen, it's a trade off. On one hand you get better colour and pixel resolution that machines with smaller screen memory (the Spectrum and C64 both have colour limitations within a character and, in it's normal "text" modes the C64 has a limited number of distinct characters on screen) , however on the other hand it requires a lot more CPU time to manipulate and both the display and other graphics tend to consume more memory.

[Puresox]

Ok so that clears up Gauntlet, thanks for the insight on it.
How about , DrDestructo(Mastertronic). Or the Afterburner, Op Wolf , Renegade. They are different cases and not what topic is specifically asking. Any insights on how these manage to run so nicely , say into comparison to maybe Titus the Fox , or Hudson Hawk .
Is the reputation of sluggishness on CPC  due purely to Spectrum ports  not being ideal . And the factor of scrolling .Also  Does music within gameplay have a vast effect on the speed ?
A number of questions there I know, hope you can understand

[fgbrain]

There's another trick in some games like some you mention.

Not all sprites are updated (animated) in each frame but many less.. While the scrolling keeps on, many sprites remain still for some frames.
This saves lots of machine time because for, say half sprites updated, half time required!
Of course, the collision routines and positions are called in each frame, but no routines to print on-screen..

[arnoldemu]

For Operation wolf, the lower part of the scrolling screen always repeats, therefore it doesn't need to read from a tilemap and can draw the tiles all the same saving many cycles. The top part doesn't repeat (I don't think) so it only needs to lookup and draw tiles for that part.

The screen is also constantly scrolling, so it doesn't need to delete sprites, it redraws the screen each time and puts the sprites over the top.

For renegade:

there are 4 sprite drawing functions. One for each pixel position and one for reversed. As it draws it captures the background (ok because it doesn't scroll). When it erases the sprites it draws the background back.
That explains the drawing, but with renegade (and I didn't check this) I think most speed comes because it probably updates the ai much less frequently then we think.

[arnoldemu]

andy is correct. The background is a single colour, this means very fast clearing of sprites (a single colour, no need to store background graphics).
Sprites can be drawn with direct pixel writes (no need to mask).
The scrolling is fake. It doesn't scroll at all, it redraws the wall tiles and erases the old, the walls are well spaced so there are not many so it's only updating half the screen for the scroll.

[arnoldemu]

The best CPC games are very well programmed

I still don't know why Titus the Fox is so slow. There are few sprites, there is little AI, it should be much faster.

[andycadley]

DrDestructo is an easy one, it has an obvious "tell". Watch as sprites pass in front of things and notice how their colours change. That's because it's using an XOR drawing technique which allows much quicker masking (at the expense of colour changes). Since the background is mostly one colour and the enemies attacks are carefully designed not to overlap, it gets away with it without looking like a big mess.

The others are undoubtedly well programmed and probably need more careful deconstruction to figure out some of the tricks behind them. I suspect Operation Wolf is using a similar character drawing trick to R-Type. This uses allows big sprites because you're effectively treating them as part of the background and you have to redraw that as part of the scrolling anyway. Without disassembling the game, it's hard to be entirely sure (and as arnoldemu says, they're probably combining it with other tricks too).

The Amstrad certainly took a hit due to games being rush ported from the Spectrum or just having reused C64 assets (which often leads to the CPU doing extra work to process them for the CPC display) but it's by no means the only thing that makes writing fast games harder. The screen memory size is a big issue when it comes to processing data and it's pushing the limit of what the Z80 can really handle unassisted.

[ervin]

The best CPC games are very well programmed

I still don't know why Titus the Fox is so slow. There are few sprites, there is little AI, it should be much faster.

There was a vid a while ago (I think it was one of Xyphoe's) that showed a sequence where several blocks had to be stacked, in order to jump up to a higher part of the screen.
And oh dear, the framerate took a *massive* hit.

Consequently, I think one of the main reasons for Titus' sluggishness is due to terribly inefficient collision detection.
A real shame, as it looks like it could've been a great game.

[arnoldemu]

I still don't know why Titus the Fox is so slow. There are few sprites, there is little AI, it should be much faster.

The sprite routine is interesting and overly complex.

It seems to do a XOR of the background and the sprite and store it in a temporary buffer. Then it reads from this and draws onto the screen using XOR.
In addition it assumes the screen will scroll and wrap around so uses a slow method to increment the memory address.

The sprites are stored with variable widths and heights but normally.

So it's almost like it draws every sprite twice!

Ouch!

[MacDeath]

No real masked things... no real background as well.

Not quite sure about the animation smoothness... I think things are moved by bytes (2 pixels ?) or are things moved pixel by pixel ?
Really to have no mask can vastly gain a lot of CPU.

Also Speccy sized screen... and the tile set/spritesheet are not really huge or very detailed.

is there some editor for this game engine ? was it hacked ?
Would be nice to check what could be upgraded at least graphically.

[AMSDOS]

DrDestructo is an easy one, it has an obvious "tell". Watch as sprites pass in front of things and notice how their colours change. That's because it's using an XOR drawing technique which allows much quicker masking (at the expense of colour changes). Since the background is mostly one colour and the enemies attacks are carefully designed not to overlap, it gets away with it without looking like a big mess.

It also makes great use of using the changing the INK palette, which the CPC is good at, it wouldn't surprise me if the stars on the night sky remained on the day sky (as they would in real life), simply altering the relevant INK number would sort that out. 

[Puresox]

Thanks , some really useful info  appreciated

[CraigsBar]

The sprite routine is interesting and overly complex.

It seems to do a XOR of the background and the sprite and store it in a temporary buffer. Then it reads from this and draws onto the screen using XOR.
In addition it assumes the screen will scroll and wrap around so uses a slow method to increment the memory address.

The sprites are stored with variable widths and heights but normally.

So it's almost like it draws every sprite twice!

Ouch!

So how about a Titus the fox port to the gx4000, hardware sprites, enhanced pallette and assisted scrolling? it would make an awesome console game. I'd pay for that no question about it.

[Puresox]

Me too , make the game enjoyable

[dodogildo]

Awesome thread. Thank you all [emoji106]