Chapter 19 - April 12th, 2015
The Tile Scroller
The time has finally arrived when we build the new tile based scroller!
This will be the second take on the one byte hardware scroll originally created back in chapter 11. Back then, I created a vector based terrain routine which performed quite well and had reasonably low overhead but this method created a terrain that lacked variation. I could change the color of the terrain but the overall texture was much the same throughout all levels.
Looking at the scrolling games produced on the Commodore Amiga changed my perspective and I set my sights to mimic that look on the Color Computer 3. For this, I needed to replace the vector based terrain routine for a tile based terrain routine. This would be more demanding of the CPU but the boost in graphic detail that was possible with a tile based terrain system excited me and I was willing to do my best to make it work.
I began creating the new tile based landscape scroller based on my description of the one byte scrolling back in chapter 9 but there was a problem. Not a technical problem but a gameplay problem.
The landscape scrolled from right to left very smoothly but too fast for what I wanted in this game. I had allocated 8K for the landscape map encoding and this I calculated would encode at least 80 screens worth of landscape. My scroller was scrolling the landscape at 1 byte width (2 pixels) every game frame. At that rate, my player's plane character would transverse all 80 screens in just a few minutes. That was not only too short but my player's propeller plane would seem more like a jet aircraft zooming over the landscape!
Anyone who has played Jeremy Spiller's Color Computer 3 game Crystal City will recall the frantic pace that his aircraft flew over the landscape. He used the standard 2 byte horizontal scroll and was so fast that the player has very little time to take in the detailed scenery as it whizzed past.
The 1 byte scrolling technique I was using slowed that down, scrolling 1 byte width every game frame but it was still too fast so I began thinking of scrolling 1 byte width every 2 game frames. I wondered if dropping to this rate would break the smoothness of the scroll. Only one way to find out so I set out changing my code to accomodate this.
The scrolling was at the perfect speed and while not as glass smooth as before, it was still quite smooth. As a bonus, by distributing the scroll code's workload over 2 frames, the resultant CPU overhead was reduced. Using my in game CPU benchmark as described in chapter 9, I found that I was running at a CPU load equal-and-slightly-less than my original vector based scroll routine!
You can see in the screenshots above that even with a few basic tiles that I defined to get the scroller operating, it looks far better than the vector system prior. I have space to define up to 60 tiles so this will give me ample variance in the changing look of the landscape as it scrolls by.
Copyright 2013 by Nickolas Marentes