Dummies guide to Amstrads scrolling abilities....

[Puresox]

Looks like I've got plenty of info to read through on scrolling , appreciated
I haven't digested all of the thread as yet , but will be going through it, If it has been mentioned already ignore this request.


Could a list of games be made which demonstrate each different Scroll technique? Or would that be an impossible task.?
For Example Roland in Space has - This type scrolling
What was TLL's scrolling ? Such an early game with a great scroll!

[arnoldemu]

For a more technical discussion on scrolling:

http://www.cpctech.org.uk/hwscroll.txt

[AMSDOS]

I guess people refer as "hardware scroll" when the hardware provides some sort of assistance; then CRTC tricks or changing the video memory address could get into this category; but I don't think was designed as a away to do scroll, I see them like the tricks you can do in the speccy to get more colours in a 8x8 char; that doesn't mean the platform supports more colours.

Because of that I agree with the idea that the CPC range (not the CPC+) don't have that hardware assistance, and hence "no hardware scroll".

I don't see this a big deal to be honest. You can make games that show more colours that in any other 8-bit home system, and that has value; even if that means you're limited when trying to implement scroll. Use the strengths and get the best you can from the weaknesses.

This was what I was wondering about earlier, performing a trick using the hardware to make the screen move Vs. some routines for the programmer to use. But then I was asking about the Firmware SCR HW ROLL as being defined as a Hardware Scroll which has been setup for a programmer to use.

[arnoldemu]

@reidrac: I understand your point.

The designers of the 6845 wrote in the documentation:

"Scrolling of the display is accomplished by changing R12 and R13 to the memory address associated with the first character of the desired line of text to be displayed first. Entire pages of text may be scrolled or changed as well via R12 or R13".

The 6845 seems to be designed for character based displays. It generates addresses and additional hardware uses that to generate pixels and output them. They mention scrolling, but I don't think their intention was for games and probably more for vertical scrolling or for moving through pages of text. The 6845 couldn't really have additional scrolling assistance because that is for the additional hardware to perform.

In SOFT158 Amstrad wrote:

"The  screen  offset  sets  which  byte  in  the  screen  memory  is  to  be  displayed  first. Changing  the  screen  offset will move the contents of the screen in one go. This is used for rolling the screen."
Amstrad don't seem to mention horizontal scrolling and they refer to it as "rolling" and to me this means vertical movement. So in this case yes I don't think they designed it for scrolling. If they had then they would have used a different chip or added assistance like they did with the Plus.

Take the PCW, this has "roller" ram. It has a table of screen addresses and it's designed for vertical scrolling and for text. The hardware is designed so that you can do smooth vertical scrolling. To do horizontal scrolling is much harder and it's clear they didn't design it for horizontal scrolling.

So my opinion is that the CPC wasn't designed for scrolling whereas the c64 was.

[Axelay]

@reidrac: I understand your point.


So my opinion is that the CPC wasn't designed for scrolling whereas the c64 was.

I've yet to see anyone make a case for how the intent of the designers or the limitations in the functionality is even relevant.


If you are scrolling the screen by changing registers on the CRTC - the display hardware - you are hardware scrolling.  That's all it means.  It describes what you are doing.  It isn't software scrolling.

[RichTW]

Yes, of course displacing the screen by writing CRTC regs R12/R13 is hardware scrolling.  The 6845 datasheet says:

Hardware scrolling by character, line or page may be accomplished by modifying the contents of this [Start Address] register

It may not be pixel-by-pixel (although with the R5 trick and rupture, you can get pixel-by-pixel vertical scrolling), but it clearly isn't block copying screen data in software, as is required by other platforms (e.g. Spectrum, Oric).


As was mentioned upthread, while the C64 may have pixel-by-pixel scrolling within the range of a character, it actually requires a software scroll to move the screen beyond character granularity.


Coming from my background on the BBC Micro which also has a 6845, there were plenty of games which exploited its scrolling capabilities to the hilt, such as
Repton.  I think, as ever, certain types of games suit certain types of hardware better than others.  A slow horizontal scroller doesn't work well on a 6845 based machine, but then a
racing game may not work well on character-mapped platforms such as the C64!

[Puresox]

No. Although from a gaming perspective, it's mostly true.


