CPCWiki forum

I want to start a discussion on scrolling in Amstrad games.

This is more directed to the use of hardware scrolling, but software scrolling examples are also welcome.

So I've seen a number of different approaches used on the Amstrad with scrolling.

1. player remains in the same position ("scroll position" for want of a better description) on the screen at the whole time, except perhaps at the edges of the map where they are allowed to walk up to the screen edge. when they return to the "scroll position", the screen starts to scroll again and the player remains static.

Examples:

Robocop 2 (software scrolling)

2. Player moves near the edge, or to the edge of the screen. The whole screen scrolls, so that they are now on the opposite edge. e.g. player moves towards right edge, whole screen scrolls and they are now on the left edge.

Examples: Ghouls and Ghosts. Stryker and the Crypts of Trojan. Prehistorik 2.

3. player moves to left/right of their "scroll position", they remain here, and the screen scrolls. When they stop they return to their "scroll position".


I am going to put my head on the line, and say that, although "Prehistorik 2" is a very good technical achievement, it has great graphics and great sound, it's scrolling is not that great and is an example of 2. Why is it bad? Jump up and then down again. As you jump up, the screen scrolls so you are now on the bottom, as you fall it scrolls again, and you are back on the top. it can be really "jarring". If it had a scroll like (1) it would be so much smoother and nicer.

So what I am hoping is that others would help me here..

Are there other "types" of scroll you have seen, please give me examples of games that fit into each type so I can document it in the wiki and perhaps we may be able to work out *why* they chose that method.

if you want a really bad example look at "Galivan". The screen area is tiny, and the scroll is really really horrible. ;)

I can think of why some scrolls may be done this way and it's down to when the screen wraps in memory:
where the byte to the right of c7ff is c000 at the point the scroll wraps, it's not an easy calculation no more, not a simple inc, but more leading to slower drawing of sprites if you don't manage it in a clever way.

I know games can avoid this. Vertical scrollers can do this by having the problem appear on the left of the screen when it happens. They can do this by keeping the width so that 1024/width is a whole/integer number.

But on some games that scroll horizontally, the sprites continue to move during the scroll, so in this case they could cross this bad position and it can occur.

On some I noticed that the sprites stop during scroll, on others it was more difficult to tell.

The eventual aim of this discussion is to have a good list of each of the types of scrolling, examples of each, and perhaps a reason why they did it. I hope to provide some examples if I have time to write them, at this time I have other commitments.

Thank you for reading.

I think Ghost and Goblins is a 2.


Games like Wizard Willy, Turbo The Tortoise, Yogi's Great Escape, Scooby & Scrappy Doo, Wonderboy, I think are a 3 cause they all have a character working from Left to Right through Levels. I'm unsure if Mission Jupiter would be a 3 cause the scrolling is forced, though the player can move Left/Right Up & Down, guess it's kind of like Shockway Rider when you step onto the Platforms and the character in that game can move around the screen.


Were you going to talk about games like Ikari Warriors, 1942, 1943, Sonic Boom, Light Force? The scrolling (if it can be called that) in them games is pretty much the same I guess apart from Ikari Warriors which doesn't Force the Scroll.

Quote from: CP/M User on 10:32, 13 November 12
I think Ghost and Goblins is a 2.


Games like Wizard Willy, Turbo The Tortoise, Yogi's Great Escape, Scooby & Scrappy Doo, Wonderboy, I think are a 3 cause they all have a character working from Left to Right through Levels. I'm unsure if Mission Jupiter would be a 3 cause the scrolling is forced, though the player can move Left/Right Up & Down, guess it's kind of like Shockway Rider when you step onto the Platforms and the character in that game can move around the screen.


Were you going to talk about games like Ikari Warriors, 1942, 1943, Sonic Boom, Light Force? The scrolling (if it can be called that) in them games is pretty much the same I guess apart from Ikari Warriors which doesn't Force the Scroll.

Yes I am talking of all.

I will add 4. which is games where the scrolling is continuous. the player moves freely around the screen but the scroll is continuous.

Examples here:

Edge Grinder, Axys


Here we have examples of games with great scrolling. So why didn't all have great scrolling?

Quote from: arnoldemu on 10:43, 13 November 12Here we have examples of games with great scrolling. So why didn't all have great scrolling?

