multi-directional playfields

[chadderack]

Originally Posted by DanScott

Perhaps create a new thread for your development (rather than post in 2 seperate existing threads ?)

I can do that. Was just hoping to add to the conversation about an 8-way scroll. Thanks Dan.

[aros-sg]

Originally Posted by chadderack

In terms of the responsibilities of the scroll code (up/down/left/right), each direction will fill one of the four red areas... the left and right scroll will fill the
right and left columns (respectively--the right scroll blits one planeline down) and the up and down will blit to the bottom and top fill rows.

In ScrollingTrick there is only one fill column used for both left and right scrolling and only one fill row used for both up and down scrolling.

If you think of right scrolling as the normal scroll direction, you can think of left scrolling as UNDO of what happened during right scrolling. Same for down scrolling <-> up scrolling.

(scrollpositioninpixels % TILESIZE) basically tells the ~percentage of the fill column/row which needs to consist of NEW tiles, and the rest needs to consist of OLD tiles. NEW tiles = tiles from 1 screen on the right (horizontal screen) or 1 screen on the bottom (vertical scrolling). OLD tiles = tiles from "current" screen.

If you have a visbile screen size of 320 pixels, then most of the time 21 tiles will be visible (the first and the last only partially), not just 20. So with 352 pixel bitmap size there is only one invisible tile (to hide stuff you need to do during scrolling).

[chadderack]

Hi aros-sg. Thank you for your kind response

Originally Posted by aros-sg

In ScrollingTrick there is only one fill column used for both left and right scrolling and only one fill row used for both up and down scrolling.

Yes I'm doing the "limited" version with the limited screen buffer, bringing in blocks from a bitmap source in memory.

If you think of right scrolling as the normal scroll direction, you can think of left scrolling as UNDO of what happened during right scrolling. Same for down scrolling <-> up scrolling.

(scrollpositioninpixels % TILESIZE) basically tells the ~percentage of the fill column/row which needs to consist of NEW tiles, and the rest needs to consist of OLD tiles. NEW tiles = tiles from 1 screen on the right (horizontal screen) or 1 screen on the bottom (vertical scrolling). OLD tiles = tiles from "current" screen.

If you have a visbile screen size of 320 pixels, then most of the time 21 tiles will be visible (the first and the last only partially), not just 20.

Essentially that's what's happening in my code. I just tend to think of the problem as "blit above" when scrolling down, "blit below" when scrollling up (in the opposite direction)--even though the blocks end up in the same location. It seems to do as you are saying with (scrollpositioninpixels % TILESIZE) where (for example) on step 1, it blits to the first block of the fill column--whether going in a positive direction (right/down) or in the reverse.

I've left the "hide column" and "hide row" exposed during debugging and can see (when single-stepping using WinUAE debug) each tile blitted. Downward shows blocks one at a time going left to right. Upward blits in the opposite direction right to left. It does look like "undo".

So with 352 pixel bitmap size there is only one invisible tile (to hide stuff you need to do during scrolling).

I guess that simplifies the problem... because you can't scroll in opposite directions at the same time.

If you are only blitting 21 columns scrolling down, at least one of the columns (to the left or right of the 320 pixels in the middle) will not get filled. If you suddenly scroll in the direction where you haven't blitted (to the left or right) the block won't be there. Potentially, 22 columns should be updated during a vertical scroll.

Maybe there is a similar problem scrollling horizontally. Just blitting 16 vertical tiles (in 16 steps) leaves you with unfilled top and bottom rows if you suddenly scroll vertically. 17 doesn't cover it either. 18 seems to work. There could be "update blocks" that overlap when using that logic (these are A/B/C/D?). Was it phx (in Solid Gold) who uses a linked list of which tiles are "dirty" and should be replaced? That way, a block isn't blitted more than once.

So, I can keep track (for each frame) whether or not one of the "overlap" blocks was blitted... so that it doesn't get blitted twice. I think there's a max of two blocks (per scroll) that this might happen to.

Unless I misunderstand -- or am making this too complicated

[chadderack]

I've got this working now 100%. Video.