From: "Chris A. Triebel" <cat AT sun4 DOT iol DOT unh DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Tile based scrolling?
Date: Fri, 17 Jan 1997 08:50:07 -0500
Organization: University of New Hampshire  -  Durham, NH
Lines: 49
Message-ID: <Pine.SUN.3.91.970117084152.17956E-100000@sun4.iol.unh.edu>
References: <5bjnrh$bu2 AT dailyplanet DOT wam DOT umd DOT edu> <01bc0405$868f0a00$20d6b5cf AT default>
NNTP-Posting-Host: sun4.iol.unh.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
In-Reply-To: <01bc0405$868f0a00$20d6b5cf@default> 
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On 16 Jan 1997, fayda wrote:

> Date: 16 JAN 1997 23:30:17 GMT 
> From: fayda <iii AT io DOT com>
> Newgroups: comp.os.msdos.djgpp
> Subject: Re: Tile based scrolling? 
> 
> 
> 
> James Jeffrey Benjamin <jamesb AT wam DOT umd DOT edu> wrote in article
> <5bjnrh$bu2 AT dailyplanet DOT wam DOT umd DOT edu>...
> > I'm slowly working on a tile based engine using Allegro (mainly for
> > 640x480) and it has become prone to bugs. Anyway, what I'm doing is
> double
> > buffer with blitting (moving) the virtual screen around as I add new rows
> > of sprites. Is this faster or slower with the conventional way of just
> > rewriting every (compiled) sprite onto the screen buffer? I know my way
> > will get quite complex when I introduce parallex srolling. Sprite by
> > sprite is easier, but is it faster?
> 
> One of the main reasons for double buffering is to reduce the "flicker"
> effect you get when you write directly to the screen. There are other ways
> of doing it, but double buffering is Usually the preferred method. If your
> program is very speed intensive, I would suggest dumping Allegro and write
> the code yourself.
> 

I once got around the slowdown of double buffering by only blitting the 
regions that have been changed from the buffer.  It's like this when an 
object is drawn ( after it has moved or changed its image in some way )
it logs the region that it affected ( including the region that it 
restored from the last redraw ) with some function capable of keeping 
track.  I used classes when I originally wrote it, so the class had a 
member that essentially said { if (changed && drawn) 
restore(mycoords...,myoldcoords...); };.

This was much faster than restoring the whole screen on every pass.  And 
it took care of the flicker.  Note that the restore function should be 
smart enough to determine several cases that can happen and derive the 
best restore tatic.
	1) Object really hasn't moved, so just restore one of the areas.
	2) Object overlaps old position so calculate an appropriate block that
	   encompasses both areas.
	3) Object is completely seperate from the old position so restore both
	   areas seperately.

Just my two sense.  Hope it helped.

cat