I'm unsure I can answer a question like that, a programmer during the CPCs Commercial days might say it was time constraints where deadlines had to be met.  ??? 


The Discussion about New Zealand Story in the other thread could simply be an Emulator Vs. Real Machine there where the Emulator isn't quite simulating the right effect or something. I've played Rainbow Islands on both Real Machine & Emulator and the Scrolling in that game isn't smooth either, though I only think their like that cause there's a time limit factor involved in both of those games and making it appear quicker kind of gives it an bit of a kick, otherwise you'd get water or some nasty creature out to get you. "Edd the Duck" by comparison to "Rainbow Islands" has smoother scrolling, though has no limited time factor, merely a game full of nasties you have to avoid while collecting stars.

Quote from: CP/M User on 11:28, 13 November 12

I'm unsure I can answer a question like that, a programmer during the CPCs Commercial days might say it was time constraints where deadlines had to be met.  ??? 


The Discussion about New Zealand Story in the other thread could simply be an Emulator Vs. Real Machine there where the Emulator isn't quite simulating the right effect or something. I've played Rainbow Islands on both Real Machine & Emulator and the Scrolling in that game isn't smooth either, though I only think their like that cause there's a time limit factor involved in both of those games and making it appear quicker kind of gives it an bit of a kick, otherwise you'd get water or some nasty creature out to get you. "Edd the Duck" by comparison to "Rainbow Islands" has smoother scrolling, though has no limited time factor, merely a game full of nasties you have to avoid while collecting stars.

It's ok I didn't expect an answer from you :)

I was just wondering.

Perhaps I need to try and make each type of scroll and then I can answer it.

What happened to the post concerning the "cheap Z80 machine with a "joyous" rainbow on it and awful graphics on its monitor that used to have an ununderstandable success in UK thx to his price proportional to its capabilities in graphics" ?


I clicked on "like this post" and the post disappeared...
Is this some inquisition extermination team intervention or is it me, who put into oblivion what i "Like" on this forum ? :laugh:




er... I should really do a long post concerning scrollings in games here... but cxan't find proper motivation, lot of work these days and I'm tired... next time.

Quote from: arnoldemu on 18:53, 12 November 12
I want to start a discussion on scrolling in Amstrad games.

This is more directed to the use of hardware scrolling, but software scrolling examples are also welcome.

It seems like for starters then we're basically looking at 'push scrolling', or scrolling under the control of the player?  My thoughts on this are that really, there's only two types in hardware on the CPC, those that are 'true' push scrolling that keep pace with the player, as you've described as type 1, and those that are some sort of compromise, which I think of as 'surge scrolling' (after first reading that in a magazine years ago), but seems to have as many descriptions as people who've described it.  Which would be your type 2.

If I have understood what you mean for type 3, to me that is just a variation of type 1 where the scrolling has a delayed reaction to the players movement, but sort of 'rubber bands' to the player?  Or it has a delayed reaction to the player but generally keeps up with them?  I cant think of anything on the CPC that does that though.

I think another variation on type 1 would be one where the player is kept within a box in the centre of the screen.  The player gets to the edge of that box and it push scrolls at the pace of the player, but doesnt make any effort to centre to player when they stop moving.  I havent thought of a platform game that does that, but Bio Spheres does it in the vertical direction, although it seems like straight type 1 horizontally.

And speaking of type 1, some original CPC examples I can think of would be 5th Axis and Action Force.

For type 2, my belief is this probably comes about as a result of the course scroll step being too fast for a lot of platform games (and even R3 for some), so they've implemented the scrolling in brief 'surges' of scrolling that move faster than the player.  I was thinking about this a little while back, and it seemed to me that the things to consider were how close to the edge of the screen is the player allowed, how far does the screen scroll when they do, and does the action freeze when it's scrolling.

Games like Ghouls & Ghosts or Prehistorik 2 seem to more or less have a box in the centre of the screen that's a 3rd or so of the whole width/height, and they scroll by almost as much as a that box width, which as you've mentioned has a jarring effect if the player suddenly changes direction after triggering a scroll.  Though I'd disagree that Prehistorik 2 would have been smoother as a type 1.  (semantics perhaps?)  It's scrolling at 50fps right now, but as far as I can tell, it updates the sprites at 12.5fps, including the player.  A lower frame rate scroll that updated only when the player does would not look smoother to me, even if the scrolling was more intuitive.  It only uses one screen so I'm assuming the sprites update at that rate because it's using the border refresh to avoid flicker, and if that is the case, I'd be surprised if the player would be able to be updated at the 50fps of the scroll as it is currently.