The ordinary CPC models are arranged so that there screen display fits within one of four 16K blocks of main memory. How far into that memory block it starts can be configured in Mode 1 sized character chunks (with the screen "wrapping" around inside the block). Adjusting this value will therefore cause the screen to scroll in Mode 1 sized amounts in any direction - adding one causes the screen to shift to the left, subtracting one to the right, adding 40 scrolls up etc. This is why BASIC, for example, is always responsive in scrolling program listings - it's letting the hardware do all the work and not actually shifting any data around at all.


It works very well for text screens but less so for games. For one thing it's usually too big a movement for playable games since you either have to shift the screen around so quickly nobody has chance to react or you only scroll every few frames at which point everything seems to jerk about anyway and the benefits of "hardware scrolling" are lost. There is also that "wrapping" issue, which makes screen addressing on a shifted screen display more complicated than usual, potentially complicating things like sprite routines and there isn't much benefit to scrolling smoothly if the entire game is slowed down by more complicated sprite logic.


That said, there are certain hardware tricks that can be used to improve the resolution of the scroll beyond what it is supposed to be able to do, Mission Genocide being a fine example of how well it can work when done right. The downside of such tricks is that they're more complicated to program and aren't necessarily universally compatible. Some don't entirely work on different CRTCs (or need subtly different values programmed), some don't always work on TVs through a modulator etc.


The Plus range augment the scrolling capabilities via a new (and confusingly named) Soft Scroll Control Register in the ASIC. This allows you to shift the screen up to 16 Mode 2 pixels horizontally and 7 Mode 2 pixels vertically and thus is more reminiscent of the hardware scrolling in machines like the C64, allowing shifting the display by up to a Mode 1 character in either direction. By combining the two methods you actually go one better than the C64 and can pixel scroll the display in any direction without ever having to actually move anything around in memory at all. Hardware sprites are a major boon in this instance because they aren't affected by the screen addressing changes making the whole thing just a lot nicer and removing much of the display complexity around wrapping.

The complete thread has given me some great perspective into how Scrolling works, I admit I don't fully grasp it ,but it definitely is useful and pretty well described, I know for sure I have picked up a lot more understanding of the machine since finding the CPCWiki.


The paragraph highlighted above talks about how certain scrolling may have issues depending on different monitors or CRCT's. I'm surprised that this would be an issue , interested how it would affect. Is it just a case of some TV's may produce an ugly scroll ? Or is it something other than that .?

[andycadley]

The paragraph highlighted above talks about how certain scrolling may have issues depending on different monitors or CRCT's. I'm surprised that this would be an issue , interested how it would affect. Is it just a case of some TV's may produce an ugly scroll ? Or is it something other than that .?

Well, bear in mind that this is well into the "demo coder" approach to doing things, so the problems tend to arise because you're operating well outside the specified behaviour and relying quite heavily on quirks that happen when the hardware is in a technically invalid state. A common example is playing with the length of a HSYNC pulse and knowing that this will cause an Amstrad monitor to slightly shift the physical position of the screen in the display (thus allowing a finer adjustment than normally possible). It's a great trick, but other displays may not cope with it in quite the same way, resulting in anything from jerky scrolling to the display completely losing sync and giving that "rolling" effect like an old broken CRT. The problem tends to be more pronounced on modern LCD displays, which don't work in the same way as CRTs and thus are less likely to respond in the "analogue" ways these kinds of trick depend upon.

[Puresox]

Ahhh right ,I think I follow what you are saying .thanks

[asertus]

I think it fits well here..

[Anthony Flack]

Seven years late, but yeah that's a good example.

Full screen hardware scrolling was actually pretty common in the early Amsoft games. Roland in Space and Tornado Low Level are two other good examples that were also mentioned. 3D Stunt Rider is one that uses a combination of different techniques including hardware scrolling, I think? Once the CPC started seeing more Spectrum ports the hardware scroll was used less.

Correct me if I'm wrong about any of this: Killer Cobra and Ghosts n Goblins are examples that use the nudge technique to get a smoother hardware scroll. Relentless also demonstrates a smooth horizontal hardware scroll; I think in this case the nudge is baked into the double buffer. Abduction of Oscar Z also shows a nice horizontal hardware scroll that makes the most of the bitmap display by generating levels built on continuous curves rather than tile-based.

Mission Genocide was the first example of a smooth (1 pixel) vertical scroll in hardware but it has since been used to great effect in many homebrew games such as Red Sunset and Pinball Dreams. These games also demonstrate how you can "rupture" the display to hardware scroll only part of the screen. 

