How to use hardware scrolling in games?

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

How to use hardware scrolling in games?

Postby Zamuel_a » Thu Jan 03, 2008 4:09 am

I have been thinking of making a platform game like Turrican and had liked to use the hardware scroller on the STE, but I don't really know how to use it in a game like that. The game are tilebased and if I use the hardware scroller I have to creat a large screen and scroll around. That will take alot of memory. Lets say the playfield is something like 10*10 screens big, then that bitmap will take 3.2Mb. But how do I use the hardware scroller for a normal tile based engine? So I only have a 320x200 screen? I can use the fine scroller for 0-15 pixels but then I need to copy the entire screen 16 pixels to be able to use the same memory, but that seems like a slowdown.

RA_pdx
Captain Atari
Captain Atari
Posts: 215
Joined: Sun Feb 02, 2003 12:01 pm
Location: Nuernberg/GERMANY

Postby RA_pdx » Thu Jan 03, 2008 7:56 am

You need the following virtual screen resolutions:

Vertical scrolling:
width 320; height 2*( 200+speed ); speed=max. scroll speed per VBL

Horizontal scrolling ( scroll speed max. = 8 ):
width: 2*( 320+8 ); height 200

Scrolling in all directions:
width 2*( 320+8 ); height 2*( 200+speed )

The "trick" is to plot the new tiles twice. For example if you use horizontal scrolling you draw your new tile at x positions 0 and 8+320 and you display the screen at x position 8. If your scroll speed is 8 then you will do the following in the next vbl - draw the new tile at x positions 8 and 16+320 and you display the screen at x position 16. That means you increase every value by the scroll speed. Do this every VBL until you reach display x position 8+320 and then you have to start again with the first step. So you get a endless and very fast scrolling...

I hope it have described it clear enough - if not then don´t hesitate to ask again. :wink:
Last edited by RA_pdx on Thu Jan 03, 2008 2:16 pm, edited 1 time in total.

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby tobe » Thu Jan 03, 2008 12:48 pm

You can use a screen like:
- width = 320 + block width
- height = 200 + block height

make block with and height large enough so you can draw the next tile set while scrolling on the current one, by splitting the draw operation on multiple frames, instead of drawing the new tile set at once. This should give a stable frame rate.

The drawback is, you must adjust your block size and scroll speed to be sure to be able to draw the next tile set in time...

Memory is a big problem when using hardscroll, because you need to manage 2 buffers in memory (back and front). In the game Roger, i finally decided to use the blitter to scroll the screen, using only one very large background and two normal screen buffers. It take ~1 frame to update the screen buffer from the large background. On the other side, you only need to manage one buffer for moving sprites, and if a sprite is not moving, you don't need to redraw it.
You can use the hardscroll to add a border around your screens so you don't need to compute clipping.
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Postby Zamuel_a » Fri Jan 04, 2008 6:27 am

Ok I think I understand better now, I have to give it a try someday. one interesting thing I came up with then it comes to a tilebased game is that lets say its using 16*16 tiles, then you can update the palette every 16 lines so you can get alot more colors on screen. Some colors have to be the same ofcourse, like sprites and stuff that move over the entire screen, but perhaps you can have 4-5 unique colors per tile row.

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Postby Zamuel_a » Sun Jan 06, 2008 6:24 am

So I understand that if I scroll the screen to left then I draw the new tiles on the right side of the screen and a copiy of them at the left side so then I have scrolled an entire screen to the left I have a duplicate of that screen at the beginning of the screen memory so I reset the adress and start all over. That means that if I use 16*16 tiles I have to first draw them on the right side of the screen and at the same time on the left. What is the fastes way to make the copy? To draw the copy at the same time I draw each tile or draw all tiles in that row and then use the blitter to copy the entire 16*200 block to the left side of the screen?
If I then add sprites to the screeen I guess I have to first save the screen I will overwrite with the sprite so I can restore it later and I have to do all the drawings in the borders or I would get flicker. It seems like its hard to do double buffering with hardware scrolling?

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby tobe » Fri Jan 11, 2008 11:55 am

blitter is easy and fast for copying blocks.
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Sun Feb 10, 2008 3:07 pm

