Index: [thread] [date] [subject] [author]
  From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 05 Mar 1999 00:06:04 +0100

Re: Sprites in video memory

Nicolai Haehnle wrote:
> 
> becka@rz.uni-duesseldorf.de wrote:
> 
> > when he wants a 2-frame setup, while he could do:
> >
> > +---------------+
> > | visible 1     |
> > +---------------+
> > | visible 2     |
> > +---------------+
> > |virt for sprite|
> > +---------------+
> >
> > Right ?
> >
> 
> Yes, you are. The second is exactly what I want (and what you get with DirectDraw
> ;)
> 
> 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.
> It will provide a main object representing a GGI visual (e.g. KGI). You can add
> as many flexible sized surfaces to this main object as you want. They're put
> either into the main visual memory (if there's enough space) or into a memory
> visual.

Don't make anything that sits on top of LibGGI. Make it a LibGGI
extension library instead. We should have an extension for allocating
offscreen videoram for different sort of buffers/pixmaps/caches.

One of the beauties of LibGGI is that you are not limited by it's API.
LibGGI is designed to be small and provide only basic operations,
but it has an extension mechanism which allows you to add functions,
or even modify the behaviour of existing functions, without needing
to build it on top of existing functions.

The "misc" extension in libggi/extensions/misc is a good example of
how extensions can work.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

Index: [thread] [date] [subject] [author]