View Single Post
Old 22 November 2015, 21:52   #60
Registered User

keithbugeja's Avatar
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
Originally Posted by Havie View Post
I'm interested in this statement. When you say there is no actual scrolling - what do you mean? If you are not using hardware scrolling - how are you creating the movement? Excuse me if I'm missing something obvious.
No, it's more like I wasn't clear enough. Let's say you have a typical side-scrolling shoot 'em up (like R-Type), with right-to-left scrolling; for every block (or tile) worth of horizontal hardware scrolling (say 16 pixels), the whole playfield is copied (blitted) and moved 16 pixels to the left, and a new column of tiles is drawn at the rightmost edge of the screen to fill the empty space.

In Blaze, scrolling doesn't happen this way - instead, the screen is composited from tiles each and every frame. Hardware is still used to control the scrolling at the granularity of pixels, but no 'software' scrolling is used, so to speak. The advantage of this method is that the whole playfield could be animated without any penalty in performance. Moreover, since the screen is basically redrawn at each change, one doesn't need to save the portions of background behind software sprites (bobs). The flip side is that the technique is limited in terms of fill-rate, which is why Blaze runs at around 25 Hz.

In a later project, I had experimented with decoupling the pixel scrolling from the rest of the rendering, and running it at 50 Hz. This resulted in silky-smooth scrolling, but sprite movement became very jittery (Think Superfrog). For the player sprite, solving the jitter was just a question of using hardware sprites, which are independent of the background, but for the other sprites, I had no suitable solution.

Hope this makes it a bit more clear.
keithbugeja is offline  
Page generated in 0.04049 seconds with 10 queries