Ok, I have managed to make it work with horisontal and vertical scrolling by drawing the new tiles twice so I can jump back in memory to a exakt copy so it gets continues. That works, but I can't make it work with a all direction scroller and I can't see how to make it work eather. In a horizontal one I start att screen 1 and go on until I get to the next screen and while I have been scrolling I have also redrawn the screen so I can jump back, but lets say I go to screen 2 and then go down one screen. Now I redraw all tiles then I go down so that works, but then I get to the lower screen and start to scroll horizontally again I get in trouble because now then I jump back in memory I will go to a screen that I never draw in the first place, since I never was there before. How do I solve that problem?
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Sun Feb 10, 2008 8:15 pm

I use a virtual screen that is 2 screens x 2 but with an extra 16 pixels on each, e.g. 672 x 432. You can have any height you want but for the hardware scrolling to work properly it needs to based on a 320 pixel wide play area. The pic below should illustrate roughly what I do, the white rectangle representing the position of the visible screen window. Whilst the pic only shows horizontal scrolling you can see the screen data above and below ready for it to go in any direction. The only parts of the screen that need to be redrawn each VBL are 2 rows and 2 colums that are just outside the visible screen in the bits you are scrolling away from and towards. It works for me anyway and I should have a working demo of it soon.
You do not have the required permissions to view the files attached to this post.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Sun Feb 10, 2008 10:39 pm

Ok, I don't understand really. Let's say you go right on the screen and then down 4-500 pixels or so and then start to go horizontal, then you dont have any data written for that screen at all? I would have to redraw the entire screen then and not only the rows to the left and right of the screen, and thats slow.
I don't understand your pictures correctly, it looks like the top and bottom data outside the white rectangle are inverted. The top data are belove and the bottom are above and so.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Tue Feb 12, 2008 8:34 am

With the above method the only time you have to redraw the whole screen is the start of the level. If you look at the separate "screens" the only data that changes from one to the next is the strip of screen you're moving towards and the strip you're moving away from. If you are moving right you draw new data for the visible screen just off the right edge and new data for the next screen just off the left edge of the screen. Then when the "window" reaches the right hand edge it flips across to the other side into the screen that was built up whilst moving to the right. The half screens above and below work exactly the same way as soon as you start moving up or down. The following little diagram shows the parts of the screen that will be redrawn each VBL when the window is in the centre of the virtual screen:-

_________#____________________#_________
_________#____________________#_________
_________#____________________#_________
########################################
_________#____________________#_________
_________#____________________#_________
_________#____________________#_________
_________#____________________#_________
_________#____________________#_________
_________#____________________#_________
########################################
_________#____________________#_________
_________#____________________#_________
_________#____________________#_________
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Tue Feb 12, 2008 4:28 pm

I managed to get it to work! I was only redrawing the part just outside my visible screen and not the entire row, column, so now I have to redraw 2 656x16 and 2 16x416 (I think) tile rows. It works, but it takes alot of time. Then I measure the time it takes about 70% perhaps then then I have all innerloops (tile drawer) unrolled. How to speed it up? I was thinking about perhaps not update everything every frame because its just every 16 frame it needs to get updated, but then it would depend very much of the scrollspeed, if I once want the scrollspeed to be 16, then I have to redraw every frame, plus doublebuffering might get hard since I cant redraw an entire image at once. Right now I havent used any double buffering at all and it works for just scrolling, but I guess if I want to put out some sprites I would need it, or I have to redraw everything outside the visible part of the VBL, wich might get hard. But I need more processorspeed than the 70 something percent I get.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

RA_pdx
Captain Atari
Captain Atari
Posts: 215
Joined: Sun Feb 02, 2003 12:01 pm
Location: Nuernberg/GERMANY

Re: How to use hardware scrolling in games?

Postby RA_pdx » Tue Feb 12, 2008 4:55 pm

Zamuel_a wrote:I managed to get it to work! I was only redrawing the part just outside my visible screen and not the entire row, column, so now I have to redraw 2 656x16 and 2 16x416 (I think) tile rows. It works, but it takes alot of time. Then I measure the time it takes about 70% perhaps then then I have all innerloops (tile drawer) unrolled. How to speed it up?


For the vertical scrolling just draw a part of the tiles every frame: 656x1
For the horizontal scrolling: make the width of the screen even bigger so you have larger borders: Then you could draw just parts of the column every frame outside the visible screen: for example 8 parts each with 16x52 (if you have still enough memory :wink: )
>> > raZen/Paradox < <<

Atari 1040STE, TOS 2.06, 4MB, MC68010, IDE 8GB SSD, Gigafile

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Tue Feb 12, 2008 6:23 pm

