horizontal scrolling on ST

[calimero]

Hi,

1. I always wonder why some games have smooth scroll (per pixel) even at 320x200, like:

- Car Vup youtube
(offtopic - Amiga version has clouds in parallax scroll youtube)

2. and some games have awful "stop and go", >8 pixel, scrool like:

- Blues Brother youtube
- Adams Family youtube

3. and there are some games in middle: they usualy have smaller playfield and jerky, but per pixel scrool (I would say less than 25fps).
I guess it's because they are ported from Amiga, like:

- First Samurai youtube
- Fire and Ice youtube
and much better:
- Harlequin (it has much better scroll than first two but also smaller playfield!) youtube
- Turican 2 (also smaller playfield but supersmooth scroll) youtube

---

so what do you need to do for smooth horizontal scroll on ST anyway?

I will try to explain to my self - I do not have required knowledge but from observation, and some info from net, I will try:


http://www.atarimagazines.com/compute/i ... s_leap.php

to move pixels to left (for one pixel) you need to:
- load four consequent words from RAM
- remember most left bit in every word
- shift bits inside words to left
- and add (previously remeberd) bit to most right position in every of four word?

if ST have 512 cycles per HBL (scanline), and there are 40 words per scanline
and one move.w take 6 cycles (I see that there is: movem.w d0-d3,* - 24cycles for 4 word?)
it is 40 words x 6 cycles = 240 cycles (for reading pixel data data ram)!
and than again 240 cycles for writing back to ram and we already (almost) spend entire "cycle" budget WITHOUT shifting, remebering, apending bits for scroling - it is just reading and writing data from/to RAM - CPU!

how then is it possible to scroll entire 32KB screen per pixel on ST at all??



---

...and Amiga has hardware for this, right?
nice text on topic: http://onabitplane.blogspot.com/2009/09 ... amiga.html

another topic would be parallax scroll - how Amiga accomplish this??

---

I took MC68K timings from: http://oldwww.nvg.ntnu.no/amiga/MC680x0 ... iming.HTML

[Cyprian]

move.w takes 8 cycles in case memory to register or register to memory operation, and 12 cycles in case memory to memory operation

[BoNuS]

Well I once did it for a demo and it takes up al load of memory.
Its called pre-shifting, just make the same screen 8 times in memory but each time
the gfx in the next screen are 1 line shifted. then is you swap through the screens
and show them it looks like the animation is smooth...
Is that what you are looking for ?

[Dio]

how then is it possible to scroll entire 32KB screen per pixel on ST at all??

It's not at 50Hz without hardscrolling. Lost a bet with Tim Moss about that 20 years ago .

160256 cycles per frame means maximum of 40k memory accesses per frame, so the most data you can blit even with movems in a single frame is somewhat under 20k, and you can't use those all the time in H-scrolling.

You can go faster than a read/rotate/write scroller by prerotating blocks and doing a read/read/or/write; you can go even faster than that if you prerotate combinations, so tiles can be directly blitted on.

I spent a while working on a parallax-scrolling horizontal shoot-em-up using a huge library of such tricks (transparent blocks, unmerged blocks, premerged blocks). Best I could do was about 80% of the screen every 3 VBLs (and it was never likely to be viable in 512M of memory, even doing prerotation on the fly during the level). Managed to get that running again a couple of years ago:



I liked the way Blood Money did it, where it updated the background every 5 frames or so but moved your sprite every frame to make it feel smooth. Genius of the first magnitude.

[calimero]

move.w takes 8 cycles in case memory to register or register to memory operation, and 12 cycles in case memory to memory operation

I wrote 6 cycles sinve there is movem.w that will move 4 words in 24 cycles? right?

[calimero]

Well I once did it for a demo and it takes up al load of memory.
Its called pre-shifting, just make the same screen 8 times in memory but each time
the gfx in the next screen are 1 line shifted. then is you swap through the screens
and show them it looks like the animation is smooth...
Is that what you are looking for ?

I do not think that Car Vup use preshift: I think that background is to "different" to preshift everything!
but Car Vup have super smooth scroll in all 8-ways of entire screen!

[calimero]

@Dio

thanks for answer! so it must be a preshift if it is smooth scrool on ST...

Do you have some demo of that shooter that you would like to share? O:)

regarding Blood Money - I really like that game and play a lot but I never notice that!!! really genius concept


---

so how hardware scroll work on STe or Amiga - it is implemented in hardware so CPU is used only to set parameters?


and how CarVup is made?

[simonsunnyboy]

