English Amiga Board General 8-way scrolling: algorithms/etc
 Register Amiga FAQ Rules & Help Members List  /  Moderators List Today's Posts Mark Forums Read

 25 November 2021, 03:17 #2 Retro1234 Boo   Join Date: Jun 2006 Location: 5150 Posts: 4,973 I did it once kind of like this http://eab.abime.net/showthread.php?t=80646 So the screen was twice the height and width with 2 or 3 columns/rows for some buffering if I scrolled down diagonal I noticed I ended up with the screen split into 4 identical screens or something like that but what always bothered me was there must be a perfect mathematical formula that if your visible screen is blah and tiles blah to reach perfect scroll i.e after diagonal scroll such and such it's been ages so can't remember and others probably know better ways but it always bothered me there must be a perfect formula instead of my guess work. Anyway good luck dude.
25 November 2021, 18:02   #3
Registered User

Join Date: Jul 2021
Location: Sandy, UT
Age: 52
Posts: 228
Quote:
 Originally Posted by Retro1234 I did it once kind of like this http://eab.abime.net/showthread.php?t=80646 So the screen was twice the height and width with 2 or 3 columns/rows for some buffering if I scrolled down diagonal I noticed I ended up with the screen split into 4 identical screens or something like that but what always bothered me was there must be a perfect mathematical formula that if your visible screen is blah and tiles blah to reach perfect scroll i.e after diagonal scroll such and such it's been ages so can't remember and others probably know better ways but it always bothered me there must be a perfect formula instead of my guess work. Anyway good luck dude.
Interesting approach. Thank you for your post, Retro1234. But using a larger/taller buffer, it would still be necessary (*using my current code) to correct blocks that are out of place. With a small screen buffer, I can leave the fill columns visible so that while debugging, the problems might appear. Vertical scroll seems to have virtually no issues when combined with horizontal... it's the horizontal that has the issues. So a taller buffer might not help.

...

To have smooth scrolling (in an algorithm similar to mine), you need to re-use fill columns for left vs. right and re-use fill rows for top vs bottom. The "double duty" of the fill columns is why incorrect blocks show up. People can and will switch directions--which switches the context of the fill row into a source row and the fill column into a source column.

So it's almost like you have to keep track of the last x-direction moved--just to correct blocks that are out of place. Testing this, it seems that if you scroll horizontally, then scroll down or up such that you are on a different "map y block", the difference between that block location and the map y block location where you stopped will be the number of rows you need to re-blit into the fill column (for the x-direction you are moving). That is, unless you scroll up or down less than 16 rows. If you scroll up or down more than that, just AND the difference with 15 (since my buffer is 16 rows tall).

This issue doesn't seem to crop up with up/down scroll... the problems always appear on the left or right edge of the screen. I need to test this hypothesis. This will also play into the "saveword" when switching directions left or right... the map y block delta should be used to compensate for the vertical location of the saveword in the buffer.

26 November 2021, 08:44   #4
aros-sg
Registered User

Join Date: Nov 2015
Location: Italy
Posts: 93
Quote:
 Originally Posted by chadderack So it's almost like you have to keep track of the last x-direction moved--just to correct blocks that are out of place. Testing this, it seems that if you scroll horizontally, then scroll down or up such that you are on a different "map y block", the difference between that block location and the map y block location where you stopped will be the number of rows you need to re-blit into the fill column (for the x-direction you are moving). That is, unless you scroll up or down less than 16 rows. If you scroll up or down more than that, just AND the difference with 15 (since my buffer is 16 rows tall).

During X scrolling when you ~"cross over into new" block (like scrolling right from scrollxpos = 15 to scrollxpos = 16, or scrolling from scrollxpos
= 32 to scrollxpos = 31) the Y (!) fill row needs to be"fixed", because it is in the wrong place now.

During Y scrolling when you ~"cross over into new" block (like scrolling right from scrollypos = 15 to scrollypos = 16, or scrolling from scrollypos
= 32 to scrollypos = 31) the X (!) fill colum needs to be"fixed", because it is in the wrong place now.

See this (A), (B), (C) images in xylimited-uk.html in ScrollingTricks. (A) is before scrolling. (B) is after scrolling before the "fix". And (C) is after the scrolling with the "fix" applied.

26 November 2021, 17:18   #5
Registered User