Zamuel_a wrote:I managed to get it to work! I was only redrawing the part just outside my visible screen and not the entire row, column, so now I have to redraw 2 656x16 and 2 16x416 (I think) tile rows. It works, but it takes alot of time. Then I measure the time it takes about 70% perhaps then then I have all innerloops (tile drawer) unrolled. How to speed it up? I was thinking about perhaps not update everything every frame because its just every 16 frame it needs to get updated, but then it would depend very much of the scrollspeed, if I once want the scrollspeed to be 16, then I have to redraw every frame, plus doublebuffering might get hard since I cant redraw an entire image at once. Right now I havent used any double buffering at all and it works for just scrolling, but I guess if I want to put out some sprites I would need it, or I have to redraw everything outside the visible part of the VBL, wich might get hard. But I need more processorspeed than the 70 something percent I get.

I'm not using any double buffering myself and as you say drawing sprites in the non-visible part of the VBL. As you say though that leaves you tight for CPU time. I am limiting the scroll speed to 1 pixel/VBL at present and if you carefully spread the drawing of those tiles over the 16 frames it takes to scroll by 1 column you will find you only need to draw a handfull of blocks each VBL which can be done in just a few scanlines, and screen blocks can be drawn during the visible part of the VBL since they are drawn whilst still outside the window. For my code I treat the start of each VBL as being the moment the last scanline has finished being drawn. That way you have the time from then until the first scanline of the next VBL to restore sprite backgrounds to old co-ord's, save sprite backgrounds from new co-ords and finally draw sprites. Then you can use all the space in the visible part of the VBL for the game logic, collision detection, music etc. If you need to scroll faster then you will of course need to draw more blocks per VBL but since these can be drawn in the visible part of the VBL its not necessarily that big a deal.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Tue Feb 12, 2008 10:54 pm

Ok, that sounds smart. If I don't care about the double buffering, then I can ofcourse divide the drawing on multiple frames. Whats the best way to make sprites? preshifted software once or using the blitter? I guess its dependant on the size of the sprites.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Wed Feb 13, 2008 7:58 am

Zamuel_a wrote:Ok, that sounds smart. If I don't care about the double buffering, then I can ofcourse divide the drawing on multiple frames. Whats the best way to make sprites? preshifted software once or using the blitter? I guess its dependant on the size of the sprites.

It depends mainly on the size but pre-shifting can also be used to provide zero CPU sprite animation. If you look at some of the Turrican sprites on my website you should be able to see what I mean. I plan to preshift anything smaller than about 32 x 32 and use the blitter to shift larger sprites in real-time. Its worth noting that except for very small sprites such as bullets its still worthwhile to pre-shift even if you use the blitter since they can then be drawn in one pass rather than one per bitplane. Bullets and other small sprites will be 100% software though and in fact I have a helper who is gonna try and write some generated sprite code routines for such things :)
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Wed Feb 13, 2008 7:26 pm

For my code I treat the start of each VBL as being the moment the last scanline has finished being drawn


Isn't the VBL started at beginning of the new screen? So you have a number of cycles at the top border to use, and then you have the visible area and then you have the bottom border to do more stuff outside the visible screen? But you were going to have graphics in the bottom border to? Then its ofcourse alittle worse.
Since I need all time I can get that is outside the visible screen I wonder if it's a good ide to use Timer B to generate a interrupt at the last scanline (line 200) so I know then I get to the bottom border and can start to put out some more data.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Wed Feb 13, 2008 10:00 pm

Zamuel_a wrote:
For my code I treat the start of each VBL as being the moment the last scanline has finished being drawn


Isn't the VBL started at beginning of the new screen? So you have a number of cycles at the top border to use, and then you have the visible area and then you have the bottom border to do more stuff outside the visible screen? But you were going to have graphics in the bottom border to? Then its ofcourse alittle worse.
Since I need all time I can get that is outside the visible screen I wonder if it's a good ide to use Timer B to generate a interrupt at the last scanline (line 200) so I know then I get to the bottom border and can start to put out some more data.

I mean from a purely logical point of view. Of course the actual VBL starts above the top of the screen and in the traditional way of doing things you would start each new screens code from there also. All I do is aim to have all the code for the current VBL done by the time the last scanline of the playfield is drawn so that all the time in the bottom border and the top border of the next redraw is available in one chunk for drawing the upcoming screens sprites. The fact that the status panel is in the bottom border is of little concern since it doesn't require updating in real-time like the playfield does and so its scanlines can still be included in the sprite drawing phase of the code.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Thu Feb 14, 2008 1:57 am

