hardware scrolling in games

[arnoldemu]

Then good luck with the Job. I hope you get it.

Bryce.

I agree with you Bryce. Macdeath, I hope you get it.

[arnoldemu]

rastan uses both rupture and hardware scrolling. The hardware scrolling is char based (no r3, r5 tricks here).
Made by the same programmer who made Turrican (which uses the same scrolling I think, but more limited display).

I think both are good examples of hardware scrolling. True, the scrolling is char based, but it's not too bad, and it's not confusing when it scrolls.

True both are close to being type 1, but also they are a little like type 2.

I think I'll re-work the hardware scrolling page I'm writing to use the ideas from MacDeath, they make more sense here about how to categorise them.

I also looked at Fred/Roland on the Ropes, ok the game is old, it has some flicker, but it's a nice example of hardware scrolling. It too is char based, but done well. The flicker comes from redrawing the status panel. Could have been done better with rupture here, but it's ok.

[MacDeath]

It could be interesting to put a link to this past topic :
character-based tile engine with parallax scrolling

The character-based tile engine with parallax scrolling made by Ervin in C.

Yes, character based scrolling can be good actually, provided the eyes are tricked by some other stuff like kool looking graphics, also provided it is fast enough so you don't really see the big characters steps-by-steps movement.

Slow scrollings don't like charbased scrolling, fest scrolling is fine with this.
Get a look at R-Type for the MSX1... the slow charbased scrolling really hurts.
What may trick you into believing the game is somewhat smooth is the fact the R-9 is done through Hardsprites which move smoothly (but the fires are charbased too anyway)

On the Speccy-CPC, it is done differently as the "sprites" are charbased entirely, but the "backgrounds" manage some smooth effect (still the shadow from the characters can be seen during the movement).

I wondered, is it possible to use 4x4 (mode1) characters so it is actually quite smooth ?
I guess the fact it goes for 4xtimes more characters to address can be problematic on the other side (as each character would be 1/4 of a real character)

Rick Dangerous was fun in that it managed to have no horizontal scrolling but had a vertical flip screen scrolling (fast one) and simply horizontal flip screen (not scrolled)... this is quite interesting as it is an "exploration" platformer...
Jet set Willy could have use such thing I guess.

The "Railroad" or "exploration" aspect can be important.
Railroad would often get only on direction automatic scrolling... (no possibilities to go back).

Xenon2 megablast on the otherhand, while a vertical shooter, managed to enable the player to go back a little bit.

SpaceGun (arcade version) while an Operation Thunderbolt/Wolf clone, also had such feature.

A few games' "engines" were somewhat screwed up because they tried too hard to include an additional scrolling.

Copter 271 for GX4000 is an example.
the horizontal scrolling is actually handicapping the game hardly, add to this the perhaps too big sprites (well, magnified Harsdsprites).
More proper solution would be (in that case) to simply skip/remove the horizontal scroll (this ease the engine/CPU a lot I guess) and perhaps to even aim at a 256 vertical resolution.


Strider on the amstrad (and speccy... as it is speccy port) also has a few scrollings issues in my opinion.
This is mostly due to the fact the screen is quite small, while the player's sprites is proportionnally big in this (almost arcade sized, somewhat).

As a result, each time you jump the vertical scrolling is activated (ouch) so you stay inside the playfield (unless at an edge of the level map)...

Had the screen dimensioned bigger, the scrolling would be far less demanded and the game smoother.

That's the problem with both speccy port and poorly designed games on CPC.


R-Type on NEC PC-engine console was also like this.
It is pixel perfect with arcade, but as PC engine had an inferior vertical resolution, it adds a vertical scrolling.

So developers often have to resize the whole game (when dealing with arcadeports) or add scrolling.

Back to strider :

[AMSTRAD CPC] Strider - Longplay & Review

ok.
the HUD (score zone) is like... 1/3 of the screen. it was a nice way to fill the screen while having less stuff to animate...

So as a result the actual resolution of the playfied is something like 208x128.
128 vertical with the player's sprites being like 40pix height = 1/3 of the screen.

Each fucking time you just ninjaflipjump in the air, you are in a black screen because the floor goes out of the window.
A bigger screen would mean more tiles and sprites to display, but also it would mean that the CPC don't have to move all this upward then downward at each fucking painfull jump.

[AMSDOS]

I also looked at Fred/Roland on the Ropes, ok the game is old, it has some flicker, but it's a nice example of hardware scrolling. It too is char based, but done well. The flicker comes from redrawing the status panel. Could have been done better with rupture here, but it's ok.

Yes I always felt it spoilt the game a little bit. Roland In Space uses the same kind of thing, which seems to be a bit more polished, though it doesn't have to worry about status bars.

[Axelay]

Then, you can also look at some games that use software scroll, like galivan, and they made a complete mess here. really, it's like they just hit the keyboard until a game appeared.

the display is tiny, I think they double buffer the screen within the same 16k, 2 screens in 16k I think. But then when they do the scroll it's really bad.

