STE Hardware scrolling techniques

GFA, ASM, STOS, ...

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

Post Reply
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

STE Hardware scrolling techniques

Post by elliot »

So I have been looking back at my old coding techniques and I always had a problem with the most efficient way of doing scrolling on the STE.

If your playfield was say 640x400 then you would just allocate 128k and scroll around it perfectly, easy use of the scroll registers and then a source address update when you reach the threshold - next to zero CPU time. However, if you had an infinite (say tile based) playfield then you may do something like a 64K screen buffer and scroller over it building as you go and then doing a blit copy of the entire last 32K back to the first 32K which would lead to a frame drop or two every 320 pixels. I am sure I am sure I have seen this and even worse seen it done every 16 pixels which means a jerk every 16 pixels.

If the STE had registers for the screen something along the lines of x/y count and source increment (decrement) then you could just "fold over" a single screen mid scan line (imagine the effects you could do). This would probably be a real head f*!k for the sprites but not impossible, however, the STE does not (as far as I am aware) have such registers - did the Amiga? It is probably possible to do this for a vertical scroller and change the screen address at a certain scan line but I think for the X it would require super timing on each scan line that would eat CPU time. Has anyone tried to change the screen address mid scan line?

Thinking back what I did was in each frame I drew (for my horizontal scroll) I would have 320x200 with another 320x200 map built to the right of that and then I would write something like 2 or 3 of the 16X16 tiles in the buffer to the "right" of those buffers which left me with a frame or two to copy that 16x200 block back to the start of the buffer. When the screen reaches the far right I could then move it back to the first 32K with a complete screen already built and the process starts again. The screen and complete copy of if would be built over many frames which would spread out the workload and make the work timing for each frame much more uniform. I hope this makes sense written here!

There is a bunch of logic that needs to be addressed with sprite locations but not that big a deal but in addition there were some advantages, for example, you would have a copy of the original screen before the sprites were drawn so when you came to clean them up you could just blit back a section from the copy you already had.

My point is, no matter what, I could not figure out a way of mitigating the 16X200 blit copy of something I had already drawn. I know it is not a big deal but I am wondering if there was a method that I am simply not seeing to do infinite scroll without making copies on screen data you had already drawn! This is a thought experiment really but any ideas, technics, cheats would be welcome. Here I am talking no overscan, 4 bitlanes, 320x200x16, etc but if it is an interesting method outside of this then I would love to know that too.
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
User avatar
thomas3
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Apr 11, 2017 8:57 pm

Re: STE Hardware scrolling techniques

Post by thomas3 »

Nah, that's the way you do it. (AGT does it that way too - sure there's a thread on here where dml discusses the tech in detail, including use of the second screen to clean up dirty screen areas).

Obviously you want to be organising your tiles etc to enable efficient drawing to both margins, rather than drawing one side and then "copying" to the other, but I'm sure you know that and we're in the realm of semantics here :)

Ps - this method works on STF too with syncscroll, but you would only need it for vertical scrolling. For horizontal scrolling you just draw the immediate left or right margin depending on direction. This is because e.g. a 64k buffer gives you many many "screens" capacity as you're only moving your (simulated) screen pointer by 8 bytes. (Of course you need to hold multiple shifted copies for scrolling in smaller increments).
joska
Hardware Guru
Hardware Guru
Posts: 5342
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: STE Hardware scrolling techniques

Post by joska »

What thomas3 said - distribute tile drawing across frames and write to both the column to be scrolled in AND the column that was just scrolled out at the same time instead of copying an entire column every time you increase/decrease the address pointer.

As for sprite positioning - I have only done this once so I may be completely wrong, but IMO the easiest approach is to work with map level coordinates and transform those to screen coordinates when drawing the sprite. So if your current map is 10 screens wide, you will use x coordinates 0-3199 for all sprites/objects for everything, and let the drawing routines worry about the physical position. If you take scrolling into consideration for every move, collision check etc your code will probably get a lot more complex than it has to be.
Jo Even

VanillaMiNT - Falcon060 - Milan060 - Falcon040 - MIST - Mega STE - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
Zamuel_a
Atari God
Atari God
Posts: 1275
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: STE Hardware scrolling techniques

Post by Zamuel_a »

What I have done is to just reserve a large enough area for the level and scroll it without drawing any tiles. It takes no cpu time and most games doesnt have so huge levels so memory is an issue.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

It is true that nowadays on a 4mb STE you could reserve 3mb for screen and still have a meg for samples, code, sprites, etc and you would have a virtual resolution of 30,720x200 which is a big level. But back then half meg would be limiting your game...

Also, this does not allow for infinite scrolling though but I suppose you just design your game around this.
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
User avatar
Frank B
Atari God
Atari God
Posts: 1054
Joined: Wed Jan 04, 2006 1:28 am
Location: Glasgow