On the STE you have additional hardware registers that allow you to define a pixel correct "window" (which is always a full scanline wide without tricks) over your screen memory. You basically have a picture larger than 32K in memory and set the registers accordingly to display only a portion of this.

However managing sprites and adding new background properly on a hardware scrolled STE screen eluded my work sofar

On STF it is crazy sync and cyclecounting stuff which certainly won't work on the Falcon due to the timing. The STE hardscroll works the same on the Falcon.

[calimero]

On the STE you have additional hardware registers that allow you to define a pixel correct "window" (which is always a full scanline wide without tricks) over your screen memory. You basically have a picture larger than 32K in memory and set the registers accordingly to display only a portion of this.

and do you know how it is implemented in STe?
are bits really rotate inside every byte...?

and why this is not implemented in fisrt ST? as I can see, there are lot of games for Commodore 64 with fullscreen smooth scrolling - does C64 do this in hardware?

[simonsunnyboy]

The STE does this all in hardware, I don't know what sort of bit shifters or intelligent bit reading networks are inside the STE shifter.

It was left out in the plain ST due to price reasons. The machine was designed to compete with the Macintosh and thus did not need pure gaming hardware.
The hardware scrolling doesn't really help desktop applications so why waste money on pricy specialized hardware?

ggn once did a nice example in GFABASIC: http://paradize.final-memory.org/downloads/stehscrl.lst

All you do is write the correct values into the registers and update them properly.

*EDIT* And yes, the C64 and Atari 8Bits have a similar hardware support too, main difference is they smoothscroll a character based screen map, not a pixel addressable.

[Dio]

so it must be a preshift if it is smooth scrool on ST...

Unless it's an STE, I reckon so, and even then you can't do the full screen at 50Hz, 25Hz is the best you can do. You can use sync-scrolling if you only need 16-pixel alignment a la Enchanted Lands.

Do you have some demo of that shooter that you would like to share? O:)

That pic is about is about as far as it got. Managing gameplay was getting too complicated to work in a reasonably primitive asm (no structs) and I didn't know enough about data structures at the time. I had the movement pattern table, the wave content table, the timing of enemy waves table... it was bad enough when there was just tables of tables, but by the time it got to a table table table table, I was losing interest. The graphics engine was a solid prototype, and the dynamic preshifting and interrupt loading were very good ideas to keep it varied, but there was never any gameplay. We finally dumped it when I started work on Starball.

so how hardware scroll work on STe or Amiga - it is implemented in hardware so CPU is used only to set parameters?

It changes the design challenge of the app a lot - you tend to use draw/undraw dirty region sprites rather than a repaint-every-frame architecture.

[danorf]

As far as I can say, I think the best code for doing 1 pixel wide horizontal scrolling with an 68000 with no dedicated hardware or any hardware trick as sync-scroll, must take 328 cycles per line (low res) per bitplan (in the best case). so you can scroll one or two bitplans of a full screen image (320*200) within a 50Hz frame but not 4. Within 2 frames it could be possible (but with a huge code : >62KB), so don't expect more than 25 images/second with an horizontal scrolling on a plain ST (unless with preshifted graphics).

[calimero]

That pic is about is about as far as it got. Managing gameplay was getting too complicated to work...

I did not think on game but on "technical demo" - I just wan to see all that scrooling ...

@danorf - thanx for answer!

[mc6809e]

It changes the design challenge of the app a lot - you tend to use draw/undraw dirty region sprites rather than a repaint-every-frame architecture.

This to me is THE trick to get high frame rates on the ST. The 68000 is mostly memory bandwidth limited so the fastest rates are obtained by simply minimizing the number of memory accesses.

[dml]

This to me is THE trick to get high frame rates on the ST. The 68000 is mostly memory bandwidth limited so the fastest rates are obtained by simply minimizing the number of memory accesses.

Yes... and if you're moving things much bigger than bullets, consider using a fast hashtable to track dirty BG tiles inside the playfield manager itself, repainting sprite areas rapidly from tiles instead of save/restore. It amortizes sprite overlaps, is order-insensitive and works much better for bigger objects (esp. _really_ big objects since you can repaint the dirty margins only).

Also, by tracking items through the playfield manager, it has a chance to optimize away repaints in pending dirty scroll edges and can completely ignore repaints outside the active display area...

my 2p

[EDIT]

Granted this isn't much use on an ST with h-scrolling as noted below - the whole display needs rebuilt because there is no line 'skip' register and therefore no offscreen margin to scroll into even with heavy preshifting or syncscroll addressing tricks (not that I know of anyway ;0). Only useful with v-scrolling, or STE and Falcon HW scroll...

