23 October 2015, 20:18 | #1 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,656
|
Horizontal vs vertical scrolling
I was wondering what it's "easier" to do for the Amiga, a horizontal or a vertical smooth scrolling? What would consume the least computer power? Which one would be easier to code?
Let's assume I have 2 or 3 layers of parallax, too. |
23 October 2015, 23:47 | #2 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 853
|
Vertical.
Does not eat sprite cycles. You can wrap the screen leisurely at the end of any line you want. If you restrict your parallax to full bitplanes then you don't have to worry about having to blit them around to shift differently from the other bitplanes. (I think Banshee used 1 or 2 bitplanes for some weather effects.) |
23 October 2015, 23:58 | #3 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,656
|
Thanks for that info. For some reason I thought the AMiga was wired for doing super easy horizontal scrolling!
|
24 October 2015, 01:58 | #4 | ||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Being able to display the same landscape several times on the same screen is nice but this is so rarely needed or used that this is not a practical advantage, just a theoretical one. If you limit yourself to the lowest common set of features, then the cost is the same. If you consider parallax a necessity then horizontal wins hands down. It makes it a bit harder to compute the copperlist and blits but much less so than for vertical. Quote:
Parallax is easy for horizontal, quite hard for vertical. Wrapping is easy for vertical, quite hard for horizontal. Choose your way, choose your pain. Last edited by ReadOnlyCat; 24 October 2015 at 02:07. Reason: Added Akira quote. |
||
24 October 2015, 02:09 | #5 | |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
Quote:
Vertical scrolling means you often need double the height of the screen or have to use a split, which then complicates drawing objects onto it because they have to be drawn in pieces. |
|
24 October 2015, 02:30 | #6 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
I never gave a deep thought to pure horizontal scrolling because for some reason I am more interested in 8 ways but just having to point the "exhausted" pointer to the top of the memory after one full screen scrolled is indeed really simple and cheap. Thanks for enlightening this kitten too! |
|
24 October 2015, 03:30 | #7 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,656
|
I actually am interested in making something that would scroll horizontally so this is good to hear.
Thanks, guys! I need to learn so much more though. |
24 October 2015, 05:59 | #8 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Also I realize now that I completely miscalculated the bitplane pointer update for his technique: there is no need to reset any "exhausted" pointer at all because there is no "exhaustion": only 800 additional bytes are needed for the last bitplane while the others simply recycle existing bytes. Silly kitty. This said, if you wanted to scroll say 400 screens, then instead of allocating 400x40 bytes you could simply allocate one additional bitplane (256x40) and do the reset of the exhausted pointer I suggested. This will require reordering bob data in memory though but only if you want to keep factorizing blits. (*) note that blitting several planes requires that the planes to blit are separated by the same number (can be zero) of non blit planes (quite hard to picture I must admit) which can require an even number of planes. A bonus of the additional bitplane allocation suggested in the third paragraph is that it can transform an odd number of bitplanes into an even one and thus allow more viable combinations of bitplanes to blit. Last edited by ReadOnlyCat; 24 October 2015 at 06:39. Reason: Added a paragraph. Added precision about blits. |
|
24 October 2015, 09:11 | #9 |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,187
|
400 screens x 40 bytes is still only 16kb. It may well be worth losing that memory for the simplification you get using this method.
|
24 October 2015, 13:35 | #10 |
Registered User
Join Date: Sep 2009
Location: Norway
Posts: 1,715
|
Yeah we get it! You're probably one of those furries. In a lot of your posts, you mention things like "you humans" and other indications, is it really necessary? It's just absurdly weird to read things like that in rather serious posts about Amigas... It would be more understandable if it was in a furry community or something.
|
24 October 2015, 14:45 | #11 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
So what... you're just a bit young and intolerant to people who you perceive as different. It'll get better eventually
|
24 October 2015, 15:04 | #12 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Also your picture is offensive, makes me hungry and is absurdly weird in a rather serious community about the Amiga. (I am joking, I find it really fun and cute.) But hey, back to scrolling! |
|
24 October 2015, 15:29 | #13 |
Registered User
Join Date: Sep 2009
Location: Norway
Posts: 1,715
|
Why do I even argue with a cat, I should've known. But yeah, back on-topic. :P
EDIT: I'm sorry, I just realized how unnecessary it was of me to pick on you in the first place. Leffmann is right... Last edited by 8bitbubsy; 24 October 2015 at 17:56. |
24 October 2015, 18:00 | #14 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,656
|
Quote:
Let's get back to topic |
|
24 October 2015, 21:45 | #15 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 853
|
/topic
Unfortunately the Amiga can't wrap the display address halfway through a line; looking at how the hw is implemented that would have been a no-brainer if they had thought of it or deemed it interesting. With AGA you can play games with re-setting the (low 16-bit) address pointers when you use 4x FMODE as you get more time between fetches to make it wrap midline. I'm toying with that for a Gauntlet thing I put time into at random intervals. (I do have my logic off by one line for some reason I can't wrap my head around though, but the effect of seeing your bitmap starting from the beginning again when you get midway through the screen is so cool. IMO!) |
25 October 2015, 02:34 | #16 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,656
|
What is this effect you describe? Can you illustrate with an example?
|
25 October 2015, 05:22 | #17 |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Northway is referring to the update of bitplane pointers in the middle of a scan line as discussed in this thread: http://eab.abime.net/showthread.php?t=79776.
On AGA it is possible to update all bitplane pointers with the copper between subsequent bitplane DMA fetches when in 4x mode, so if one resets the pointers to the value they had at the beginning of the line then the rest of the line displays the beginning again, thus wrapping horizontally. On ECS, this is doable but with two bitplanes only. Above that, updating the bitplane pointers will not happen fast enough before the data is fetched again and there will be some graphical glitches. It is a pretty cool technique and that thread is definitely worth a read for whoever likes Amiga hardware details. |
25 October 2015, 05:51 | #18 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 853
|
Think "Defender". (This is only about horizontal scrolling.)
That world just goes round and round horizontally. What do you do when you are at the rightmost end of it and want to scroll further to show what is on the far left side? You can't just keep increasing the bitplane pointers as you will show the left hand side one line higher than it should be. So you build a scrolling engine to dynamically update the screen. Nothing wrong with that. You _will_ require at least two buffers (one to look at and one to build so you can switch to it), two more if you double-buffer, and one more if you want an untouched repair buffer. If possible you could of course just make the game world wider and paste a whole screenful of pixels at the right hand side of the bitmap so it seems like you are wrapping around to the beginning and then jump to the left again when you have scrolled so far that you see all the pasted-in pixels. If you change parts of your world then that gets tricky as both the true and faked parts must be updated. Scrolling the other way is ofc the same problem again so you need to apply the same solutions in reverse. If your world has a beginning and an end (be it horizontally or vertically) it is so much simpler. You just stop scrolling when you reach an end. The number of buffers needed are just one/two/three (single/double/repair) and not so much memory. --- The alternative would be to have some hw support to be able to adjust the bitplane pointers midway through a line. From what Toni Wilen (the go-to man for things really technical) has described the display logic basically does this after every fetch of bitplane data: Have we reached DDFSTOP? -Yes: Add modulos -No: Add 2 (or 4 or 8 depending on FMODE) If we could turn back the clock (hey, it is Back To The Future time after all! Oh, and Wintertime - I just turned back the clock for reals) then we could add a DDFCHNG register and two CHANGE1 and CHANGE2 registers that are basically identical to the modulo registers. You would then have the logic go Have we reached DDFSTOP? -Yes: Add modulos -No: Have we reached DDFCHNG? - - No: Add 2 (or 4 or 8 depending on FMODE) - - Yes: Add CHANGEs That would give you hw support to let the display show the end of the game world and then start drawing it correctly from the beginning again without any complex checks and updates. You would of course have to clip blits against the wrap, but that should be worth it and possibly something you need anyway. The memory needed for this would be static, and you now only need one buffer for single-buffer and two/three for double/repair. This annoyed me no end. After some Deep Thoughts and learning a bit about AGA I realized that with 4x FMODE you have 6 copper instructions between each memory fetch (if using 8 bitplanes). That is enough time to update the low 16 bits of the bitplane pointers for 6 bitplanes. If you organize the memory layout so that the upper 16 bits of a bitplane pointer will always be static then you get a clean change of bitplane display midway through the line as it is being drawn. You use the copper to do that for every line of the bitmap. IIRC the first horizontal copper cycles available after fetch are (decimal) 27, 43, 59, 75, 91. Probably shift left once. I have just tested it with 4 dual-playfield bitplanes (the other 4 I'm not scrolling anyway). And as I said, this Just Works for vertical scrolling as you have all the time in the world to have the copper do a single update of all the bitplane pointers per frame. (I was going to have it easy with the Gauntlet levels I were testing until I realized that the map was not a multiple of 64 pixels and so I have to build a full scroll engine as 528 pixels doesn't fit 4x FMODE well.) |
25 October 2015, 17:23 | #19 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
Quote:
Code:
---2-3-1 ---2-3-1 --C-2-C- 3-C-1--- Unfortunately it looks like 4 planes is possible by using similar interleaving but you'll hit hardware limit: write to any DMA pointer 1 cycle before same DMA pointer is used for DMA access: write does nothing.. |
|
25 October 2015, 22:20 | #20 | ||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Quote:
Does the write really do nothing or is the written value only available after the DMA fetch? If that's the latter then there is still hope. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Horizontal Blanking | sandruzzo | Coders. General | 18 | 17 January 2012 09:27 |
Rambo alike game (shooter horizontal+vertical) | speciesxx | Retrogaming General Discussion | 12 | 27 October 2010 17:59 |
[Found: Insanity Fight] Vertical Scrolling Shootemup | capehorn | Looking for a game name ? | 5 | 13 March 2009 08:18 |
Vertical scrolling motorcycle game.. Anyone? | Thrash75 | Looking for a game name ? | 11 | 18 May 2005 19:44 |
Watchtower - jumpy horizontal scrolling | Tim Janssen | support.Games | 0 | 14 December 2004 22:16 |
|
|