Horizontal Scrolling with 4x Fetch and all sprites
 

Hi All,

I've been reading up on a few threads today regarding the Amiga AGA's ability to scroll horizontally (256 pixels undisturbed).

It seems though that the only way to scroll with 4x bitplane fetch is to start DDFSTRT at $18 and lose most of the HW sprites.

Has the experienced coders here ever managed to achieve this?

Geezer

I've been mucking about with AGA scrolling & sprites with 4x fetch but so far haven't managed something useful. Mainly due to the alignment restrictions of the bitplanes.

So far, my best result for 256 pixels wide @ 4x fetch + scrolling is basically the standard X position of the screen + 64 pixels. It may be possible to make this into a DDFSTRT at $34 (using the same trick to do so as would be used on the A500), but that would not change much.

I originally thought you might be able to do much better, but I forgot the bitplanes need to be aligned to 64 bits at all times in 4x fetch mode :(

256 quarter pixels, 64 low-res pixels.

Unfortunately yes if you want the standard 320x screen with DIWSTART=xx81 and full 64px wide scroll. :(

Thanks Roondar - I know we discussed this over pm, but I just wanted to canvas opinion for the other devs.

I'm actually looking at Aladdin now and it it running in 4x fetch mode, I can't tell yet though if it has all the sprites available (doesn't look like it).

Geezer

One thing I have considered, but not programmed/tried yet is a 'partial' approach where you use the standard $38 ddfstrt and use a display window that is shifted by 16 or 32 pixels to the right.

Then, using 4x fetch it should be possible to scroll by either 16 or 32 pixels using the hardware without odd effects (using a delay of the right values to only shift this many pixels without showing empty space). This then gives you 16 or 32 frames to create a 16 or 32 pixel shifted version of the screen in a new bitmap buffer.

This might work. It will take a whole bunch of memory though (2 additional full screen buffers) and I've not calculated to see if the extra Blitter/CPU cost of drawing the screens this way is actually smaller than the gains for 4x fetch mode.

Edit: did a bit of back-of-the-envelope calculation and it seems that this method probably does not gain you any time. It probably won't lose you any either, but meh - not super useful.

Cheers Ross.

Considering my Rygar implementation though it is running in 2x fetch mode. The challenge is to know if it's technically possible to get it running in 4x fetch mode.

When I played around with this initially I couldn't get it to work so settled on 2x mode... but the playfield is only 256px wide so I'm unsure if it is achievable or not.

Not if you want a centered screen.
1x -> DDFSTART=$38 -> DIWSTART=$91, DIWSTOP=$1b1 -> 288px
2x -> DDFSTART=$38 -> DIWSTART=$a1, DIWSTOP=$1a1 -> 256px
4x -> DDFSTART=$38 -> DIWSTART=$c1, DIWSTOP=$181 -> 192px :banghead
Sure you can have a screen in 4x with a 64px left screen part covered by sprites, and a full 256px right part, but for another game ;)

Cheers :)

Thanks Ross, that's pretty much what I calculated as well.

Here's my copper init routine... Just slightly different i guess.

Yes, your values are a bit 'strange', but I can be wrong, I make some test and report. :)

Probably wise I drop in the whole list then. ;)

(or most of it)

My values are correct, test the attach (total garbage test :)).

9x 32bit fetch, DDFSTRT=$38, DIWSTRT=$2ca1
Shift screen with left/right mouse buttons.
Both to exit.

EDIT: I do not know what I've uploaded before, this is the right test :D

EDIT2: you've a DMA surplus fetch (11x!), you cut to much DIW and video is too much to right
but better rethink at it tomorrow :sleep

MORNING EDIT: the best you can do with FMODE=7 is in tgt_x5
5x 64bit fetch, DDFSTRT=$30, DIWSTRT=$2cb1 to $1b1 (much similar as yours)
1 sprite missing in action.. but massive bandwidth gain [5x vs 11x(or better 9x)]