[Dio]

This to me is THE trick to get high frame rates on the ST. The 68000 is mostly memory bandwidth limited so the fastest rates are obtained by simply minimizing the number of memory accesses.

Sure, but it's only useful in games where the playfield is static. I moved to it for the PC version of Starball, which used hardware scrolling, but on the ST version as soon as the table scrolled you'd have to wipe everything anyway so there's no point in draw/undraw.

[ljbk]

As far as I can say, I think the best code for doing 1 pixel wide horizontal scrolling with an 68000 with no dedicated hardware or any hardware trick as sync-scroll, must take 328 cycles per line (low res) per bitplan (in the best case). so you can scroll one or two bitplans of a full screen image (320*200) within a 50Hz frame but not 4. Within 2 frames it could be possible (but with a huge code : >62KB), so don't expect more than 25 images/second with an horizontal scrolling on a plain ST (unless with preshifted graphics).

I confirm that.
And the problem is if you want to scroll more than 1 pixel at a time.
Shifting 1 pixel will always look smooth, may be slow but smooth.
Shifting 2 pixels via SW without any preshift trick leads to at least 3 frames to move the 4 bit planes screen: this will look bad. Solution => memory for each possible shift / 8 or 9 video screens => not applicable to games that have to run with 512KB.

I still have a source that is more than 25 years old where i tried to do the no-trick 4 planes scroll with shifts > 1.
Probably it is not the best, and surely could be improved (for example: generated code would remove the swap D6 because no dbf counter would be needed anymore => but more memory needs), but it can be used as an example.
It looks like this for 16 dots :
...
move.l (a1)+,d0
move.l (a1)+,d1
rol.l d7,d0
rol.l d7,d1
move.l d0,d4
and.l d5,d4
and d6,d0
swap d0
and d6,d0
or.l d2,d0
move.l d1,d2
and.l d5,d2
and d6,d1
swap d1
and d6,d1
or.l d3,d1
move.l d0,(a0)+
move.l d1,(a0)+
...

This takes 112 cycles + 2 rol.l => around 136 cycles for 16 dots and 2 pixels shift !!!
As we have 64000 pixels, we would need around 544000 cycles for the whole screen => 3.4 frames !!!
The worst case happens with a 4 pixel shift but the result should still be under 4 frames.
Anyone managed this under 4 frames ?
This means less than 120 cycles for each block of 16 dots !


Enjoy,
Paulo.

[Dio]

For backgrounds, the advantage of shifting in granularities above 1 pixel is that it reduces the memory cost of the preshifts. For 4-pixel granularity horizontal scrolling (e.g. Time Bandit) you only need 7x the cost of one block for the prerotations.

Interestingly, you can also use unusual tile widths. For example, if you're prerotating onto a 4-pixel boundary, you can use 20-pixel-wide tiles for only a touch more memory than a 16-pixel wide tile (8x instead of 7x). Doesn't sound like much but it's 25% more pixels actually with data in, so nearly a 10% memory efficiency improvement, it means you only have a 16 tile per screen loop instead of a 20 tile per screen loop, so you just reduced your cost to 80% too, and it means your background redraw cost is constant, rather than 'fast' in the 1/4 cases where you have a 16-pixel boundary and 'slow' in the 3/4 cases where you don't.

If (admittedly clunky) byte scrolling is acceptable, then you get a very interesting 24-pixel tile width, prerotations are only 4x the memory of unrotated tiles and only a 14-tile loop, 70% of the cost of a 16 pixel tile background. If someone was going for a very fast-rate horizontal shoot-em-up, I think you could do that over at least 60% screen area with a basic starfield parallax at 25fps on a 512M machine. Use these big-tiled, fast backgrounds and some compartaively small dinky sprites and I reckon you'd have a very interesting basic idea for a game.

I only observed this a few years ago and I'm not aware of any games that used it.

I just thought of another way you could do this without prerotation, at the cost of (huge amounts of) memory: maintain N screens (where N is the scroll granularity) . Basically, hardware scrolling but with a software blit. Not really going to work well on 512M for 1-pixel fullscreen, but a small-ish window and 4-pixel granularity might be workable.

[simonsunnyboy]

I assume Steve Bak did something like this. His fast and efficient scrolls however are not in fullscreen but it doesn't matter. Starray on a 520ST is pretty impressive.

[mc6809e]

This to me is THE trick to get high frame rates on the ST. The 68000 is mostly memory bandwidth limited so the fastest rates are obtained by simply minimizing the number of memory accesses.

