Index: [thread] [date] [subject] [author]
  From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Tue, 9 Mar 1999 19:03:38 -0500 (EST)

Re: Sprites in video memory

On 8 Mar 1999, Jason McMullan wrote:
>    Here's an idea - make the visuals _smaller_.

I think this idea might be workable.  The only thing it has
going against it is another level of indirection
in the calls to the drawing operations.  That is, in the stubs.c
function we'd have instead of:

int _ggiDrawPixelNC(ggi_visual *vis,int x,int y)
{ return vis->opdraw->drawpixel_nc(vis,x,y); }

... something like this:

int _ggiDrawPixelNC(ggi_visual *vis,int x,int y)
{ return vis->class->opdraw->drawpixel_nc(vis,x,y); }

The visual structure would be something like:

typedef struct ggi_visual {
        unsigned int       version;
        void              *mutex;       /* Lock when changing.. */
        struct ggi_visual *next;        /* Next one in the list... */
	struct ggi_visclass *class;     /* The class handling 
					   all these visuals */
	void              *instance;     /* instance private data,
					    e.g. address of sprite */
}

We'd lose binary compatibility but since the visual has been wisely
tucked in the internal/ header directory, source compatibility
would be the same.  But that would involve a good deal of rewriting.

Like Andy said, if we have a temporary extension with it's own API
e.g. ggiThingyDrawPixel(*vis, *thingy, int x, int y) we'd have a better time
integrating it into the regular API.

If anyone can point me to any docs on how extensions work, I
can step through the process and try to write an extension HOWTO.

P.S. We might be able to make the extra indirection do double duty 
as a sanity check if we are clever.

P.P.S. I'm confused as to what the criterion being used to decide
if something goes in the visual or in the GC might be ... why are
the gamma correction values in the visual, for example?

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

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