There are all kinds of creative ways you can use the CRTC offset. The wonderful Logon's Run demo is animated entirely with clever CRTC offsets.

Operation Wolf is a fast software scroll. It would be pretty much impossible to use a hardware scroll here without messing up the side panel. Sub Hunter is a fantastic example of just how fast you can make a pure software scroll by directing the stack pointer at the screen and throwing registers at it. Scramble also achieves a nice, fast software scroll by only drawing the edges of the ground.

Vespertino, when it comes out, should be a great example of mixing hardware and software techniques.

The C64, as was mentioned, had to do character scrolling in software. During its lifetime, it struggled to pull off a full-screen scroll that shifted both the tile data and colour data, leading to many games with drab backgrounds. It wasn't until democoders discovered a glitch in the VIC-2 chip that actual hardware scrolling (horizontally) on the C64 became possible. Mayhem in Monsterland is the first game that used that technique to scroll a full-colour background.  

[ZbyniuR]

Amstrad is able to made fluent 1 pixel line scroll but only in vertical. 

Or more simple jump by 8 lines in 8 directions. This is so easy even in pure Basic.

10 DEFINT a-z:' here you can load some screen
20 IF INKEY(1)=0THEN t=t+1ELSE IF INKEY(8 )=0THEN t=t-1
30 IF INKEY(0)=0THEN t=t-40ELSE IF INKEY(2)=0THEN t=t+40
40 t=(t+1024)MOD 1024:v=48+t\256:w=t MOD 256:OUT&BC00,13:OUT&BD00,w:CALL&BD19:OUT&BC00,12:OUT&BD00,v:GOTO 20

And now try move by arrow keys.

[Amagni]

Wow that looks amazing!

Is there some way you could overlay a sprite on that?

[Anthony Flack]

Totally, you just have to make sure the sprite can cope with being drawn over the part of the screen where the memory wraps around.

[reidrac]

Now that this thread is back from the dead, I'll add an example of vertical scroll in Hyperdrive:


https://www.youtube.com/watch?v=KlLn5JdyYEM

Obviously I made the game I wanted to make, but still some connoisseurs complained about the gameplay not being what they wanted it to be. But I digress.

To be fair, the scrolling wasn't the hard part nor the screen split. It was also moving sprites and making a game with that.

[Anthony Flack]

Obviously I made the game I wanted to make, but still some connoisseurs complained about the gameplay not being what they wanted it to be. But I digress.

As somebody who enjoys the early golden age shooters, I appreciate paying homage to that overlooked era, and it's frustrating that genre expectations have narrowed people's idea of what makes a good shmup. I made a prototype once where you could only fire one bullet at a time, as a deliberate mechanic, and everybody I showed it to said "this is not ok"

[reidrac]

Obviously I made the game I wanted to make, but still some connoisseurs complained about the gameplay not being what they wanted it to be. But I digress.

As somebody who enjoys the early golden age shooters, I appreciate paying homage to that overlooked era, and it's frustrating that genre expectations have narrowed people's idea of what makes a good shmup. I made a prototype once where you could only fire one bullet at a time, as a deliberate mechanic, and everybody I showed it to said "this is not ok"

In my game is not the case. The demo is doing that for precision, but as you get power ups, the rate increases. So there's more to it. I think the complaints came more from the puzzle component of the game (you need to complete a chain of 9 kills on a specific time to get a power up).

Give it a go: https://www.usebox.net/jjm/hyperdrive/

When I released it, I was invited to a stream to discuss the game. The guy interviewing me had never played the game but once he understood the mechanics, he got to stage 5 (or something like that) in less than the 2 hours that we were chatting.

If someone expects DoDonPachi gameplay with smooth scroll at 25Hz on the CPC, this is not it; and I'm not sure if those expectations are fair TBH

[Optimus]

That reminds me when people are arguing whether Doom is 2.5D or 3D

It can be vague, I thought since you can change vram offset address even if it's choppy character offset, then CPC has hw scroll, just not smooth.
Now others argue whether the CPC+ has multiplexed sprites or not, my definition was if you can re postion the sprites to display more than 16 it has. For me multiplexing was displaying more than the theoritical. But of course you cannot change the address of the sprite so for others it's not multiplexing.