Join Date: Jul 2021
Location: Sandy, UT
Age: 52
Posts: 228
Quote:
 Originally Posted by aros-sg During X scrolling when you ~"cross over into new" block (like scrolling right from scrollxpos = 15 to scrollxpos = 16, or scrolling from scrollxpos = 32 to scrollxpos = 31) the Y (!) fill row needs to be"fixed", because it is in the wrong place now. During Y scrolling when you ~"cross over into new" block (like scrolling right from scrollypos = 15 to scrollypos = 16, or scrolling from scrollypos = 32 to scrollypos = 31) the X (!) fill colum needs to be"fixed", because it is in the wrong place now. See this (A), (B), (C) images in xylimited-uk.html in ScrollingTricks. (A) is before scrolling. (B) is after scrolling before the "fix". And (C) is after the scrolling with the "fix" applied.
Hey aros-sg, thank you! I'll check xylimited-uk.html and see where I'm going wrong. Much appreciated! The approach that I described in my previous post (fixing the fill column) seems to be working... (for right scroll--haven't fixed left scroll) but maybe aros-sg's explanation can make the algorithm even simpler. I'll try it.

 27 November 2021, 01:49 #6 chadderack Registered User   Join Date: Jul 2021 Location: Sandy, UT Age: 52 Posts: 228 aros-sg: Maybe you have a minute to help. Here's my issue. I take the x-step from the x-map position ONLY. In other words, [MAPX POS & \$000F]. Here's a typical example. Let's say I'm at x=356h and y=b2h. The column highlighted in RED is the right fill area--but I'm blitting to the left fill column. The blocks in the red column are blitted blocks shown one step later. Now I want to move down three "tile block heights" (rounded to the nearest block height)... so 3 tile moves down. I end up at Y=E1h. If I don't fix up the fill column, the three blocks shown in yellow will remain on the screen. It's because of the X-step (I believe) Should I be combining the x-step AND y-step ... or should I just add the MAP-Y block to the X-step so that every "step" corresponds to the same visible row on the screen? Currently I have code that figures out how many column tiles to replace--but it is slow. I'm guessing that's the wrong way to go about things. Thank you! Attached Thumbnails
 27 November 2021, 10:30 #7 aros-sg Registered User   Join Date: Nov 2015 Location: Italy Posts: 93 As you scroll around,the visible part of the bitmap moves around in memory (and vertically also wraps around most of the time). And the blit positions for a step are always relative to that current ~view_start_place in memory. Place == multiple of 16 (tile size). So pixel_scroll_position rounded down to tile grid. So if y_scroll_pos_in_pixels is 0 .. 15, a stepx of 0 does not blit to the same address in memory, as a stepx of 0 would if y_scroll_pos_in_pixels was 16 .. 31. In memory they would be 16 lines apart. Everything is always relative to current visible bitmap position/layout (y split/wrap) in memory. So stepx = 0 always blits to the same "virtual" place, but "physical" may be different as subject to position in memory/vertical wrapping of visible bitmap inside memory of bitmap.
27 November 2021, 15:56   #8
Registered User

Join Date: Jul 2021
Location: Sandy, UT
Age: 52
Posts: 228
Quote:
 Originally Posted by aros-sg As you scroll around,the visible part of the bitmap moves around in memory (and vertically also wraps around most of the time). And the blit positions for a step are always relative to that current ~view_start_place in memory. Place == multiple of 16 (tile size). So pixel_scroll_position rounded down to tile grid. So if y_scroll_pos_in_pixels is 0 .. 15, a stepx of 0 does not blit to the same address in memory, as a stepx of 0 would if y_scroll_pos_in_pixels was 16 .. 31. In memory they would be 16 lines apart. Everything is always relative to current visible bitmap position/layout (y split/wrap) in memory. So stepx = 0 always blits to the same "virtual" place, but "physical" may be different as subject to position in memory/vertical wrapping of visible bitmap inside memory of bitmap.
Ah, thank you. This is where I must have gone wrong. I'll have to re-work horizontal scroll to do things this way. Thanks again!

 28 November 2021, 21:50 #9 chadderack Registered User   Join Date: Jul 2021 Location: Sandy, UT Age: 52 Posts: 228 I'm not exactly implementing aros-sg's algorithm the same way he explains. I blit some "overlapping" blocks--sometimes the horizontal scroll blits to the "fill row" and sometimes the vertical scroll blits to the "fill column." For another, I don't set up the buffer the same way as in his source. His source suggests a buffer with an extra tile row for the top and one for the bottom. Both of my rows are at the bottom of the screen buffer--below the visible screen. (Done to make vertical split code simpler). So I find myself checking for horizontal blits where the Y-step is uneven... then increment a counter each time this happens. When switching back to vertical blit--if the counter > 0, I "fix up" the row (if necessary)... if I was blitting up blocks into this row, replace the whole row with down blocks. Too complicated. Even when it "works" I end up with occasional artifacts, and some blocks out of place (every 16th or so). What I want to do is break down the explanation of how to handle the "problem blocks" from xylimited-uk.html. I'm trying to figure out if this is correct: Code: ```FIXING UP THE BUFFER AFTER... RIGHT SCROLL: ------------------ HELPFUL REALIZATION: DOWN BLOCKS WILL BE IN THE FILL ROW (AT BOTTOM--ONLY ROW NOT PARTIALLY SHOWING ON SCREEN) WHEN: ON UNEVEN Y STEP/EVEN X STEP COLUMN BLIT: TOP BLOCK OF RIGHTMOST (NON-FILL) COLUMN WITH NORMAL (UP) BLOCK ROW BLIT (FILL): Y-STEP BLOCK (FROM DOWN SOURCE AS A FILL (DOWN) BLOCK) LEFT SCROLL: ---------------- HELPFUL REALIZATION: DOWN BLOCKS WILL BE IN THE FILL ROW (AT BOTTOM--ONLY ROW NOT PARTIALLY SHOWING ON SCREEN) WHEN: ON UNEVEN Y STEP/EVEN X STEP COLUMN BLIT: TOP BLOCK OF FILL COLUMN WITH FILL (DOWN) BLOCK ROW BLIT (FILL): Y-STEP BLOCK (FROM UP SOURCE AS A NORMAL (UP) BLOCK) DOWN SCROLL: ------------------ HELPFUL REALIZATION: RIGHT BLOCKS WILL BE IN THE FILL COLUMN (AT LEFT--ONLY COLUMN NOT PARTIALLY SHOWING ON SCREEN) WHEN: ON UNEVEN X STEP/EVEN Y STEP ROW BLIT: FIRST BLOCK OF FILL ROW WITH NORMAL (UP) BLOCK (NO PLANE SHIFT) COLUMN BLIT (FILL): X-STEP BLOCK FROM RIGHT SOURCE (PLANE SHIFTED) (IF LAST X-DIRECTION WAS RIGHT) OR LEFT SOURCE (IF LAST X-DIRECTION WAS LEFT) UP SCROLL: ------------- HELPFUL REALIZATION: RIGHT BLOCKS WILL BE IN THE FILL COLUMN (AT LEFT--ONLY COLUMN NOT PARTIALLY SHOWING ON SCREEN) WHEN: ON UNEVEN X STEP/EVEN Y STEP ROW BLIT: X-STEP BLOCK OF FILL ROW WITH NORMAL (UP) BLOCK (NO PLANE SHIFT) COLUMN BLIT (FILL): FIRST BLOCK FROM RIGHT SOURCE (PLANE SHIFTED) (IF LAST X-DIRECTION WAS RIGHT) OR LEFT SOURCE (IF LAST X-DIRECTION WAS LEFT)```

 Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

 Similar Threads Thread Thread Starter Forum Replies Last Post Aladin support.Games 4 12 August 2017 03:02 Gazzer Coders. General 32 13 July 2011 15:04 TikTok Coders. General 2 07 May 2007 19:03 Zetr0 project.Amiga Game Factory 12 15 December 2005 14:53

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories Support     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE         project.AmigaLive     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Amix     support.AmigaOS     support.Other Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Maptapper     project.Sprites     project.WinUAE - Kaillera Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.Amiga File Server     project.CD32 Conversion     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs Misc     Amiga websites reviews     MarketPlace         Swapshop     Kinky Amiga Stuff     Collections     EAB's competition Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS         Coders. Blitz Basic     Coders. Contest         Coders. Entries Creation     Graphics         Graphics. Work In Progress         Graphics. Finished Work         Graphics. Tutorials     Music         Music. Work In Progress         Music. Finished Work         Music. Tutorials

All times are GMT +2. The time now is 18:21.

 -- EAB3 skin ---- EAB2 skin ---- Mobile skin Archive - Top