Sure, but it's only useful in games where the playfield is static. I moved to it for the PC version of Starball, which used hardware scrolling, but on the ST version as soon as the table scrolled you'd have to wipe everything anyway so there's no point in draw/undraw.

Well okay. But by my reckoning there are only about 3500 accesses remaining per frame if the CPU uses the rest of the time to blit to the frame buffer with MOVEMs, so 50 FPS is possible, but there isn't much time for anything else. I also notice Starball has a 64px margin on the right that appears to be mostly static. How many extra cycles per frame remain because you avoid updating this region? Don't get me wrong. Starball is impressively fast for all the action in the playfield, but I'm sure you would have lost at least a few FPS if you were trying to vert scroll 320 pixels instead of 256.

[calimero]

Well okay. But by my reckoning there are only about 3500 accesses remaining per frame if the CPU uses the rest of the time to blit to the frame buffer with MOVEMs, so 50 FPS is possible, but there isn't much time for anything else. I also notice Starball has a 64px margin on the right that appears to be mostly static. How many extra cycles per frame remain because you avoid updating this region? Don't get me wrong. Starball is impressively fast for all the action in the playfield, but I'm sure you would have lost at least a few FPS if you were trying to vert scroll 320 pixels instead of 256.

but Starball is a vertical scrolling game! isn't be even more easier to scroll entire screen up and down by changing video address for 160 bytes? (or this is caveat with that "256" bytes boundary for video memory address??)

btw I never played Starball, it really looks interesting! it will be game for tonight

[Dio]

by my reckoning there are only about 3500 accesses remaining per frame if the CPU uses the rest of the time to blit to the frame buffer with MOVEMs, so 50 FPS is possible, but there isn't much time for anything else.

Yeah, the limit is 40k word accesses per frame, with the screen taking 16k accesses to read in full. To blit the table on Starball took 25600 accesses plus movem overheads (64 words * 200 lines * 2) + about 12 cycles per 48 bytes if I remember correctly.

How many extra cycles per frame remain because you avoid updating this region? Don't get me wrong. Starball is impressively fast for all the action in the playfield, but I'm sure you would have lost at least a few FPS if you were trying to vert scroll 320 pixels instead of 256.

Yeah, it was deliberate for just about every reason - time, size of the table in memory, but game design too, since we wanted a board somewhere - the original plan was to do more animation on it, rather than just the text, but it was too much like hard work. (Starball actually started out briefly as a Star Fleet pinball game, if anyone remembers the puppet series from the 80s, and there were plans to do FMV, streamed off the disk using interrupt transfers).

Starball runs at 25fps fixed on standard ST, except very rarely in Invaderball it just creeps over the line into the next frame sometimes if you continually press both flippers due to the large number of (non-prerotated) sprites. The table blit takes about 80% of a frame as noted above. With hardware scrolling or sync scrolling it might just have been possible to make it run at 50fps, but neither was an option, and even if it was it would have reduced the peak sprite count significantly and created even more memory problems than we had anyway (it's very close to not fitting into a 512M machine).

but Starball is a vertical scrolling game! isn't be even more easier to scroll entire screen up and down by changing video address for 160 bytes? (or this is caveat with that "256" bytes boundary for video memory address??)

Yeah, can't scroll by individual pixels on a non-STE without sync-scrolling, which I didn't know how to do and wouldn't have trusted very much. And then it wouldn't have run (at glorious 50fps for the ball and background, at least) on the Falcon either .

[calimero]

but Starball is a vertical scrolling game! isn't be even more easier to scroll entire screen up and down by changing video address for 160 bytes? (or this is caveat with that "256" bytes boundary for video memory address??)

Yeah, can't scroll by individual pixels on a non-STE without sync-scrolling, which I didn't know how to do and wouldn't have trusted very much. And then it wouldn't have run (at glorious 50fps for the ball and background, at least) on the Falcon either .

ooouch! ... so there is no "hardware" scroll for vertical alignment either?

so how then you do vertical scroll on ST? pushing words around without rotating??

[Dio]

That's the way I did it. Just threw bytes at the screen. As mc6809e says, works fine at 25fps but it's very hard to do 50fps unless you cut the window size down a lot.

[calimero]

That's the way I did it. Just threw bytes at the screen. As mc6809e says, works fine at 25fps but it's very hard to do 50fps unless you cut the window size down a lot.

and "256 bytes" boundary limit for video address is because low/or high part of video register is not writable ? right?