I am trying to understand what the CPC's scrolling capabilities are, as I really am not sure on Whats what with it.? As I am not a programmer I am not familiar with these things.
When I was a kid I thought that the CPC didn't have hardware scrolling abilities and the sight of plenty of jerky games confirmed this. However since coming onto the CPCWiki forum ,I've heard people state 'crertain games are utilising the CPC's hardware scroll'.
Any chance of giving a run down on why hardware scroll was not used in plenty of games,
-was it because people were not aware of it?
-Or was it due to limitations?
- Does the hardware scroll work in the same Fashion Vertically as well as Horizontally
- Are the speed of the scroll limited,or is it highly variable ?
Thanks.
Hardware scroll only on CPC+ range of computers, not the first three models (464, 664 and 6128).
B-Asic v3.4 by longshot permits to use hardware scrolls with basic (rsx commands) on Amstrad CPC+.
Programmers are better now at using CPC hardware.
I don't have all the answers to that, there are probably games written in the past which could have used one scrolling routine over another. Hardware scrolling isn't necessarily smooth, Wonderboy for example has a Hardware Scroll.
Harrier Attack on the other hand is a series of Loops and a LDIR instruction to shift the position of the screen, your Plane in that game blinks because the plane needs to be deleted and redrawn as you travel through the game.
The 2 game variations of Get The Cash I made the early version I made uses the firmware SCR SW ROLL to Selectively Roll a portion of the screen Top to Bottom, this is described as a Software Scroll, unlike SCR HW ROLL which rolls the whole screen which has been described as a Hardware Scroll, though both Roll the screen the Height of a Text Cursor (which is 8 lines). Because I was physically moving the screen, objects in my game were flickering, so my later version uses a fake scroll to have the code move the money bags & brick walls through the playing field. Using this approach the screen doesn't move whatsoever, however if you get to the end of the game, the end of game sequence is using Software Roll to move the characters up and down the screen & on the Opening Loading Sequence I'm using similar technique as well as SCR GET LOCATION & SCR SET OFFSET for the Horizontal effect. That effect moves the whole screen, so it works best is nothing else is on the screen, it only survives I think because it's basic way to Horizontally Move the screen.
Quote from: genesis8 on 23:52, 09 December 16
Hardware scroll only on CPC+ range of computers, not the first three models (464, 664 and 6128).
B-Asic v3.4 by longshot permits to use hardware scrolls with basic (rsx commands) on Amstrad CPC+.
Programmers are better now at using CPC hardware.
Right, so it is true then the ordinary CPC didn't have scrolling. I wanted to check because a guy was making a point regarding Operation Wolf on the Atari St , he seemed to rate The ST version of OP Wolf , but I reckoned that the ST could have produced a far better game. I then mentioned how superb the CPC version was which Is a computer which doesn't have Hard Scroll. The guy insisted that CPC had the ability . So at that point I shut up cos wasn't sure whether I was wrong. I'm certain that it has been mentioned in the forum that there is a form of Hard scroll for the standard CPC.
So as we stand the standard CPC does not have hardware scroll.
Posted this at the same time as AMSDOS,s reply so amended as Amsdos tells us that Hardware scroll is available
Unfortunately I don't have a lot of detailed knowledge about the CPC+. In a sense it has Hardware Sprites (the CPC has not), so the Hardware Scrolling @genesis8 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=215) is referring to, is seperate from the Hardware Scrolling in a CPC, so I'm presuming the CPC+ Hardware Scroll gives the programmer a set of tool to easily code it into ones program, on a CPC the coder has to worry about all the other things which need to happen as a result of moving the screen, which is probably where most coders have a different approach to the same problem.
I'm just going by the Information from the Unofficial Amstrad WWW Resource (http://cpctech.org.uk) which details "A list of games that use demo programming techniques. (http://cpctech.cpc-live.com/docs/games.html)", but it also talks about SCR HW ROLL as being a Hardware Scroll in the Source Code (http://www.cpctech.org.uk/source.html), which rolls the screen either up or down. That particular instruction is a part of the Firmware, so in a sense is a tool for the programmer, but as I mentioned earlier it shifts everything either up or down 8 pixels (one cursor line) and the coder has to delete/redraw anything they don't want to move, but I would have imagined that to be happening on a Plus, though it probably has better management of moving scenery across the screen and not having to worry about it appearing on the other side of the screen and perhaps more versatile on the size of the area to move and what direction to move it?
Quote from: Puresox on 00:13, 10 December 16
Right, so it is true then the ordinary CPC didn't have scrolling.
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.
Quote from: AMSDOS on 01:44, 10 December 16
That particular instruction is a part of the Firmware, so in a sense is a tool for the programmer, but as I mentioned earlier it shifts everything either up or down 8 pixels (one cursor line) and the coder has to delete/redraw anything they don't want to move, but I would have imagined that to be happening on a Plus, though it probably has better management of moving scenery across the screen and not having to worry about it appearing on the other side of the screen and perhaps more versatile on the size of the area to move and what direction to move it?
Hardware scrolling always affects the entire screen display, in both the original and Plus variants. The trick if you want a static section is to hardware scroll the screen and then "software scroll" the static section back in the opposite direction so that it appears static (assuming of course that your scrolling region is larger than your static one!) Anything too fancy, like scrolling a Window in BASIC, is generally better done with software scrolling routines.
The Plus however, has a few more tricks up it's sleeve. Firstly you can adjust the SSCR at any point in the display and the effect takes place instantly. So if you want to reset the scrolling at a certain point you just need to wait for that scan line and reprogram the register, something made considerably easier by the fact you can configure raster interrupts to fire on specific scanlines rather than the fixed points of the original models. Secondly you can start a new screen display coming from a separate 16K bank on any given scanline (like "rupture splitting" only a lot easier), so that any character scrolling in effect won't move your fixed screen section nor will you have to worry about screen wrapping causing issues.
CPC+ offer a pixel precise shift into the first memory word displayed and a split screen facility.
This is still not a true scrolling management
Quote from: andycadley on 06:21, 10 December 16
No. Although from a gaming perspective, it's mostly true.
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.
I don't really agree with this. If the question was about CPC hardware scrolling being as versatile as on say the C64, or can 50fps mutli-directional scrolling be achieved in any given case, then of course the answer is no. But the comparison that is relevant in my view, is how does the CPC hardware scrolling compare to software scrolling as it was often ported from the spectrum, and in many cases, those games have tiny play areas, single digit frame rates, and as often as not, actually scroll in character steps, just like the hardware scroll anyway!
So even ignoring more advanced CRTC use for fine scrolling and sticking with the coarse scroll, I think there are benefits to the CPC hardware scroll in games. Not throwing buckets of cpu time at shifting the screen means you have plenty for those more complex sprite routines, and if you can make the same game work with a 50%+ bigger play area and up to double the frame rate, I see that as only a good thing for the game play. I think games like 5th axis, Boulder Dash, Eagles Nest and Monty Python all show examples of how simple coarse scrolls can work well. Not everyone will be a fan of those scrolling implementations, or the games for that matter, and of course these approaches would not suit every game, but to me those larger 12-16kb play areas and generally higher frame rates than you get in most software scrolling games is an obvious benefit to those games.
Quote from: roudoudou on 08:22, 10 December 16
CPC+ offer a pixel precise shift into the first memory word displayed and a split screen facility.
This is still not a true scrolling management
In that case the c64 doesn't have a true scrolling management.
It can pixel shift the graphics but then you still need to move all the graphics after you have used all the shifts.
Some c64 games make this quicker because they use chars for the display.
Yes the CPC has hardware scrolling. It does this by changing the start address for the screen and the graphics wrap at 16KB.
For horizontal, you add/subtract 1 from the start address.
For vertical you add/subtract 40 from the start address (based on the default screen width).
Do this over and over and you have vertical or horizontal scrolling or both.
Some games use it but not a lot.
It has limitations.
Normally it's 8 lines vertical movement and mode 1 char horizontally.
So it's fast and chunky. This often makes it unsuitable.
To use it you update the screen start, then draw a column and/or row (depending on if you are scrolling horizontally, vertically or both).
It operates on the entire screen too.
Demo programmers showed that you can overcome some limitations:
1. some part scrolling, some part static
2. 1 scan-line scrolling vertically (ok on all monitors and televisions)
3. 1/2 a mode 1 char horizontally (monitor/television response permitting)
A lot of game programmers either didn't know how to do the demo tricks, or they couldn't make them work with all cpcs, or they couldn't make them stable or it was too fast a scroll.
Also, hardware scrolling has one other complication:
At the point of screen wrapping the calculations for drawing sprites are a bit more complex.
So I think it comes down to:
- it was too fast and they didn't want it that fast
- they didn't know how to make it smoother
- they were porting from spectrum and just converted it's software scrolling.
Plus gives extras to help.
C64 in comparison:
- you can shift the screen by 8 pixels
- if you want to scroll the screen you then need to copy the graphics (bitmap mode and about 8K) OR copy chars (much less ~1K)
- if copying chars they split it over multiple frames to reduce time
- they could easily split the screen into scrolling and static.
looking at a lot of the commercial games that used cpc's hardware scrolling it seems like the programmers didn't know how to use it or didn't have time to use it properly.
They do stupid things like pause all the action while scrolling, or if you need to move diagonally they move horizontal THEN vertical when both can be done. This really gave a bad impression.
Quote from: arnoldemu on 12:18, 10 December 16
In that case the c64 doesn't have a true scrolling management.
It can pixel shift the graphics but then you still need to move all the graphics after you have used all the shifts.
Some c64 games make this quicker because they use chars for the display.
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.
Quote from: Axelay on 12:15, 10 December 16But the comparison that is relevant in my view, is how does the CPC hardware scrolling compare to software scrolling as it was often ported from the spectrum, and in many cases, those games have tiny play areas, single digit frame rates, and as often as not, actually scroll in character steps, just like the hardware scroll anyway!
I'm not sure that's entirely fair on many conversions. Look at the good example like Batman The Movie, Robocop etc and they're just not something that's feasible using only character based scrolling. That said, I was mostly thinking of the kinds of (mostly) continuous scrolling shooters etc, where getting a consistent fluid scroll is most important - certainly there are other varieties of game where coarser scrolling is not so bad and there are plenty of games that could have benefitted from it rather than using a quick port from the speccy.
Quote from: reidrac on 12:36, 10 December 16
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.
Interesting.
To me, changing the screen address to do the scroll is a simple thing that can be done easily and has no tricks to it. The screen moves. You need to do some drawing with the cpu to plot graphics to scroll a map, but the same is true of the Plus and c64.
So does the Plus have hardware scrolling?
And does the C64 have it?
Quote from: arnoldemu on 12:46, 10 December 16
To me, changing the screen address to do the scroll is a simple thing that can be done easily and has no tricks to it. The screen moves. You need to do some drawing with the cpu to plot graphics to scroll a map, but the same is true of the Plus and c64.
What's more, I'm pretty sure that feature exists in hardware precisely to give the ability to scroll text based screens easily.
Quote from: andycadley on 12:46, 10 December 16
.. That said, I was mostly thinking of the kinds of (mostly) continuous scrolling shooters etc, where getting a consistent fluid scroll is most important - certainly there are other varieties of game where coarser scrolling is not so bad and there are plenty of games that could have benefitted from it rather than using a quick port from the speccy.
MSX Nemesis:
Is it more that we can't accept the chunky scroll on CPC?
Quote from: reidrac on 12:36, 10 December 16
I don't see this a big deal to be honest.
To me it is. People say the CPC can't do scrolling and people say it doesn't have hardware scrolling.
From my criteria and perspective it does so I disagree with you and say it does.
My point is it does but people chose not to use it. I can think of reasons why, but I wish I could ask them to find out why they didn't consider it.
Quote from: arnoldemu on 12:46, 10 December 16
Interesting.
To me, changing the screen address to do the scroll is a simple thing that can be done easily and has no tricks to it. The screen moves. You need to do some drawing with the cpu to plot graphics to scroll a map, but the same is true of the Plus and c64.
So does the Plus have hardware scrolling?
And does the C64 have it?
Well, because the CPC can do 4 bit per pixel in mode 0 you could argue in the same way that it support bit planes and hence fast blitting of sprites ;)
You can use hardware to implement some types of scroll, but I don't think that's hardware scrolling.
Quote from: reidrac on 12:55, 10 December 16
Well, because the CPC can do 4 bit per pixel in mode 0 you could argue in the same way that it support bit planes and hence fast blitting of sprites ;)
You can use hardware to implement some types of scroll, but I don't think that's hardware scrolling.
Not really, the memory layout of the display on the CPC isn't planar so you can't really say it supports bit planes in any sense.
As to whether you think it counts, I guess that's up to you. But if you exclude it, you kinda have to also say machines like the C64, Master System and NES also don't have hardware scrolling because all of those basically work in a similar fashions....
Quote from: andycadley on 12:46, 10 December 16
I'm not sure that's entirely fair on many conversions. Look at the good example like Batman The Movie, Robocop etc and they're just not something that's feasible using only character based scrolling. That said, I was mostly thinking of the kinds of (mostly) continuous scrolling shooters etc, where getting a consistent fluid scroll is most important - certainly there are other varieties of game where coarser scrolling is not so bad and there are plenty of games that could have benefitted from it rather than using a quick port from the speccy.
Well I did say many cases, not all, and that it would not suit all games. So I agree there were
some great software scrolling games, but I would argue that games such as those you have mentioned form a significant minority, personally.
On the subject of continuous scrolling shooters though, I like to think I've already made some arguments about that previously. ;)
Quote from: arnoldemu on 12:49, 10 December 16
Is it more that we can't accept the chunky scroll on CPC?
That somehow doesn't look quite as bad as I'd expect (maybe the starfield effect is helping counter it to some extent?) - it'd certainly be something interesting to try out. R-Type on the Speccy is also character based but has the advantage of a very slow scroll speed and moving enemies more frequently than the background, so there are certainly some things that could be worth trying out.
Nice reading.
CPC-power has some useful tags about HW-scroll. I suggest you guys check (for games with HW-scroll):
http://www.cpc-power.com/index.php?page=database&lemot=Scroll%20Hard%20vertical
http://www.cpc-power.com/index.php?page=database&lemot=Scroll%20Hard%20horizontal
http://www.cpc-power.com/index.php?page=database&lemot=Scroll%20Hard%20multidirectional
For those who might not understand what's going on, I'll try with less text.
CPC screen might be set to start anywhere in 16 KB video-ram.
Precision is not pixel but characters.
One could say: we have a scrolling 40x25 screen/windows within 1024 characters from VRAM.
Since only 2 registers changes from HW (i.e. CRTC) are required, we coud write: this is an HW-scroll.
Below:
windows with red border is the 1024=&400 characters VRAM.
windows with white border is the 40x25 screen; also seen on right side.
Scrolling +40characters
(http://www.msxvillage.fr/upload/hw-scroll_40.gif)
Scrolling +1character
(http://www.msxvillage.fr/upload/hw-scroll_1.gif)
Quote from: Overflow on 14:30, 10 December 16
CPC screen might be set to start anywhere in 16 KB video-ram.
CPC screen start adress has only 1024 positions in a 16kb bank as the CRTC start adress is everytime in the first 2K block of a bank (word precision).
With some nasty tricks you may add insivible lines to cheat and start everywhere (still word precision) but later after the screen begun (as far as i remember)
Am I trolling? I would like to
like this explanation twice.
Quote from: arnoldemu on 12:26, 10 December 16
Yes the CPC has hardware scrolling. It does this by changing the start address for the screen and the graphics wrap at 16KB.
For horizontal, you add/subtract 1 from the start address.
For vertical you add/subtract 40 from the start address (based on the default screen width).
Do this over and over and you have vertical or horizontal scrolling or both.
Some games use it but not a lot.
It has limitations.
Normally it's 8 lines vertical movement and mode 1 char horizontally.
So it's fast and chunky. This often makes it unsuitable.
To use it you update the screen start, then draw a column and/or row (depending on if you are scrolling horizontally, vertically or both).
It operates on the entire screen too.
Demo programmers showed that you can overcome some limitations:
1. some part scrolling, some part static
2. 1 scan-line scrolling vertically (ok on all monitors and televisions)
3. 1/2 a mode 1 char horizontally (monitor/television response permitting)
A lot of game programmers either didn't know how to do the demo tricks, or they couldn't make them work with all cpcs, or they couldn't make them stable or it was too fast a scroll.
Also, hardware scrolling has one other complication:
At the point of screen wrapping the calculations for drawing sprites are a bit more complex.
So I think it comes down to:
- it was too fast and they didn't want it that fast
- they didn't know how to make it smoother
- they were porting from spectrum and just converted it's software scrolling.
Plus gives extras to help.
C64 in comparison:
- you can shift the screen by 8 pixels
- if you want to scroll the screen you then need to copy the graphics (bitmap mode and about 8K) OR copy chars (much less ~1K)
- if copying chars they split it over multiple frames to reduce time
- they could easily split the screen into scrolling and static.
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!
For a more technical discussion on scrolling:
http://www.cpctech.org.uk/hwscroll.txt
Quote from: reidrac on 12:36, 10 December 16
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.
@reidrac (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1504): 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.
Quote from: arnoldemu on 22:12, 10 December 16
@reidrac (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1504): 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.
Yes, of course displacing the screen by writing CRTC regs R12/R13 is hardware scrolling. The 6845 datasheet says:
QuoteHardware 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 (https://www.youtube.com/watch?v=bNRlnNIOXwk). 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 (https://www.youtube.com/watch?v=PqLXXD0pVH0) may not work well on character-mapped platforms such as the C64!
Quote from: andycadley on 06:21, 10 December 16
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 .?
Quote from: Puresox on 00:25, 14 December 16
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.
Ahhh right ,I think I follow what you are saying .thanks
I think it fits well here..
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.
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. :)
Wow that looks amazing!
Is there some way you could overlay a sprite on that?
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.
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.
Quote from: reidrac on 14:01, 24 October 23Obviously 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"
Quote from: Anthony Flack on 08:36, 26 October 23Quote from: reidrac on 14:01, 24 October 23Obviously 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 :D
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.
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.
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.
Quote from: Anthony Flack on 23:03, 28 October 23I can't help but feel many CPC games would have been improved by prioritising framerate over scrolling.
Too true!!
Quote from: Anthony Flack on 23:03, 28 October 23It'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.
Quote from: Anthony Flack on 23:03, 28 October 23This 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
Quote from: Anthony Flack on 23:03, 28 October 23John 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.
Quote from: Anthony Flack on 23:03, 28 October 23I 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.
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...