I'm going to play devil's advocate here, because Galivan is indeed poor, but is the scrolling and screen size particularly bad?  There are other games that have used two 8k screens before (Midnight Resistance & Astro Marine Corp come to mind) though I think those perhaps dont seem as severely small because of the more traditional screen proportions.  There are also plenty of spectrum ports or CPC software scrolled games that had play areas of a similar or even smaller size to Galivan, but they've distracted from it with a lot of fluff around the edges of the play area.  For example, even David Perry used a 28x16 character play area on Dan Dare 3, and that's even smaller than Galivan.  (but happily, more fun... )


Of course there is also that Galivan surge scrolls in that small window.  A while back I wondered why on earth CPC software scrolling games would be doing that, and after comparing a few games to their spectrum counterparts I found that most appeared to be spectrum ports of games where that spectrum version had used colour in the backgrounds.  So I presume the character stepping is about avoiding colour clash on the backgrounds, and the intermittent scrolling happens because it's too fast otherwise.  So it appears that for software scolling games on the CPC use of that scrolling technique is just down to being quick ports of z80 code designed to work around a problem on a different platform.


However I found New Zealand Story on the spectrum has a surge scroll but no colour to worry about that I could see.  I guess a character is also a byte wide on the spectrum, so that kind of scroll may also just be about memory or CPU issues to avoid scrolling by partial bytes.


Galivan on the spectrum also uses a tall narrow screen.  I noticed the arcade uses a screen of similar dimensions, so whether they used a tall narrow screen to mimic the arcade, or whether it just made some slow code run faster, I could only speculate.  But it does seem to me that there is 'nothing unusual' about the lack of effort or the problems with the CPC version of Galivan, compared to many other spectrum ports.

Strider on the amstrad (and speccy... as it is speccy port) also has a few scrollings issues in my opinion.
This is mostly due to the fact the screen is quite small, while the player's sprites is proportionnally big in this (almost arcade sized, somewhat).

As a result, each time you jump the vertical scrolling is activated (ouch) so you stay inside the playfield (unless at an edge of the level map)...

Had the screen dimensioned bigger, the scrolling would be far less demanded and the game smoother.

That's the problem with both speccy port and poorly designed games on CPC.

This is true enough from a design perspective, but from an implementation perspective, the scrolling is done in software.  A bigger play area would also mean a lower frame rate.  That is also a problem, a lower frame rate means less responsive controls, a less fun game.

[Xifos]

Hi,

May i ask a surely silly question ?

Somebody wrote, on a stupid french forum, that using R3 trick for hardware scrolling could damage CTM monitors !
No doubt it came from some cpc hater...

But what is the truth about this CRTC register 3 trick ?
I played a lot ghost'n goblins when i was a kid, and my monitor never exploded (i could be wrong but ghost'n goblins uses R3)...

[ivarf]

We have many examples of bad CPC scrolling with small screens. To me it seems that the fullscreen flickscreen method in many cases makes for a better game. If only all games could have had the scrolling of Star Sabre... Would it be possible to do a remake of the R-type remake as smooth as Star Sabre?

What is limiting the use of Star Sabre scrolling in more games?

[arnoldemu]

But what is the truth about this CRTC register 3 trick ?
I played a lot ghost'n goblins when i was a kid, and my monitor never exploded (i could be wrong but ghost'n goblins uses R3)...

Register 3 trick changes hsync width sent to monitor.
hsync is used to tell the monitor the timing of the lines.
the value is changed each frame, only by a small value, but perhaps it is enough to stress the electronics inside the monitor.

I never knew of a game that broke a monitor in this way.

[arnoldemu]

We have many examples of bad CPC scrolling with small screens. To me it seems that the fullscreen flickscreen method in many cases makes for a better game. If only all games could have had the scrolling of Star Sabre... Would it be possible to do a remake of the R-type remake as smooth as Star Sabre?

What is limiting the use of Star Sabre scrolling in more games?

hardware scrolling uses all of a 16k page. in addition, it would scroll a status panel, so you must re-draw the status panel, or you must use "splitting" to split the screen into scrolling and not scrolling.

another problem is that the r3 trick can cause a panel to move left/right, and you must add extra lines between the scrolling and the panel to avoid this.

so the technique often means more ram is used, and often you need to have good timing to make a stable scroll and panel.

it is more complex thing to make than a software scroll.

I still believe other games would be better with this type of scroll

[Bryce]

Hi,

May i ask a surely silly question ?

Somebody wrote, on a stupid french forum, that using R3 trick for hardware scrolling could damage CTM monitors !
No doubt it came from some cpc hater...

But what is the truth about this CRTC register 3 trick ?
I played a lot ghost'n goblins when i was a kid, and my monitor never exploded (i could be wrong but ghost'n goblins uses R3)...

Frequently changing the value of R3 would have absolutely no negative effects on a CTM Monitor. The circuitry is entirely analogue and is permanently changing. All you are doing is switching a transistor at a different rate, but all well within the tolerances of the part. The transistor doesn't care how regular the frequency is as long as it doesn't go above a certain frequency and the CPC definitely can't switch it faster than the transistor is able to.