Re: STE Hardware scrolling techniques

Post by Frank B »

This is Amiga centric but the techniques work on the STE.

http://aminet.net/package/dev/asm/8wayscroller

You only need 8 bytes for every 16 pixels you scroll. You do not need 64000 bytes to scroll two screens, You need only 160 bytes.
That's a great document for understanding how scrolling works. HTH
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

I am just doing some calculations on some ideas, what is the "rule of thumb" scroll rate of games? I am talking about scrolling shooter so say R-Type or Blood Money?

At 50Hz if you scroll a pixel per VBL then you are scrolling 50 pixels a second which seems very high. I am thinking one would scroll a pixel every 5 frames or so for a fast shooter - that makes 10 pixels every second right?
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
User avatar
keops
Atari Super Hero
Atari Super Hero
Posts: 649
Joined: Mon Jul 26, 2004 3:39 pm
Location: Canada
Contact:

Re: STE Hardware scrolling techniques

Post by keops »

50 pixels per second is totally ok, that's 6.4 seconds to scroll the entire screen horizontally. Less than that won't look good / smooth.
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

Okay that does sound fine in fact.

So if my calcs are correct, 3mb is around 90 320x200 screens (32K each) which means 90X320=28,800 pixels on the X axis. So that then means 6.4 seconds x 90 = 576 seconds to scroll the entire "level". 576/60=9.6 minutes of level which is a lot.

That does sound like a lot - is my math correct?
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
User avatar
Orion_
Atari Super Hero
Atari Super Hero
Posts: 513
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

Re: STE Hardware scrolling techniques

Post by Orion_ »

