From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Mon, 8 Mar 1999 00:36:35 +0100 (MET)

Re: Sprites in video memory

> The sub-target is a nice thing, but as Brian said the visual structure 
> is bulky

If you want to use standard LibGGI functiosn on it, you need at least _one_
visual associated to it. IMHO you should only use one, maybe two, if you
have to split between vidmem and memvisual for those.

Then bulky becomes relative.

> and, which is more important, the application programmer must decide where to
> locate the sub-target.The best solution for all this would be to make the
> appropriate targets aware of all this, 

NO. PERIOD.

There is no reason to make targets aware of something that can be done in an
extension.

Targets are kept small and simple for a reason.

> but this requires heavy changes in the API.

Yes. Exactly what we do NOT need right now. You know, that we have a BETA
out, don't you ?

> What I will do for now is to write a library that allocates drawmaps for the
> programmer, as I've already described in an earlier posting. It won't be a libGGI
> extension because it acts as a container for several visuals.

That is EXACTLY the purpose of an extension.

LibGGI extensions are "added value packs", that can be generic to some
extent, as well as go down to the metal of the individual visual.

Please have a look at the "misc" extension, which shows how to do it.

I do not want to bloat the basic API with sprite functionality. 

Heck, we even moved splitline out, why should sprites make it in ?

CU, ANdy

P.S.: Sorry for the shouting, and that I sound annoyed. This thread is going
on for quite a while now, without any code being produced, and without
looking into the mechanisms that are designed to do that.

Please go on with your library, but have a look at the extension mechanism.
It might help you greatly, and the library will fit more smoothly with the
rest of GGI.

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =