On Wed, 28 Feb 2001, Brian S. Julin wrote:
[snip]
> If you do something stupid like request a sprite with
> GGI_AUTO,GGI_AUTO resolution and your target happens to do full
> screen sprites and it eats all your VRAM and you don't check to
> see that and de/realloc it with a lower resolution, well that's
> your own fault.
That's why I say: "When the user does crap, then s/he gets crap!" :)
> > My example can handle with this case. But I want to archieve that
> > WITHOUT threads. I suppose, you are too low-level, and I am too
> > high-level. We have to find the golden middle way... :)
> >
> > Any suggestions for this?
>
> I'm still not really compreheding where threads come into this at
> all.
Well, all what I have seen in every GGI-lib are basically three
functions to allocate, check and deallocate any resources. Try to
realize your example below by using just this three functions. You
will see, that this can't be done without threads.
Now, I see which way you go. I think, that this is the way we have to
go.
> The "Low level API" doesn't look that bad once you massage it
> with convenience functions, and my examples assume you are using
> it for something that is actually difficult to do. If you were
> using it for simpler things it could look like this:
>
> ggiGAresource_t mymode, mynewmode;
>
> ggiGAEmptyResource(&mymode);
> ggiGAAddSimpleMode(mymode, 640,480,2 /*frames*/, GT_AUTO);
> ggiBSEAddSimpleSprite(mymode, 30, 60, GT_AUTO);
> ggiBLTAddSimple2dTexture(mymode, 100, 100, GT_AUTO);
> if (ggiGACheck(vis, mymode) == NULL) {
> fprintf(stderr,"I won't run without my crap. Waaah.\n");
> ggiExit();
> }
> if ((mynewmode = ggiGASet(vis, mymode)) == NULL) {
> fprintf(stderr,"Someone screwed the pooch.\n");
> ggiExit();
> }
> sprite = ggiBSETieResource(vis, mynewmode, 0);
> texture = ggiBLTTieResource(vis, mynewmode, 0);
> /* Wow, that was relatively painless */
>
> /* Get a bigger sprite */
> ggiGAEmptyResource(&mymode);
> ggiGAAppendTiedResources(mymode, mynewmode);
> ggiBSEDelSprite(vis, mymode, 0);
> ggiBSEAddSimpleSprite(mymode, 100, 100, GT_AUTO);
> if (ggiGACheck(vis, mymode) == NULL) { /* Sprite was too big */
> fprintf(stderr,"I should have checked this earlier. Doh!\n");
> /* wait until we need the new mode */
> MyCleanUpAndExit();
> }
> /* wait until we need the new mode */
> ggiBSEUntie
> ggiGAset(vis, mymode);
> ggiBSETieSprite(vis, mymode, 0);
>
> Now as for stuff that isn't in GAlloc because it is handled
> entirely by the extension and never conflicts with anything else,
> there is no need for special treatment -- say the above sprite
> was an X pointer handled by libBSE. GAlloc would simply ignore
> the resource, and BSE would know to allocate the object when the
> Tie() function is called.
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.
> 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.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