Ok, I see what you mean. Since you are in the bottom border you already know then you are at the last scanline so you I guess you are using timer B to generate an interrupt at the last scanline.
I was thinking about updating the palette every 16 scanline so I can have tiles with independant palettes. Not all 16 colors then because some colors always have to be the same over the entire screen like sprite colors and so, but perhaps 8 colors could be updated.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Thu Feb 14, 2008 6:12 am

Zamuel_a wrote:I was thinking about updating the palette every 16 scanline so I can have tiles with independant palettes. Not all 16 colors then because some colors always have to be the same over the entire screen like sprite colors and so, but perhaps 8 colors could be updated.

Sounds feasible. My code uses Timer B to change the sky colour every scanline and then again to change the palette for the status panel at the end of line 191 and then again at the end of line 199 to open the bottom border. So that the status panel does not interfere with the hardware scrolling its done as a split screen by setting the screen address to the address of my status panel bitmap at the same time as doing the palette split. Its worth mentioning that I have no idea if this kind of method has been done before or whether in the end it will leave me enough CPU time but I am hopeful :)
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Thu Feb 14, 2008 6:17 am

Heres a screenshot of the current code in action (scrolling horizontally). The white bar shows the amount of CPU time taken to draw scenery tiles and the dark red section above is a pause put in just to drop the white bar down far enough to see it (i.e. nothing important is being done here, yet).
You do not have the required permissions to view the files attached to this post.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Sat Mar 08, 2008 5:26 pm

