On Wed, 28 Feb 2001, Christoph Egger wrote:
> But you forget one situation regarding ggiGACheck(): If it fails, how
> do you figure out, _which_ request failed? The user can handle this
> case in a clean way, then. That is much better than just exiting the
> application.
Yes, I did leave that out. I was thinking (badly) that
the return value of the GACheck would be a pointer to
a resource list containing the results. But A) people
throw return values away a lot and that would leak memory
and B) it wouldn't match the other GGI function return codes.
Better:
int ggiGACheck(ggi_visual *vis, *ggiResource_t req, **ggi_Resource_t result);
int ggiGASet(ggi_visual *vis, *ggiResource_t req, **ggi_Resource_t result);
#define GAGet(vis, result) GACheck(vis, NULL, result);
Result has to be double pointer because it points to stuff
alloced inside the function.
> > One thing I would add though is that a lot of the features will
> > sometimes be needed in large quantity, so we should have two
> > quantity feilds in the resource -- the amount absolutely needed,
> > and the maximum amount needed. That or a "SpriteSet" object to
> > request.
>
> We can use a "usage_counter" for each resource and share them as
> well. For example, ggiDoom uses the same kind of enemy again and
> again. ggiDoom requests as much sprites as needed, but internally the
> _image_ of the sprites are shared in VRAM or system RAM buffer.
Ooh... you found a nook I hadn't gotten to... good! I had addressed
this a bit in the "aquel, ese, este" stuff, but not thoroughly and
I didn't describe it very well.
I think the best thing to do here is to make it possible to
ask for either the whole sprite (the hardware sprite circuitry
and the VRAM to go with) or just the VRAM or just the circuitry.
This is similar to the way BSE can provide a memory buffer
for off-board preparation of data for a resource.
BSE should provide for a way to point each instance of the
circuitry at any GAlloc'ed chunk of VRAM. But by default if
you don't ask for anything special, you get one circuit and
one chunk of VRAM to go with it.
In fact, this is handy for BLTS and 3D "hardware pipelines" as
well, because you can have more than one "engine" working
on the same data. So maybe my "aquel, ese, este" stuff was no good,
but it might be the start of a good idea:
Basically a lot of these features have different modes or states they
can be in. They can be stored on disk; they can be in the VM layer so you
don't know whether they are in RAM or in SWAP; they can be in a DMA/AGP
buffer so you know they are in RAM; they can be in the VRAM so you know
they are already on the other side of the bus; and they can not only
be in the VRAM but pointed to by the circuits that make them do whatever
it is they do.
What to do about it... yet more to think about I guess. Just as long
as we stay out of the process of making the decisions when to
move a resource from one state to the next, and let the application
do that, we should retain our sanity, though :).
--
Brian