Stryker is an interesting one.  It scrolls the whole screen when the player gets to the edge, letting the player continue, but enemies freeze, and no new enemies spawn, while the scrolling is active.  The player continues to fall if they fall off the bottom of the screen, but if they leave a screen vertically via a ladder, then the player also freezes!  I personally thought they should have stuck with flip screen for this.  Being able to walk half way through a screen without enemies & items spawning just seems strange.

Another that scrolls the whole screen is Titus the Fox.  The action freezes while it scrolls, its almost a flip screen game with a tranistion effect.

Final variation I can think of right now is Monty Python.  That has the game at 17fps I think, but freezes and scrolls 1/4 of the screen width at 50fps.  The screen size is reduced, the level sections are short and it only scrolls horizontally, not vertically (as far as I've ever got) so it looks like it avoids the screen address reset.


Bloody hell, what a nasty wall of text.  :D

MacDeath would be proud of that post :D

Bryce.

Quote from: Axelay on 15:49, 13 November 12
If I have understood what you mean for type 3, to me that is just a variation of type 1 where the scrolling has a delayed reaction to the players movement, but sort of 'rubber bands' to the player?  Or it has a delayed reaction to the player but generally keeps up with them?  I cant think of anything on the CPC that does that though.

Type 3 is just like in Edge Grinder.

Scroll moves always - it's on rails. Player is either fixed, or moves around freely.

BTW, Thankyou for your post, the games and your assessment. I really appreciate it.

It is interesting how people have chosen to implement the scrolling. Yes, it could be down to the speed of the scroll. it is something i'll investigate.

to me, it's not always about it being super smooth here, I am more "why aren't all the scrolls like 1"?

a scroll which is triggered by moving to the side and it scrolls the whole screen, to me, suits a game where you can't go backwards. movement is in one direction, here then you don't get the problem of it scrolling it all back again if you reverse direction.

 

Quote from: MacDeath on 15:29, 13 November 12
What happened to the post concerning the "cheap Z80 machine with a "joyous" rainbow on it and awful graphics on its monitor that used to have an ununderstandable success in UK thx to his price proportional to its capabilities in graphics" ?


I clicked on "like this post" and the post disappeared...
Is this some inquisition extermination team intervention or is it me, who put into oblivion what i "Like" on this forum ? :laugh:

It was my post. I made some small changes and got "edited" at the bottom. I lost the text when copying it for a new post. My error, not the system or a moderator. I had to leave the computer and had no time to write it again. Thanks for the like :)

Unsure it's relevant, though kinda related so it's in the spoiier.

Quote from: CP/M User on 08:55, 14 November 12
Unsure it's relevant, though kinda related so it's in the spoiier.

some games do that by moving stars giving the appearance of scrolling.

I think others may move things in the background, but not the entire screen to simulate?

What about 2 layer scrolling, where the background scrolls at two different speeds to give a 3D depth effect? What catagory would that come under?

Bryce.

Quote from: Bryce on 10:45, 14 November 12
What about 2 layer scrolling, where the background scrolls at two different speeds to give a 3D depth effect? What catagory would that come under?

Bryce.

I would call it parallax scrolling.

it would be another category (4).

A few games do this all are software scrolling:

Wizard Willy
Teenage Mutant Hero Turtles.

Is hardware scrolling utilized in racing games? Which category would that fall into?

Quote from: arnoldemu on 18:47, 13 November 12
BTW, Thankyou for your post, the games and your assessment. I really appreciate it.

You're welcome. 

Quote from: arnoldemu on 18:47, 13 November 12
It is interesting how people have chosen to implement the scrolling. Yes, it could be down to the speed of the scroll. it is something i'll investigate.

to me, it's not always about it being super smooth here, I am more "why aren't all the scrolls like 1"?