I got it to work in all directions and was trying to optimize it by split the drawings by 16 since we only need to update every 16 pixels. Now I saw a problem. I have been drawing new tiles on the right side of the screen and a copy on the left side, but then I start to scroll I see that part that Im now trying to draw so I see then it draw the screen. My screen is 16+320+320+16 pixels wide but it seems like I have to do it 32+320+320+32 instead and treat the normal 320 screen as a 352 pixels instead, so I can scroll 16 pixels left and right without seeing the new data beeing draw, now at 320+16 pixels instead of the block just right to the screen.
Seems like I got everything wrong from the beginning:(
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Sat Mar 08, 2008 9:40 pm

Zamuel_a wrote:My screen is 16+320+320+16 pixels wide but it seems like I have to do it 32+320+320+32 instead and treat the normal 320 screen as a 352 pixels instead, so I can scroll 16 pixels left and right without seeing the new data beeing draw, now at 320+16 pixels instead of the block just right to the screen.
Seems like I got everything wrong from the beginning:(

unseenmenace wrote:I use a virtual screen that is 2 screens x 2 but with an extra 16 pixels on each, e.g. 672 x 432. You can have any height you want but for the hardware scrolling to work properly it needs to based on a 320 pixel wide play area.

I'm pretty sure 2x(320+16) is right as with all 336 pixels worth of scenery drawn you can then scroll within 16 pixels without revealing any part-drawn scenery but it may be easier to think in terms of 16 pixel rows and columns. Lets say your viewing columns 10 to 30 (21 columns of 42) and you're scrolling right, you will be drawing upcoming scenery in column 31 and scenery for the next screen flip in column 9. As soon as you change direction and start going left you have to undo what you've just been doing and draw upcoming scenery in column 9 and scenery for the next screen flip in column 31. This is where sharing the load out between the 16 frames of a column comes in, you can have a specific few blocks that are drawn in any 1 pixel position of a column so that the whole upcoming column is drawn by the time you start scrolling into it. When you change direction you just reverse the order that these blocks are drawn in and change what you are drawing there (as above). That way you can change direction mid column without any extra drawing needed. I hope that made sense :S
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Sun Mar 09, 2008 12:20 am

Ok, I have to do some thinking and see if I can solve it easily:)
But lets say that we start our screen at coordinate 0 and the first thing we do is draw the entire screen (default screen), then I can't just draw 320x200 pixels, I need to draw the 16 pixels to the right to so they are ready to scroll in then I start to move to the right and then I start to scroll I need to draw the next column of data on the right, but my screen address still starts at 0 since the first pixels I scroll in are within the 16 pixel block with the HSCROLL register and thats the pixels from coordinate 320-336. The new column to draw then I start to scroll must then be the data from coordinate 337 to 353. So with the screen address at 0 it means that the column to draw isnt the one just to the right of the screen since that is already shifted in with the HSCROLL register, it is instead the column starting at 337 to 353 and I then have to do the copy at coordinate -32 to -16 since the data at -16 to 0 has to be already drawn so I can change direction without having to update all that data to.
To do that I need 32 pixels on my left side then I start so it seems I need 32+320+320+32 pixels.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Re: How to use hardware scrolling in games?

Postby unseenmenace » Mon Mar 10, 2008 9:17 pm

I dug out my original notes for my scrolling routine in case they are of any help:-

Code: Select all

Visible Playfield is 320 x 192 pixels (20 x 12 blocks) but to ensure all drawing
is done invisibly you need 336 x 208 (21 x 13 blocks) therefore virtual screen
needs to be 672 x 416 pixels or 42 x 26 blocks.

Assuming we only have 1 pixel/frame scrolling then:-

For the horizontal scrolling you need to draw 2 columns of 26 blocks every 16
frames.
For the vertical scrolling you need to draw 2 rows of 42 blocks every 16 frames.

(2 x 42) + (2 x 26) = 84 + 52 = 136 blocks

Of course these rows and columns intersect in 4 places so in fact you only need
to draw 132 blocks.

132/16 = 8.25 so technically 8 1/4 blocks need to be drawn each VBL.


Example batch of 16 frames:-

Frame      Blocks to draw            Blocks  Total

Frame 0      0 to 7 of left column      8   8
Frame 1      8 to 16 of left column      9   17
Frame 2      17 to 25 of left columns   9   26

Frame 3      0 to 7 of right column      8   8
Frame 4      8 to 16 of right column      9   17
Frame 5      17 to 25 of right column   9   26

Frame 6      0 to 7 of top row      8   8
Frame 7      8 to 15 of top row      8   16
Frame 8      16 to 23 of top row      8   24
Frame 9      24 to 32 of top row      9   33
Frame 10   33 to 41 of top row      9   42

Frame 11   0 to 7 of bottom row      8   8
Frame 12   8 to 15 of bottom row      8   16
Frame 13   16 to 23 of bottom row      8   24
Frame 14   24 to 32 of bottom row      9   33
Frame 15   33 to 41 of bottom row      9   42

This draws 136 blocks every 16 frames but draws some twice to keep the logic
simple.  If I can think of an easy way of skipping the duplicated blocks then
I will.  I will get the theory working with 1 pixel per frame scrolling only
initially but eventually the game will need to be able to scroll faster in
certain situations such as when Turrican turns into the spinning disc
(horizontal) and when he is falling (vertical).  It could probably get away
with only ever scrolling faster than 1 pixel per frame in a single direction at
a time, the theory there being that if Turrican is in spinning disc mode and
falling he no longer has traction and therefore won't be moving as fast
horizontally.

e.g:-
XSPD=1, YSPD=1      OK
XSPD=2, YSPD=1      OK
XSPD=1, YSPD=2      OK
XSPD=2, YSPD=2      BAD

Example of XSPD=2, YSPD=1 (e.g. spinning disc mode):-

Frame      Blocks to draw            Blocks  Total

Frame 0      0 to 12 of left column      13   13
Frame 1      13 to 25 of left column      13   26

Frame 2      0 to 12 of right column      13   13
Frame 3      8 to 16 of right column      13   26

Frame 4      0 to 9 of top row      10   10
Frame 5      10 to 19 of top row      10   20
Frame 6      20 to 30 of top row      11   31
Frame 7      31 to 41 of top row      11   42

Frame 8      0 to 12 of left column      13   13
Frame 9      13 to 25 of left column      13   26

Frame 10   0 to 12 of right column      13   13
Frame 11   8 to 16 of right column      13   26

Frame 12   0 to 9 of bottom row      10   10
Frame 13   10 to 19 of bottom row      10   20
Frame 14   20 to 30 of bottom row      11   31
Frame 15   31 to 41 of bottom row      11   42


Example of XSPD=1, YSPD=2 (e.g. falling):-

Frame      Blocks to draw            Blocks  Total

Frame 0      0 to 13 of top row      14   14
Frame 1      14 to 27 of top row      14   28
Frame 2      28 to 41 of top row      14   42

Frame 3      0 to 13 of bottom row      14   14
Frame 4      14 to 27 of bottom row      14   28
Frame 5      28 to 41 of bottom row      14   42

Frame 6      0 to 12 of left column      13   13
Frame 7      13 to 25 of left column      13   26

Frame 8      0 to 13 of top row      14   14
Frame 9      14 to 27 of top row      14   28
Frame 10   28 to 41 of top row      14   42

Frame 11   0 to 13 of bottom row      14   14
Frame 12   14 to 27 of bottom row      14   28
Frame 13   28 to 41 of bottom row      14   42

Frame 14   0 to 12 of right column      13   13
Frame 15   8 to 16 of right column      13   26


Example of XSPD=2, YSPD=2 (e.g. falling disc):-

Frame      Blocks to draw            Blocks  Total

Frame 0      0 to 17 of top row      18   18
Frame 1      18 to 35 of top row      18   36
Frame 2a   36 to 41 of top row      6   42

Frame 2b   0 to 5 of bottom row      6   6
Frame 3      6 to 23 of bottom row      18   24
Frame 4      24 to 41 of bottom row      18   42

Frame 5      0 to 17 of left column      18   18
Frame 6a   18 to 25 of left column      8   26

Frame 6b   0 to 7 of right column      8   8
Frame 7      7 to 25 of right column      18   26

Same again for frames 8 to 15


After a bit of thought it occurs that the rows need to be independant of the
columns as otherwise it'll only work when the horizontal and vertical scrolling
are in sync with one another.  Therefore we need to draw a bit of each on each
frame:-

Rows (vertical)            Columns (horizontal)

Index   Row blocks    Blocks  Total   Index   Column Blocks  Blocks  Total

0   0 to 10 (top)   11   11   0   0 to 6 (l)   7   7
1               1
2   11 to 20 (top)   10   21   2   7 to 12 (l)   6   13
3               3
4   21 to 31 (top)   11   32   4   13 to 19 (l)   7   20
5               5
6   32 to 41 (top)   10   42   6   20 to 25 (l)   6   26
7               7
8   0 to 10 (bot)   11   11   8   0 to 6 (r)   7   7
9               9
10   11 to 20 (bot)   10   21   10   7 to 12 (r)   6   13
11               11
12   21 to 31 (bot)   11   32   12   13 to 19 (r)   7   20
13               13
14   32 to 41 (bot)   10   42   14   20 to 25 (r)   6   26
15               15

It only draws scenery on even pixel positions (in the row or column) so it'll
work just as well with 1 or 2 pixel scrolling.  The only proviso is that
increases of scroll speed must wait till the screen is on an even pixel.  This
could be overcome by simply doing each drawing batch on both even and odd
positions.  Using this system the most blocks that need to be drawn in a frame
will be 18.



SCROLL SPEEDS:-
---------------

Different levels will have different scrolling requirements

Chapter World   Level   Type         Max X   Max Y   Parallax

1   1   1   Normal      2   2   Rasters only
1   1   2   Normal      2   2   Rasters only
1   1   3   Normal      2   2   Rasters only

1   2   1   Normal      2   2   None
1   2   2   Normal      2   2   None
1   2   3   Normal      2   2   None

1   3   1   Vertical   0   4   Yes
1   3   2   Normal      2   2   None
1   3   3   Vertical   0   4   Yes

1   4   1   Normal      2   2   None
1   4   2   Normal      2   2   None
1   4   3   Normal      2   2   None

1   5   1   Normal      2   2   Rasters only
1   5   2   Normal      2   2   Rasters only
1   5   3   Normal      2   2   Rasters only


2   1   1   Normal      2   2   Rasters only
2   1   2   Normal      2   2   Rasters only

2   2   1   Normal      2   2   None
2   2   2   Normal      2   2   None

2   3   1   Normal      2   0   Yes
2   3   2   Normal      2   2   None
2   3   2   Normal      8   0   None

2   4   1   Normal      2   2   Yes (limited)
2   4   2   Normal      2   2   None

2   5   1   Normal      2   2   None
2   5   2   Vertical   0   8   None

UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: How to use hardware scrolling in games?

Postby Zamuel_a » Mon Mar 10, 2008 9:54 pm

I can't understand how you can manage it with just 21 blocks, 20 are visible, but if you scroll left then number 21 is the one you see with the HSCROLL register and 21 is the same you are currently redrawing? I need at least 22 blocks, 20 blocks showing if HSCROLL is 0, but if HSCROLL increase I start to see number 21 and I start to draw number 22 in 16 parts.
I don't understand how to do it any other way?
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 4 guests