But anyway, like all things, we try to categorize in strict boxes. That's how people come and say "how can this platform not displaying better gfx if it's 64bit?". It's not that simple and would need extensive explanation. I consider Doom 3D because I don't like the 2.5D definition, even though I know the ins and outs of it's engine and I know it's not doing polygons. But it becomes subjective.

[Anthony Flack]

Hyperdrive is great; I can finally play it now I have an M4. Getting full chains after stage 1 is definitely tough, but should make sense to anyone who ever tried chain-routing DoDonPachi. Anyway, the beauty of free games is you don't have to please anybody... 

I'm itching to do a shooter for the CPC myself as I have some other ideas I want to try out. 

[Anthony Flack]

It's interesting to consider the MSX and Sega SG-1000 games - machines that lacked the ability to do a smooth background scroll. Coders simply accepted character-step scrolling and got on with it, making games with jerky scrolling that are still perfectly playable, with good framerates. I played Zippy Race on the SG-1000 and you'd think the lack of smooth scrolling would kill that game but you know what, it actually captures the feel of the arcade pretty well. Elevator Action is the same. The scrolling isn't pretty, but it doesn't actually matter.

This would have been considered unacceptable on the CPC where standard practice was to do an all-software scroll in a tiny window and run at 8fps instead. Of course the lack of hardware sprites tended to push people in this direction but I can't help but feel many CPC games would have been improved by prioritising framerate over scrolling.

John Brandwood was one of the few people sensible enough to see that smooth scrolling was largely irrelevant to gameplay and a good framerate is much more important. Gryzor and Renegade play just fine without a full scroll.

I don't know if you saw, but somebody made a version of Jet Set Willy (for the PC) which is fully scrolling, like Roland in Space. This was very interesting to me because it doesn't improve anything... it actually kind of ruins the exploration aspect.

[dodogildo]

I can't help but feel many CPC games would have been improved by prioritising framerate over scrolling.

Too true!!

[andycadley]

It's interesting to consider the MSX and Sega SG-1000 games - machines that lacked the ability to do a smooth background scroll. Coders simply accepted character-step scrolling and got on with it, making games with jerky scrolling that are still perfectly playable, with good framerates.

Maybe true of the SG-1000, but the MSX had it's fair share of Speccy ports which, if anything, played even slower than those on the CPC. A lot of which were pixel scrolling games rather than chunky character scrolling.

This would have been considered unacceptable on the CPC where standard practice was to do an all-software scroll in a tiny window and run at 8fps instead. Of course the lack of hardware sprites tended to push people in this direction but I can't help but feel many CPC games would have been improved by prioritising framerate over scrolling.

Lack of hardware sprites is a big issue though, it's harder and slower to write software sprite routines that can cope with the screen wraparound that occurs with CPC hardware scrolling

John Brandwood was one of the few people sensible enough to see that smooth scrolling was largely irrelevant to gameplay and a good framerate is much more important. Gryzor and Renegade play just fine without a full scroll.

But for every Renegade, there is a Pacland. Where the game is entirely broken by replacing the scroll with a flip screen. Sometimes you can get away with tampering with the mechanics of a game and still keep it playable and sometimes you just can't.

I don't know if you saw, but somebody made a version of Jet Set Willy (for the PC) which is fully scrolling, like Roland in Space. This was very interesting to me because it doesn't improve anything... it actually kind of ruins the exploration aspect.

The Amiga version notably did the same and was awful as a result. Another example of a game where you can't just make random alterations and assume it'll play the same or better. It needed the flip screen to work properly.

[Anthony Flack]

I guess I'm thinking more of the Japanese MSX games. Same graphics chip, different culture...

Lack of hardware sprites is ALWAYS a pain, but you can easily check if your sprite is in a wraparound position and use your regular routine whenever it's not. It's a pain to write sprites that cross the edge of the screen in any case. 

But even if you keep it all in software... did anyone really mind that Rick Dangerous doesn't scroll properly?

Scrolling or not scrolling is a separate issue to being able to see what's in front of you. Pacland is ridiculous because it makes you walk ALL the way to the edge of the screen. Gryzor would have been ruined too if they'd done that. And Pacland doesn't even run particularly well!

If it updated at half-screen intervals it would have worked all right. A slow, chunky scroll, or a push scroll like Ghosts n Goblins would have worked all right. A smooth continuous scroll would be better, but if you can't have everything...