Re: Bored at work....

[BLuRry <brendan.robert@gmail.com>]

Using page-flipping you might be able to pull off a half-byte scroll by having a 3.5 pixel shift of your sprites (anti-aliased?) in a second table and use page flipping.  Here's an example rough outline of the algorithm:

Draw page 1:
   Generate erase list (tiles that are gone and should be replaced with background)
   Generate update list (tiles that are in motion, all tiles if screen is moved)
   ** A general note, only erase tiles if the background should be there and only redraw tiles if there is not already a tile drawn there.  Case in point: if there is a row of ceiling tiles then you'll never really have to redraw them after they've scrolled into view!  This will limit how much re-work you really have to do when redrawing a screen.  Again, look at Choplifter.  It is usually only redrawing the chopper when nothing else is on-screen.  It's very efficient!
   Generate movement list (player, enemies)
   Process erase list, then update list, then movement list drawing as necessary
   Finally activate page 1.

Draw page 2
   Same as before, except it should use a different set of lists so you can understand what has changed since you last drew screen 2.  The drawing routines and lookup tables will need to accommodate the left/right halves of tiles.
   Finally activate page 2.

Draw page 1... etc.

In essence, you'd only flip pages during screen scrolls.  This would mean that when the screen is not scrolling you would need to keep the redraw very tidy so you can race the gun to update with limited flickering/tearing.  And even then a little is OK (nobody ever said that moon patrol sucked because of it)

If you were making a DHGR game then you could still do whole-byte scrolls, except it is easier to get the 3.5 pixel shift since that's a whole DHGR byte more or less.  You would still need a lot of pre-shifted lookup tables of course.

-B


On Tuesday, August 7, 2012 10:28:52 AM UTC-5, BLuRry wrote:
> I agree that a 1-pixel scroll would be very slow.  I think you would have to accommodate it with a few things to lower the complexity.  After reading the source of Prince of Persia and watching how different games update the screen (alcazar and choplifter are interesting!) you might get some really good cues:
> 
> 1) Only update what needs to be updated, using a table to represent the different blocks on screen.  This is how PoP manages to keep track of gates, torches, etc.  Only redraw something if it is actually moving, so you'll need a routine to build the movement list.  If the whole screen is moving then you add the list of platform/blocks on it.  If the screen is stationary but a block is animating then you might only be drawing that one tile.
> 
> 
> 
> I heavily recommend using MetaCheat heatmap to watch how ChopLifter does it.  I swear Gorlin is a genius!
> 
> 
> 
> 2) Limit the size of the playfield.  You can do this in a way that doesn't negatively affect gameplay as long as you fill the top 1/3 with meaningful content like a nicely detailed scorefield.  Take Moon Patrol for example.  I like how Alcazar does it because only the middle 1/3 of the screen is active most of the time when you're in a castle.  You can use the MetaCheat heatmap to see what areas of HGR are being updated.
> 
> 
> 
> More extreme examples of this are "Way Out" and "Pandora's Box", both of which have very small view portals but because of other game features this doesn't drastically limit gameplay.
> 
> 
> 
> 3) For a scrolling game, limit the complexity of stuff that is always there.  Forget drawing cloud sprites, unless you can have them fixed in place.  Moon Patrol does this by only redrawing the active playfield and uses a solid ground so it doesn't have to redraw it unless it is drawing a pit.  Therefore you might want to consider having a way to represent a pit as a black hole and anything below a certain y-coordinate is always brown in some levels or grey in others unless otherwise specified (so pits would be like tiles that have negative space)
> 
> 
> 
> If you do this, you might actually be able to pull off a really decent platformer with scrolling!  1-pixel scrolling might work but it could also be a little sluggish.
> 
> 
> 
> -B
> 
> 
> 
> On Tuesday, August 7, 2012 1:10:26 AM UTC-5, Antoine Vignau wrote:
> 
> > Hi R.,
> 
> > 
> 
> > 
> 
> > 
> 
> > From the sprites HGR page, I understand you will have a 1-pixel scrolling feature. On one hand, that will be smooth. On the other hand, that will be very slow. I'd rather use a one column (one byte) scrolling for fast animation.
> 
> > 
> 
> > 
> 
> > 
> 
> > Keep up the good work, that is still impressive,
> 
> > 
> 
> > antoine