View Single Post
Old 22 November 2015, 22:34   #61
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Originally Posted by keithbugeja View Post
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.
Blitting the entire playfield is completely unnecessary... you just shift the start of screen memory one word to the right and keep on going. As long as you have a little extra Chip RAM to move into, the image just wraps round and round. Remember memory is always linear, the 2 dimensions of the screen are an illusion.

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.
This sounds like the technique i suggested for converting NES games, since only 2 bitplanes are required there so it may be able to run at 50 fps.

BTW Mr Beanbag redraws the background behind bobs by refreshing from the tile map, it doesn't save the background behind bobs at all. But it only redraws in rectangular regions, not the whole screen.

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.
if the other sprites can also be updated at 50fps, there is no problem. Although Mr Beanbag does experience this problem, because the hardware scrolling has granularity of 1/4 pixel horizontally, and of course bobs are restricted to full pixel motions, so sometimes enemy sprites that are chasing the player can appear to vibrate slightly. But 1/4 pixel scrolling is not possible on OCS anyway.
Mrs Beanbag is offline  
AdSense AdSense  
Page generated in 0.04026 seconds with 10 queries