Bryce. 

[sigh]

it is more complex thing to make than a software scroll.

I had no idea that hardware scrolling would be more complicated. Isn't hardware scrolling/sprites originally intended to make things easier? Would it still be difficult to achieve on a plus machine?

When looking at commando on the cpc, are there any other games using the same technique?

[arnoldemu]

I had no idea that hardware scrolling would be more complicated. Isn't hardware scrolling/sprites originally intended to make things easier? Would it still be difficult to achieve on a plus machine?

When looking at commando on the cpc, are there any other games using the same technique?

I would say correct use of hardware scrolling takes more thought.

it is easier on the plus because you can use the hardware sprites.

I hope to put some of these problems right with some more example code.

[Axelay]

hardware scrolling uses all of a 16k page. in addition, it would scroll a status panel, so you must re-draw the status panel, or you must use "splitting" to split the screen into scrolling and not scrolling.

If you are working to 64K though, you can use R9 to reduce that 16k down to something comparable to a commercial era game, without the need to fill space with graphic borders and large panels, so memory 'need not' be the issue.

I would say correct use of hardware scrolling takes more thought.

I think there were a lot of software scrolling games that could have used more thought too. 

[sigh]

Not too derail the thread, but what are the benefits of hardware scrolling in games compared to software scrolling? Are there any games that have/can/used both methods at the same time? Is hardware scrolling in games better for certain modes(mode 0, mode 1)?

[AMSDOS]

I love the Hardware Scrolling in Wonderboy, I think it works well in with the game, having said all that I'm sure someone will probably dislike it. 

[db6128]

Not too derail the thread, but what are the benefits of hardware scrolling in games compared to software scrolling?

It's not something I know much about either, but definitely the chief benefit is that you have only to change the base address of the screen and maybe another register or two in the CRTC, instead of having to physically write all the affected bytes into their new places in software.

[Puresox]

Wonderboy!! .


may have good scrolling ,  but abysmal version.

[Gryzor]

Aw, come on, I loved that little boy running around in its nappies throwing stuff

[Bryce]

Aw, come on, I loved that little boy running around in its nappies throwing stuff

Only someone who hasn't got kids could say that!

Bryce.

[Gryzor]

Quote from: Gryzor on 14 December 2012, 12:08:11Aw, come on, I loved that little boy running around in its nappies throwing stuff
Only someone who hasn't got kids could say that!

Bryce.

Jealous, ehhhh?

[fano]

It's not something I know much about either, but definitely the chief benefit is that you have only to change the base address of the screen and maybe another register or two in the CRTC, instead of having to physically write all the affected bytes into their new places in software.

Yep, this the main benefit.Doing hardware scrolling is not complicated in itself but its major drawback is address wrapping.The physical end of the screen can be everywhere on the screen (every 2 bytes).This is not really a problem for background as long you draw character sized tiles but  it is more problematic for sprites in terms of code speed.
Btw, i am working on a such problem, how do you , game programmers (Axelay, Arnoldemu and so on) do you handle this problem ?

[Axelay]

Yep, this the main benefit.Doing hardware scrolling is not complicated in itself but its major drawback is address wrapping.The physical end of the screen can be everywhere on the screen (every 2 bytes).This is not really a problem for background as long you draw character sized tiles but  it is more problematic for sprites in terms of code speed.
Btw, i am working on a such problem, how do you , game programmers (Axelay, Arnoldemu and so on) do you handle this problem ?

I've only had to deal with it once so far, so I dont know if it was the best way, but my approach was to handle sprites in sets of two pixel lines at a time, because that way, I could always do my increments from the "easy" lines (&c7ff, &d7ff, &e7ff and &f7ff) as correcting those is a simple single reset that covers all of them, whereas trying to correct the address after an increment from the lines below those (&cfff, &dfff, &efff, &ffff) is (or seemed) much more complex because more bits needed correcting, and those bits are different for each of those lines.

[Xifos]

Is it not better to work with 64 bytes width screen ?
For address wrap ?

[fano]

I'd say only if you use vertical scrolling, the problem remains for horizontal scrolling.

I've only had to deal with it once so far, so I dont know if it was the best way, but my approach was to handle sprites in sets of two pixel lines at a time, because that way, I could always do my increments from the "easy" lines (&c7ff, &d7ff, &e7ff and &f7ff) as correcting those is a simple single reset that covers all of them, whereas trying to correct the address after an increment from the lines below those (&cfff, &dfff, &efff, &ffff) is (or seemed) much more complex because more bits needed correcting, and those bits are different for each of those lines.

I see, interesting idea , i'd never think processing that way.Actually, i am thinking to try to avoid this wrapping.The idea is to have two lines,vertical and horizontal, to divide the screen space in 4 following the memory wrapping.If a sprite crosses theses lines, just use them to split the sprite in 2 or 4 parts.This way eliminates needs of wrapping control and allows to use more classical optimisations.I just hope that will balance the cost involved by the splitting method.