FPS of scrolling in certain games.

[Carnivius]

Not sure where to ask this so if this is in wrong place please move:

Can anyone tell me the frames per second speed that games such as RoboCop or Stormlord scroll at (when the player character is moving obviously).  They are pretty smooth compared to a lot of other CPC games and appear to scroll in 2 Mode 0 pixels (same size as 4 Mode 1 pixels).  I'm trying to make one of my Amstrad CPC-style PC games move the same way but I can't seem to get the speed right.  So how many times a second these games scroll when the player is moving.  That's what I'd like to know.  Thank you.

[Axelay]

Robocop looks to be running at 12.5FPS.  Stormlord is 17FPS, although perhaps it may drop to 12.5 if the screen gets busy with the way it clears each frame with the stack and redraws the whole screen, so if there's areas with a lot more tiles than usual it may slow down.

[reidrac]

Not sure how difficult would be to fake that because as Axelay said, it is usually 50 FPS divided by a factor. For example I usually update at 16.6 FPS in my games (50/3), because I don't scroll.

Keeping in mind that PCs usually refresh at 60 FPS... I would say: don't bother and make it feel nice in the platform you're developing for.

[Carnivius]

Not sure how difficult would be to fake that because as Axelay said, it is usually 50 FPS divided by a factor. For example I usually update at 16.6 FPS in my games (50/3), because I don't scroll.

Keeping in mind that PCs usually refresh at 60 FPS... I would say: don't bother and make it feel nice in the platform you're developing for.

I dunno.  They feel wrong when going at 60fps with the Mode 0 graphics.  I've tried 30 and currently got them at 15fps and it feels... fine but when I try match the speed up with a true CPC game scrolling on WinApe it doesn't seem quite right no matter how much I tweak it.   I don't want people to play the Amstrad CPC-style version running smoothly on a PC and then find the eventual true CPC version to feel really different or wrong in some way. 

[reidrac]

I dunno.  They feel wrong when going at 60fps with the Mode 0 graphics.  I've tried 30 and currently got them at 15fps and it feels... fine but when I try match the speed up with a true CPC game scrolling on WinApe it doesn't seem quite right no matter how much I tweak it.   I don't want people to play the Amstrad CPC-style version running smoothly on a PC and then find the eventual true CPC version to feel really different or wrong in some way.

I think it would be reasonable to expect differences.

Also take into account that WinAPE is doing its best to emulate the CPC but the output is still 60 FPS!

[RichTW]

I was very impressed with Stormlord on the CPC.  Does anyone know how it achieves such fast smooth scrolling?  Is it doing hardware scrolling (with rupture) using two screen banks offset at 2 pixels from each other?  Or is it doing a software scroll (effectively redrawing non-empty screen elements) with double buffering?  Or something else even more cunning?

[Axelay]

I was very impressed with Stormlord on the CPC.  Does anyone know how it achieves such fast smooth scrolling?  Is it doing hardware scrolling (with rupture) using two screen banks offset at 2 pixels from each other?  Or is it doing a software scroll (effectively redrawing non-empty screen elements) with double buffering?  Or something else even more cunning?

It's a software scroll, hardware double buffered.  It begins each frame with using the stack to clear the screen.  Then it prints the tiles over the freshly blanked screen.  I havent looked at the overall display loop, but presumably it's skipping the blank tiles.  Actually it must be, as those parallax stars are printed before the background.  The routine that prints the tiles is unrolled and uses the stack to read the tile data, interrupts are disabled.  It also appears to use separate routines for the partial edge tiles.

[RichTW]

I guess it would have been possible to do away with the 9k screen clear each update too, and only clear specific bits which need clearing, e.g. boundaries of scenery and moving sprites over blank background.  By my calculations, even a fully unrolled 9k screen clear using the stack takes around 200 scanlines.  Could at least have helped it run consistently in 3 frames, although it gets decidedly more complicated to actually implement once you need to keep track of all the moving boundaries.

[Axelay]

I was a bit surprised myself to find the game was using a complete screen clear to start each frame as well considering it's moving reasonably fast for a software scroll, as it's hard to imagine that approach being optimal on the CPC.

I made the clear timing estimate closer to 300 scan lines though, I suspect your time has been based on T-states or a 3 microsecond push, while push actually takes 4 microseconds on the CPC.  I went and timed the clear routine in use in stormlord and it works out to 335 scan lines in all.

