From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Thu, 4 Mar 1999 16:10:40 -0500 (EST)

Re: Sprites in video memory

On Thu, 4 Mar 1999, Nicolai Haehnle wrote:
> Yes, you are. The second is exactly what I want 
> (and what you get with DirectDraw ;)

As I just got done writing an overview of framebuffers, this reminded me
that the situation with sprites/textures/Z-buffers has still not been resolved
in the libGGI and KGI interfaces.

> As libGGI doesn't have a very comfortable API to do this, 
> I'm thinking about a library set on top of libGGI that handles surfaces 
> like DirectDraw does.

libGGI (or better, libGGI2D) really _should_ have a good API for texture
caches and sprites.  It shouldn't implement its own caching strategy,
since the application may want to micromanage that, but it should give
a texture cache subroutine all the hooks it needs.  I don't know if using 
drawing primitives on sprites/textures in video memory is necessarily good, 
since they sometimes have very funny layouts in video memory and it may be 
better just to draw in main memory and flush the contents, but the option 
should be there at least.

This has been talked about on the list before, and one of the issues that 
came up was that even though it would be nice to have a full visual structure 
with drawing operations for each texture/sprite, that involves a lot of
overhead.  Some sort of "batch visual" to represent several similar visuals
could help this a lot, and is not a very far stretch from what you are
proposing.

On the kernel side, Steffen's code has structures that could be of help
in setting framebuffer layouts right -- but there is a while to go before
you can negotiatiate your mode to maximize your texture cache.  We need
to add API functionality.

P.S. If you have time, could you stop by the Programmers Guide (see my 
post from earlier today), look at the framebuffer layout intro, and send 
me mail about anything that's missing or inaccurate, even just a rough 
outline?

--
P.C.M.C.I.A. stands for "Plastic Connectors May Crack If Adjusted"
                                                             -- me
--
Brian S. Julin