14 October 2021, 20:09 | #41 |
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
|
15 October 2021, 08:11 | #42 | |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
Quote:
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). |
|
15 October 2021, 12:29 | #43 | |||
Registered User
Join Date: Jul 2021
Location: Sandy, UT
Age: 55
Posts: 230
|
Hi aros-sg. Thank you for your kind response
Quote:
Quote:
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". Quote:
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 Last edited by chadderack; 15 October 2021 at 12:42. |
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
doom multi ? | turrican3 | support.Games | 2 | 16 August 2019 08:22 |
OCS/ECS Playfields - blitting objects using colours 16-31? | Marle | Coders. Blitz Basic | 6 | 03 October 2018 19:19 |
Multi-quoting | Graham Humphrey | project.EAB | 38 | 21 August 2010 22:19 |
Multi Zocker | mai | HOL data problems | 0 | 04 December 2009 11:08 |
Multi-Assign | Shoonay | support.Apps | 17 | 12 April 2005 15:16 |
|
|