But yeah it's hard not to think that surely keeping track of trailing edges & sprites to clear would be faster, without doing any code on it at least, but I guess it's one of those cases of presumably it was something like 100 scan lines on the spectrum and that could seem like a small price to pay for a much simpler approach.

[RichTW]

Yeah, I was doing it naively (11 T-states at 4MHz), but hadn't remembered the obscure way the cycles are stretched in order to share the bus with the video hardware (still not entirely sure how 3 memory cycles becomes 4us but I assume it's been measured/analysed).

So, yeah, in that case it's closer to 300 scanlines, basically 1 entire frame thrown away clearing the screen!  Shame that.  For sure, it will have been done entirely for simplicity reasons (I have a BBC Micro game which does exactly the same thing entirely out of laziness, which could be undoubtedly improved by only clearing what's necessary).

But I guess it paves the way for someone to do something Stormlord-esque at an even better frame rate!

[Carnivius]

I'm always somewhat amused when a topic I start evolves into tech talk I cannot understand.

It's very interesting though even if I can't make sense of it myself.

[Docent]

Yeah, I was doing it naively (11 T-states at 4MHz), but hadn't remembered the obscure way the cycles are stretched in order to share the bus with the video hardware (still not entirely sure how 3 memory cycles becomes 4us but I assume it's been measured/analysed).

Here you can find the explanation of this process:
http://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/msg136331/#msg136331

[Carnivius]

@Axelay
How do your games scroll smooth?  Edge grinder appears to scroll just 1 mode 0 pixel a time and is fast and smooth?  Are there any drawbacks?  Only suitable for a shoot em up or maybe a simple platformer along the lines of Turbo the Tortoise but all smooth?

[sigh]

I was a bit surprised myself to find the game was using a complete screen clear to start each frame as well considering it's moving reasonably fast for a software scroll, as it's hard to imagine that approach being optimal on the CPC.

I made the clear timing estimate closer to 300 scan lines though, I suspect your time has been based on T-states or a 3 microsecond push, while push actually takes 4 microseconds on the CPC.  I went and timed the clear routine in use in stormlord and it works out to 335 scan lines in all.

But yeah it's hard not to think that surely keeping track of trailing edges & sprites to clear would be faster, without doing any code on it at least, but I guess it's one of those cases of presumably it was something like 100 scan lines on the spectrum and that could seem like a small price to pay for a much simpler approach.

So in regards to Dynamite Dux which is also using a software scroll and a smaller screen (I think) while scrolling quite smoothly, are they replacing the whole screen, or are they just replacing the bits that are needed?

I've always been very impressed by the speed of that game, but I'm guessing this has a lot to do with the frame rate being quite consistent from what I remember.

[Axelay]

@Axelay
How do your games scroll smooth?  Edge grinder appears to scroll just 1 mode 0 pixel a time and is fast and smooth?  Are there any drawbacks?  Only suitable for a shoot em up or maybe a simple platformer along the lines of Turbo the Tortoise but all smooth?

All but Sub Hunter are hardware scrolls.  Edge Grinder is 1 mode 0 pixel per frame at 25FPS.  The technique used has a couple of drawbacks.  From a hardware point of view, it uses manipulating CRTC register 3, the monitor H-sync, which generally only works on analogue CRTs like the amstrad monitors.

The other drawback is that the R3 technique only gets you down to a two mode 0 pixel scroll, so in order to get a one mode 0 pixel scroll, the background graphics on one of the double buffered screens are offset by one mode 0 pixel, so a mode 0 pixel scroll can be achieved.  The problem that creates is you cant really *stop* scrolling without ceasing to use the double buffer.

The way the scrolling stopped at the end of Super Edge Grinder for the boss was to copy one buffer to the other, the lack of on screen action at that point hid the cpu time used by that process.  So in general the scrolling method used in Edge Grinder is best suited to continuous scrolling shooters, though it's always conceivable that someone could come up with a game design that might just work it into some other genre.

So in regards to Dynamite Dux which is also using a software scroll and a smaller screen (I think) while scrolling quite smoothly, are they replacing the whole screen, or are they just replacing the bits that are needed?

I've always been very impressed by the speed of that game, but I'm guessing this has a lot to do with the frame rate being quite consistent from what I remember.

It uses a tile system similar in principal to that used in stormlord, save it's an 8 way scroll, and skips the screen clear that used and instead redraws the entire screen with the tiles, then places the sprites on top.   But yeah, the play area is quite small too, just 24 chars wide and 16 high.

[Carnivius]