Thinking about the why some more, a number of games with hardware scrolls only used a single screen with no buffer, so another possible reason might be just to avoid doing too much at once, by not having to update sprites, the background tiles and even the score lines if no screen split is employed, all at once on the visible screen.  To avoid or minimize the sort of visual 'glitching' games like Roland on the Ropes displayed.  Maybe?  Or perhaps it was just simpler to do?  :)

But I'm inclined to think some of it might be down to the later prevalence of spectrum ports meaning that using hardware scrolling never really seemed to get past the 'experimental' stage.

Quote from: CP/M User on 08:55, 14 November 12
Unsure it's relevant, though kinda related so it's in the spoiier.

I think it's a fair bet that many software scrolling game you see with large amounts of blank background (or just stars) are probably only scrolling the required strips of background or moving 'objects' around rather than scrolling as such.  Commando for example, makes it seem pretty clear it has more to do the more scenery that's present by the way the frame rate takes such a hit when encountering the large runway.  Another is Nemesis, which dramatically slows down when it introduces its' cavern walls during a level.

Quote from: sigh on 15:20, 14 November 12
Is hardware scrolling utilized in racing games? Which category would that fall into?

Do you mean top down or side on 2D racing games?  Or are you thinking of the parallax backgrounds in 3D games?

Quote from: Axelay on 12:33, 15 November 12
Do you mean top down or side on 2D racing games?  Or are you thinking of the parallax backgrounds in 3D games?

The racing games such as Outrun, Chase HQ etc. Supercycle has amazing smoothness with the 3d scroll effect. I was wondering if this is hardware base?

There was a simple little game which was a Type-In in Amstrad Action which I think had some Hardware Scrolling in it (using the "OUT" command?). The game I think was called "Apple Days?" or "Apple Dayze?" and the idea was Apples would randomibly fall out of the tree and you'd have to catch them in your basket. The scrolling came into play with part of the screen being obscured and as you moved your basket, the screen would move - left or right and you'd have to reach the apple in time. Was a nice game (originally played it in my 464), though I don't think it worked when I got a 6128.  :(  Haven't tried it on the Emulators.

Quote from: sigh on 18:53, 15 November 12
The racing games such as Outrun, Chase HQ etc. Supercycle has amazing smoothness with the 3d scroll effect. I was wondering if this is hardware base?

all of the racing games are done with software.

Ok let's go.

There are many types of scrolling, and also many ways to generate it I guess.

=Simple Horizontal
=Simple Vertical
=Simple Diagonal (when simultaneous H+V only).
=multi directionnal scrolling : features both horizontal and vertical, sometimes enable a proper diagonal, sometimes it alternate between horizontal and vertical.

(those two are not really relevant but good to precise the difference)
=Forward scrolling : A scrolling may only goes to one direction so you can't "go back" once you advanced to a point, as often used for railroad shooters, but not only, Kharnov doesn't allow to go back per example.
=Forward and Backward scrolling : you can go back to previous screen (not possible on most railroaded shooters)

=Automatic scrolling : railroad shooters such as R-Type or Army moves 1st part.
=player/event activated scrollings : you activate the scrolling because you move the player character.

=continuous scrolling :  the player character is always at the center of the screen unless you reach the border of the level map or for some special events such as bosses.
=Flip screen : there is no scrolling, when you reach the border a new screen is generated at once. As in Gryzor.
=Flip screen scrolling : when you reach the border (or a part of the screen activating the scrolling), a scrolling is activated, scrolling the sprites too, for a whole screen or just a limited (half) distance.

=Pixel scrolling : a pixel scrolling. hard to achieve horizontally for the CPC.
=Byte scrolling : implement 1byte (=8bits), which is like 2 Mode0 pixels, 4 mode1 pixels or 8 (a whole character) mode2 pixels
=Character scrolling : implement a whole "character" at each incrementation of the scrolling.

=Paralax : multiple plans running at different scrolling rates.

=Smooth scrolling : smooth scrolling is both a pixel scrolling and a non flip-screen scrolling, often continuous scrolling too.
usually seen on C64 and consoles, rarely on CPC.
It is to notice that the Player character/sprite may activate it not just when it moves to one direction, but use a flipscreen method : the scrolling may activates only when you try to move past a point like 1/3 or 1/4 from a border (or whatever fraction). continuous means most of time that the activation point is at the 1/2 point/zone of the screen

