Horizontal scrolling tricks

[jotd]

I'm trying to roll my own scrolling routine in assembly for a game you'll instantly recognize

[ Show youtube player ]

I haven't tackled the "end of memory" issue yet, but I suppose you have to draw the tiles twice and jump "back" to lower bitplanes when you do that to give the feeling of continuity. I'll do that later

Now I'm more concerned by left & right parts.

I'm using dual playfield (ship and status are on another plane set)


- What can I do to hide the drawing of tiles on the right before it's scrolled (note that the right part of the screen is going to be blank/only show the score as the game is portrait hence the tiles appearing 2/3 of the screen width)
- What can I do to avoid the shifting on the left which leaves a black stripe when bplcon1 is not 0 (more visible when 15) ?

I'm aware of the aminet "scrolling tricks" archive which is great, although the code is not really explained very well. There are weird masks, multiplications by 17 (!!!) and probably also wrong stuff.

For example in this code

static void UpdateCopperlist(void)
{
	ULONG pl;
	WORD	xpos,planeaddx,scroll,i;
	WORD	*wp;

	i = fetchinfo[option_fetchmode].scrollpixels;  // 16 for me (fmode = 0)

	xpos = videoposx + i - 1;

	planeaddx = (xpos / i) * (i / 8);
	i = (i - 1) - (xpos & (i - 1));    ====> whaaat????
	
	scroll = (i & 15) * 0x11;    ====> multiply by 17 what the hell????
	if (i & 16) scroll |= (0x400 + 0x4000);  =====> isn't that ending by setting wrong/unused bits into BPLCON1
	if (i & 32) scroll |= (0x800 + 0x8000); ======> same remark
	
	// set scroll register in BPLCON1
	
	CopBPLCON1[1] = scroll;

[saimon69]

Looking at the future i can see also a Super Cobra coming...

[DanScott]

You have to increase DDFSTART and DDFSTOP, and use DIW to 'mask' these areas.. Or use sprites to mask if possible

[DanScott]

Multiply by 17 moves the 4 bit scroll value into the right places to scroll both odd and even planes. Lookup would probably be quicker

[jotd]

ah makes sense. With dual playfield I don't need that

thanks Dan. I wanted to make sure that I wasn't missing anything. So you're saying that scrolling games have a narrower display than non-scrolling games.

So that will be sorted for the left side. For the right side, that will be slightly trickier. I can't use sprites because the starfield already uses sprites and that's low priority (else a big black - possibly multiplexed - sprite bar could probably have done the trick).

I can use an extra black color on playfield 1 just to mask playfield 2. That's a waste of 1 color out of 8, but I can probably take it.

Another option would be to blit a black bar in playfield 2, with a bit shift so it makes up the scrolling shift. Probably the saner option (Supercars 2 does that for the central area in 2 player mode)

[morbid]

if (i & 16) scroll |= (0x400 + 0x4000);

Aga added more bits to bplcon1, described here
http://www.lysator.liu.se/amiga/code...ocode/text/AGA

scrolling games have a narrower display

Doesn't have to be narrower, as @DanScott suggested you can alter diwstart/diwstop in combination with ddfstrt/ddfstop

I can't use sprites because the starfield already uses sprites

Wouldn't one multiplexed sprite be enough for the starfield?

[DanielAllsopp]

I used a smaller display for the scrolling in my RoboCop port; the bitmap/buffer is still 320 pixels but the display window is set be 288 pixels wide with a 16 pixel buffer at either side (this is an old example when I was messing with Ghouls N' Ghosts):



I guess there's nothing to stop you making the buffer 352 pixels wide which still gives you the 16 pixel buffer either side, and will allow you to use the full 320 pixel width of the screen.

[jotd]

Originally Posted by morbid

Aga added more bits to bplcon1, described here
http://www.lysator.liu.se/amiga/code...ocode/text/AGA


Doesn't have to be narrower, as @DanScott suggested you can alter diwstart/diwstop in combination with ddfstrt/ddfstop


Wouldn't one multiplexed sprite be enough for the starfield?

ah yes AGA bits. I don't care about them since I'm OCS. Thanks


I can use a multiplexed sprite but I have to set/reset the sprite priority because starfield is below all planes (obviously). A big black bar would have to be above plane 2, below plane 1. Doable if I set BPLCON2 using the copper when writing each star to lower priority of sprites then upper it afterwards.

increasing diwstart by $10 did the trick for the left side. Thanks! going to try the sprite trick now. Learning a lot with this game!

[saimon69]

Original Hardware if i remember had a TOTAL of eight speccy-ish colors (no bright) and three sprite colors - that might come handy for ufos comets and rockets; same hardware was widespreadly used by other games too, included some italian manufacturers that used as base for their own games

[jotd]

There can be more than 25 colors on-screen probably thanks to dynamic palette change too.

Hardware is pretty powerful for the time!

I tried the sprite mask which worked but screwed up stars priority. I tried to switch bplcon2 in the copperlist dynamically it was a mess...

but what kills it is probably that I'd have to mask all the right part or the scrolled part will appear (or I can also mask using a lot of black sprites, I can use 6 sprites x16 = covered.

My problem with setting diwstop to a narrow value to respect original aspect is that in my previous games I used the upper right part for scores. Now I can't do that.



I could do that with the black sprites trick, but I fail to dynamically change sprite priority so stars are behind planes, and black hiding sprites are above planes...

Not as easy as it seems on the miggy to create a smooth scrolling game with only a part of the screen & a side status bar...

Apart from the score, the game looks good already. Maybe I can cram the score just above the fuel status. It's always filled with ground on the other playfield and probably wouldn't hide or conflict with anything.

[ross]

And if you overscan a bit to fit the score vertically?
(a single text line instead of 2 might suffice)

[jotd]

Good idea ross. I ended up creating a kind of "OSD" (using main non scrolling playfield). Ship cannot venture there. There are always at least 3 layers of tiles. Doesn't look that bad.



(I'm pretty sure original hardware would have a hard time replicating that lol )

[morbid]

Great that you found a solution!

Just for completeness:
- Couldn't you have used sprite 6 for the starfield and sprites 0-5 for the mask,
and then set up bplcon2 just once to 0x1b?

- Another option might be to put the mask into the static playfield and then change the playfield priority on every line?

[jotd]

Originally Posted by morbid

Great that you found a solution!

Just for completeness:
- Couldn't you have used sprite 6 for the starfield and sprites 0-5 for the mask,
and then set up bplcon2 just once to 0x1b?

- Another option might be to put the mask into the static playfield and then change the playfield priority on every line?

You mean setting to 0x1B makes sprite 6 with low priority vs both playfields but other sprites are still high priority? Yeah, that would definitely work!

(the HRM is not very clear about that)

- Another option might be to put the mask into the static playfield and then change the playfield priority on every line?

I tried this and it's pretty tedious with the waits and all it ends up working on some lines but not others, etc... If first option works, I'll do that so I can put the score on the right like I planned to.