All but Sub Hunter are hardware scrolls.  Edge Grinder is 1 mode 0 pixel per frame at 25FPS.  The technique used has a couple of drawbacks.  From a hardware point of view, it uses manipulating CRTC register 3, the monitor H-sync, which generally only works on analogue CRTs like the amstrad monitors.

The other drawback is that the R3 technique only gets you down to a two mode 0 pixel scroll, so in order to get a one mode 0 pixel scroll, the background graphics on one of the double buffered screens are offset by one mode 0 pixel, so a mode 0 pixel scroll can be achieved.  The problem that creates is you cant really *stop* scrolling without ceasing to use the double buffer.

The way the scrolling stopped at the end of Super Edge Grinder for the boss was to copy one buffer to the other, the lack of on screen action at that point hid the cpu time used by that process.  So in general the scrolling method used in Edge Grinder is best suited to continuous scrolling shooters, though it's always conceivable that someone could come up with a game design that might just work it into some other genre.

It uses a tile system similar in principal to that used in stormlord, save it's an 8 way scroll, and skips the screen clear that used and instead redraws the entire screen with the tiles, then places the sprites on top.   But yeah, the play area is quite small too, just 24 chars wide and 16 high.

Is it possible (and hopefully faster) to just scroll part of the game area.  For example the bottom 64 pixels (ground with 16x16 tiles with a depth of 64, 48, 32, 16) scroll while the top area (a backdrop image) stays static with the added bonus of it looking like parallax scrolling?  With the player character able to move up and down normally between the two?

[Axelay]

Is it possible (and hopefully faster) to just scroll part of the game area.  For example the bottom 64 pixels (ground with 16x16 tiles with a depth of 64, 48, 32, 16) scroll while the top area (a backdrop image) stays static with the added bonus of it looking like parallax scrolling?  With the player character able to move up and down normally between the two?

For a software scroll, potentially faster, yes, and certainly possible.  You'd only be updating all the tiles in the scrolled area, so it would be much less cpu time for updating that compared to a full screen scroll.  Though you then need to do something to restore the background of the static part after sprites have passed over it, which is where the 'potentially' comes in.  You might use a dirty tile system to restore the areas that sprites have been on the static image, but if you have a game with a lot of sprites so that a large proportion of the tiles are 'dirtied' and need restoring, then you could lose much of any speed benefit.  I am guessing you just mean scrolling left and right with such an idea, rather than something multi-directional?

For a hardware scroll, it's also possible, it would enable you to do a 'normal' scroll following player movement in 2 mode 0 pixel steps without using register 3, so overcoming display compatibility issues, by allowing you to use 4 screens for the scrolling area.  That would take quite a bit of memory though, perhaps enough to only be a serious consideration for 128k, and add more complexity to the sprite routines, so the hardware scroll would lose a little of it's speed advantage over a software scroll, as they'd be needing to cross multiple screens with different base addresses.  Still an interesting possibility for the right game design though.

[Sykobee (Briggsy)]

I wonder if Stormlord would have been faster skipping the full 9KB frame clear, and instead having a 'fast black tile' rendering method when rendering the screen? I guess the screens were mostly blank tiles (over 50% I guess looking at a video), but even so a 1/2 frame method suitable for the Spectrum might not be the best option on the CPC if it uses a full frame. I think the game scrolls 2 mode 0 pixels at a time, but i guess it doesn't do dodgy R3 tricks.


Parallax stars could be post processed onto the frame - only draw onto black pixels (you would need two blacks though) - alternatively it could be part of the fast black tile rendering method. The brighter stars are actually sub-tiles as they scroll with the map.


Clearly the game hit a frame rate target that played well regardless of such an optimisation and they went with that.

[RichTW]

Yep, I suspect it would claw back some time.  I actually sped up a software scroll by one frame by doing exactly that - it makes sense as, otherwise, you're actually writing screen bytes twice per frame for non-blank areas.  Apparently there's occasional slowdown to 4 frames, so it might've been worth their while.

[Axelay]

I suspect Stormlord would not have been faster with a 'fast blank tile' and skipping the 9kb screen clear, but I do think it would likely have reduced the peak cpu load and helped stabilise the frame rate a bit higher.  More consistently at 17fps rather than dropping to 12.5 at times where there's lots of tiles quite as often.

I'm not saying the game really suffered from a lack of optimisation for the CPC though, but the sequel used the same approach and really did suffer with slowdown at times.  That one was quite disappointing to me.

[shaymanjohn]

Is Zynaps using a software scroll? Always thought that looked really good from a technical point of view...