are their any other ways ?

Examples :

=AMC : character-based multi-directionnal paralax player activated continuous scrolling.
A good example about the qualities of a square-character based engine

=Ghost and goblin : multi-directional 1byte (is it?) player activated flipscreen scrolling.

The scrolling seems to activate when you reach a point at approximately 1/3 screen of the border (for the horizontal one) and brings you back to the 1/3 point from the opposite border (unless you move while it scrolls, which brings you at the middle of the screen once the flip screen scrolling ends. It seems the game can't do real diagonal scrolling.

=Pacmania : multidirectionnal "Cavalier perspective"  player activated "smooth?" continuous scrolling.

The Cavalier perspective means the vertical scrolling is actually a diagonal scrolling.
PacMan is always at the center of the playfield.



I've heard the hardware horizontal scrolling from the CPC is 1byte only... so in Mode0 to make a smooth 1pixel scrolling you need to double buffer it and have the tileset doubled, so each tiles would feature a version with the "normal" tile and athe same tile with 1pixel shift.

To have a 1 pixel horizontal scrolling in mode1 you may need to have 4 version of the tiles I guess, and so on.

Vertical scrolling is said to be easier to generate on the Amstrad CPC... it can be done to the pixel more easily.



RaceGames (like Wec le Man) have some strange way to mix the scrollings.


Mostly the only part really scrolling is the far background (the mountains on the horizon line) who scroll horizontally (and a bit vertically sometimes.
For the road and other elements, those are mostly sprites I guess.
I the Race game features some relief effect, I guess it is quite subtle.
the "vertical" scrolling from the road could be done via Raster affects I guess.

Yaaaeehh! MacDeath is back! It wasn't the same without your endlessly long posts. Although you stayed on-topic for the entire post?? Maybe it takes a few days before you are back to your normal self :)

Bryce.

Quote from: Bryce on 14:00, 16 November 12
Yaaaeehh! MacDeath is back! It wasn't the same without your endlessly long posts. Although you stayed on-topic for the entire post?? Maybe it takes a few days before you are back to your normal self :)

Bryce.

it's exactly what I was after...

concerning comparisons, when I compare the same game on the c64, it often has much better scrolling. Yes it has pixel by pixel scroll in hardware, but the scrolling often has more care about it, somebody has bothered to make it right. When we look at the cpc, in some games, the scrolling is not good. Like they tried and gave up. It is often worse in hardware scrolling games, because of the limits that are imposed, but still I am sure, that they could have done something better.

The issues in hardware scrolling are:
1. speed of scroll - always a problem horizontally, can be made perfect in vertical.

2. the "problem" zone, where we can't do a simple increment to get the next byte to the right. e.g. c000+1->c000, c7ff+1->c800 but this is not the byte to the right when hardware scrolling, it is c000 because of the wrap around.

But then when you look at what they did in games that use hardware scrolling, you can see there are different ways to overcome the problems and to work with it. Some are done great, some are a mess.

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.

Compare: Speccy port vs well programmed game
Compare: bad lazy scrolling vs nice programmed scrolling.

it's like a speccy port rant, but for amstrad scrolling.

What do I want to get out of this eventually?

Some examples of what is good, how to make it work correctly, various methods that can be used.
To try and correct some wrongs ;)

That's because I'm awaiting a call for a job's answer... i'm a bit stressed. ;D

Also other aspects :

=Hardware Scrolling
=Software Scrolling

This differentiation is mostly depending to the machine and the way the coder do his program I guess.
Sometimes it may be better to use a software scrolling because no hardware scrolling is available, or because it enables different stuff.

Hardware scrollings are limited to what is implemented in the Hardware.
Software scrollings are limited to what the CPU can handle.


I think a main issue with the CPC is that they too often missed the point...

Ghost and goblin is a kool exemple of what the CPC could do quite well.

On the other Hand, Green Beret is a bad example...

The flip screen scrolling activate when you reach the point at 1/4 screen (approximately) from the border and brings you to the point at 1/4 of the opposite border.
But the games actually freeze during the scrolling sequence and the scrolling is slowpoke.
this completely screw the game in my opinion (no THAT a bad game though)

Ghost N Ghost on the other hand enables the player to continue to play (move, shoot and kill zombies and daemons) while the scrollings is activated.

Flip screen scrolling was often used on PC games and Atari ST. I is not a bad technique, just it gets bitched by Commodorks and consolefags because "muh hardware smooth scrolling".

Titus the fox is a good example of the way those 2 sort of scrollings can be used on different systems.

PC Ms-Dos : flip screen scrolling
Titus The Fox (http://www.youtube.com/watch?v=f_VPhDnRwdk#)

Amiga : smoother continuous (almost) scrolling
Amiga Longplay [470] Titus The Fox: To Marrakech And Back (http://www.youtube.com/watch?v=GFSiXdkBfvg#)


=464 Vs 6128 :
To benefit from 128k is good in that you can do much more tricks to buffer properly.


Also it is known that to have a screen sized with an horizontal 128pix (Mode0) or 256pix (mode1) can also help a lot.


I always wondered if it could be possible to aim at an overscaned 256pix(mode0) or 512 (mode1) horizontal sized screen.
Of course a large part of the screen wouldn't be actually displayed, but we have the 2x 256 thing.
I guess this would clearly use like 32K of VRAM anyway and slows down many things, but this would theoretically leave a good chunk of buffer and it could be possible to have some stuff outside of the view actually managed.





displayed "overscan" is something like "lets talk in Mode1) 384x272...(101118 pixels)
Displayed fullscreen is said to be like 24K (but still 2x16K banks are used)


A 256x200 screen is 51200 pixels
a 320x200 screen is 64000pixels (=16K RAM)


512x200 = 102400 pixels
512x192 = 98304 pixels ("huge" gain just to remove 1 character line)


512x200 wouldn't be that bigger than a "normal" overscan (like... 26K ?), but perhaps having this 2x256 horizontal could be of some help ?
Or is it simply impossible ?




Still I can't believe no vertical shooter was ever made using a "256x256" sized screen (Vertical fullscreen).

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

Bryce.

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

yeay me too, but you are getting out of topic my friend... :laugh:

bac kto topic then, Another Example.

Rastan Saga.
Looks like it is a character based engine, isn't it ?
Sprites are big and seem to be masked.
But the game is quite sluggish.

Where did it go wrong then ?
Are sprites too big ? or is it the multidirectionnal Player centered continuous scrolling ? or the screen sized in "320x200" ?

Sad because the graphics are not bad.



Also it is to notice that if Gryzor could benefit from a scrolling comparable to Ghost and Goblin, the C64 community (and speccies as well) would be butthurt to the extreme... but hey, 64K only.


Satan is a good exemple about how good a multidirectionnal scrolling can be well handled on CPC.
Thank you España !
Also graphics are excellent, but as usual the screen is somewhat small.

Quote from: Bryce on 14:30, 16 November 12
Then good luck with the Job. I hope you get it.

Bryce.

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

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.

It could be interesting to put a link to this past topic :
character-based tile engine with parallax scrolling (http://www.cpcwiki.eu/forum/programming/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 (http://www.youtube.com/watch?v=B3twY7PaYa0#)

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.

Quote from: arnoldemu on 15:06, 16 November 12I 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.

Quote from: arnoldemu on 14:18, 16 November 12

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. ;)

Quote from: MacDeath on 15:44, 16 November 12
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.

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)...

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?

Quote from: Xifos on 18:45, 18 November 12
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.

Quote from: ivarf on 14:05, 03 December 12
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 ;)

Quote from: Xifos on 18:45, 18 November 12
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. 

Quote from: arnoldemu on 14:25, 03 December 12
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?

Quote from: sigh on 21:00, 03 December 12
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.

Quote from: arnoldemu on 14:25, 03 December 12
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.

Quote from: arnoldemu on 11:06, 04 December 12
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.  ;)

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)?

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. ;D

Quote from: sigh on 11:41, 05 December 12Not 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.

Wonderboy!! :laugh: .


may have good scrolling ,  but abysmal version.

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

Quote from: Gryzor on 11:08, 14 December 12
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! :D

Bryce.

Quote from: BryceQuote 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? :D

Quote from: db6128 on 10:32, 06 December 12
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 ?

Quote from: fano on 10:26, 20 December 12
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.

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

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

Quote from: Axelay on 14:52, 20 December 12I'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.