I tried for months to code a 8 ways scroller on Falcon using hardware scrolling using a 640x480 buffer, but I never succeeded, the problem is when you are on the far right limit of your buffer and you wrap up the scrolling back to the screen origin, your screen content must be the same on both side, I could achieve that on a 2 way scrolling by copying the tile on both side each time (let's say horizontal only), but scrolling on the 8 ways is always messing things up.
by the way, copying tile using unrolled loop on falcon cpu is faster than using the blitter (blitter is faster at copying sprite with masking & shifting)
User avatar
thomas3
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Apr 11, 2017 8:57 pm

Re: STE Hardware scrolling techniques

Post by thomas3 »

elliot wrote: Sun May 01, 2022 2:58 am Okay that does sound fine in fact.

So if my calcs are correct, 3mb is around 90 320x200 screens (32K each) which means 90X320=28,800 pixels on the X axis. So that then means 6.4 seconds x 90 = 576 seconds to scroll the entire "level". 576/60=9.6 minutes of level which is a lot.

That does sound like a lot - is my math correct?
Are you saying you're planning to have pre-rendered background screens sitting in memory?
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

Yeah I figure why not! You could remove the need for any tile/map logic and even better you could load an entire level from a hard disk and it be a completely "free form" image, down side is someone would need to draw it. Of course you could still pre-render a large level from tiles.

Now we have 4mb STE's and large hard disks, although these machine where indeed possible in the 80s/90s they would be rare and expensive so no one would do such a thing.
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
joska
Hardware Guru
Hardware Guru
Posts: 5342
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: STE Hardware scrolling techniques

Post by joska »

elliot wrote: Sun May 01, 2022 2:58 am So if my calcs are correct, 3mb is around 90 320x200 screens (32K each) which means 90X320=28,800 pixels on the X axis. So that then means 6.4 seconds x 90 = 576 seconds to scroll the entire "level". 576/60=9.6 minutes of level which is a lot.
True, but it does complicate your code quite a bit as there is no room left for double-buffering and a background buffer for sprite restoring. Working around this is probably more complicated than implementing a tilebased scroll.

But of course, even if you divide this by three and also allocates some "borders" to avoid sprite clipping you still have room for 20+ screen long levels.
Jo Even

VanillaMiNT - Falcon060 - Milan060 - Falcon040 - MIST - Mega STE - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
User avatar
thomas3
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Apr 11, 2017 8:57 pm

Re: STE Hardware scrolling techniques

Post by thomas3 »

Completely agree on the double buffering issue. Also, you'd still have to copy gfx to the margins of the playfield for the background, given the limits on STE playfield size. Ultimately then, you'd be saving a relatively tiny slice of CPU versus drawing the tiles (which, if stored and indexed optimally, would take only a few instructions more than a straight copy from a pre-rendered background).
joska
Hardware Guru
Hardware Guru
Posts: 5342
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: STE Hardware scrolling techniques

Post by joska »

Ahh... I forgot that. The STE's linewidth register is only 8 bits, it's the Falcon that has a 16 bit linewidth register. So scrolling one huge buffer can't be done on the STE.
Jo Even

VanillaMiNT - Falcon060 - Milan060 - Falcon040 - MIST - Mega STE - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
User avatar
dhedberg
Atari God
Atari God
Posts: 1361
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: STE Hardware scrolling techniques

Post by dhedberg »

joska wrote: Tue May 03, 2022 8:40 pm Ahh... I forgot that. The STE's linewidth register is only 8 bits, it's the Falcon that has a 16 bit linewidth register. So scrolling one huge buffer can't be done on the STE.
Unfortunately not all 16 bits can be used on the Falcon030. Can't recall exactly how many bits are used.
Daniel, New Beat - http://newbeat.atari.org.
Like demos? Have a look at our new Falcon030 demo It's that time of the year again, or click here to feel the JOY.
joska
Hardware Guru
Hardware Guru
Posts: 5342
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: STE Hardware scrolling techniques

Post by joska »

10 bits.
Jo Even

VanillaMiNT - Falcon060 - Milan060 - Falcon040 - MIST - Mega STE - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2721
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: STE Hardware scrolling techniques

Post by Cyprian »

joska wrote: Wed May 04, 2022 8:29 pm10 bits.
10 bits means 2048 bytes (1024 words), it is quite a lot,
and if I'm not wrong this is an offset between end of one line to the beginning of the next line.
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
User avatar
Orion_
Atari Super Hero
Atari Super Hero
Posts: 513
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

Re: STE Hardware scrolling techniques

Post by Orion_ »

*phew* just enough for my biggest game map of 1968x1120 pixels
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

joska wrote: Tue May 03, 2022 8:40 pm Ahh... I forgot that. The STE's linewidth register is only 8 bits, it's the Falcon that has a 16 bit linewidth register. So scrolling one huge buffer can't be done on the STE.
Wait so the scroll registers are not big enough to deal with a very large map? Surely you just change the base address when they reach their max?

The game I had in mind only had a few 16x16 sprites on screen at a time, also some pallet rotation on a few colours for effects (water, fire) so I was kind of hopping that the blitter could cope with that. I must say I did not think about the sprite update (i.e. a double buffer which this method does not have), for this method to work it would have to all be done in bottom/top border and VBL or there will be strange artifacts from time to time. I am not sure how much time that is!

Check my logic, for a sprite placement one would have to copy the destination GFX to a temp buffer, maybe this could be done in one blit if the area blitted was far more than the sprite+offsets. Then the sprite would be blitted in plus offsets at a bit plane at a time.

Next update would be to move the temp buffer back and repeat. I am guessing the logic to figure out if you need to blit out to the temp buffer again is prob more work than just blitting it.

I must admit, I never really figured out the blitter when it came to sprites/copies not on a 16 pixel block. I have kind of figured out you can not just blit a sprite in and move is 4 pixels to the right you need to blit a plan at a time - is that right?
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

And what about the blitter, what is the max x inc you can have? or is it Y inc?
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
User avatar
thomas3
Captain Atari
Captain Atari
Posts: 279
Joined: Tue Apr 11, 2017 8:57 pm

Re: STE Hardware scrolling techniques

Post by thomas3 »

Remember - screen memory is a one dimensional space (just like all memory), which is then rendered in lines. If you change the screen base, all you'll therefore do is offset the image and/or scroll vertically. To achieve hardware horizontal scrolling, you need to set up an background image with a line length greater than that of the screen, and then jump over the sections of each line you're not displaying. This is the line width register we speak of. The limitations of this register are such that you can only set up a playfield of a few screens width. You can still draw to each margin within this to create an infinitely scrolling area, AND of course there's the huge advantage of being able to hardware scroll by 1 X pixel, meaning no multiple preshifted backgrounds. Hurrah!

On the sprites... No blitter expert but I think the gains come drawing larger areas due to set up overheads for each blit. Someone can correct me but there may not be an advantage blitting 16x16 sprites.
elliot
Captain Atari
Captain Atari
Posts: 215
Joined: Tue Mar 17, 2009 2:00 pm

Re: STE Hardware scrolling techniques

Post by elliot »

Ahhh okay I get it, I assumed the X jump/skip register (whatever it is called) was 32 (24) bit - well enough to jump around a full 4mb.

That pisses all over my idea then!

I also assume it is unsigned? Not sure where this would be useful, so kind of reflection maybe.
Falcon with CT60 in rack mountable case. Two STFMs, one upgraded lots. My original STE from when I was a teen with Switchable TOS, 1.44Mb drive, 4MB RAM, Supra Hard Drive and very very yellow case. Mega STE with (currently none working) Crazy Dots 2. Atari 2600 and a Jag. And a mountain of commercial software and lots of hardware addons.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2721
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: STE Hardware scrolling techniques

Post by Cyprian »

elliot wrote: Fri May 20, 2022 11:01 pm And what about the blitter, what is the max x inc you can have? or is it Y inc?
Both 16bits signed
Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.atari.org
Post Reply

Return to “Coding”