View Single Post
Old 23 November 2015, 09:56   #63
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 434
Originally Posted by keithbugeja View Post
Thanks for your clarifications. How would this work for large maps? If, say, I keep moving screen memory to the right, would I not eventually reach the boundaries of allocated memory, independent of representation?
This is harder to explain in words than showing with a bit of thick string/rope and a tin can.

Yes, if you just keep adding +2 to your bitmap address you will eventually worm your way through all memory. Not good.
If your level has a fixed width and does not wrap around then you only need to add "level pixel width times number of bitplanes" to your screen memory allocation. If your level is 2560 pixels wide in 4 bitplanes then that is just 640 bytes extra.
If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.

(The pysical thing about the tin can is to take the string and begin wrapping it around the can from top to bottom, but as I said(wrote) you kinda need to do it in person to use it to explain sliding screenbuffers.)
NorthWay is offline  
Page generated in 0.03935 seconds with 10 queries