On Mon, 26 Feb 2001, Brian S. Julin wrote:
>
> On Tue, 27 Feb 2001, Christoph Egger wrote:
> > > int ggiGallocCheck(ggi_visual_t vis,
> > > struct ResourceProperties *in,
> > > struct ResourceProperties **out);
> > ^^
> > Why double-pointer? Isn't a single pointer enough?
>
> Sorry, I think I was thinking so we can feed in either NULL or *NULL,
> but for the life of me, I don't know why I thought we'd want to
> do that :). Perl induced dementia.
Fixed.
> > > Also, give the "resources" a *next member to hang a linked list
> > > on. This will be needed later when we add functions to negotiate
> > > multiple features and negotiate them against the video mode.
> >
> > I see! That makes it possible to use zbuffer, alpha-buffer and
> > texture-buffer at once.
>
> Right, and the order that the resources appear in the list is the
> order of importance, so suppose you wanted to say this:
>
> "I want to use 640x480 at the highest bit depth I can get, but I
> definitely need a sprite even if it means using a lower bit depth.
> And an off-screen scratch area would be nice, but is not necessary."
>
> You would have a linked list in this order:
>
> (Resource with type RT_SPRITE) -->
> (Resource with type RT_FRAME with the ggi_mode set to 640x480/GT_AUTO) -->
> (Resource with type RT_SWATCH) -->
> NULL
>
> The function that does the work might look ahead in the list for
> example to choose a better VRAM layout, but it would always satisfy
> the requirements of the entries at the top of the list first. You
> can also put more than one RT_FRAME resource in -- this:
>
> (Resource with type RT_SPRITE) -->
> (Resource with type RT_FRAME with the ggi_mode set to 640x480/GT_8BIT) -->
> (Resource with type RT_SWATCH) -->
> (Resource with type RT_FRAME with the ggi_mode set to GGI_AUTO/GT_AUTO) -->
> NULL
>
> Means:
>
> "I absolutely need a sprite, and I need at least 640x480x8, and I want
> a swatch. Better than 8bit colors and more resolution would be nice,
> but I prefer to have the swatch even if it means I only get 640x480x8."
I know, what you want. I have tried to thought this deeply out.
As a result I can say, you can NOT do this WITHOUT having at least
one thread in each (non-)extension like libovl, libblit, libxmi,
libbse, etc. And this would eat everything up, what GGI gains out of
the hardware, except you have a SMP-machine with 4 CPU's or more...
I think, the best way is leave the order of importance to the
application. It knows, what it needs and has to say, what it needs in
the order of importance. When it does crap, then it gets crap. :)
LibGalloc just checks, if the resources are available or not and
allocate them if possible.
> > I moved this into ggiResource_t to have opaque data handling.
> > To have access to multiple resources suggest to add these functions
> > as API:
> >
> > ggiResource_t ggiGallocGetNextResource(ggiResource_t res);
>
> Hmm... I'm not sure I follow -- what does this do? Just dereference
> the next?
Yep. But now I think, that this function isn't needed anymore.
See above.
> > > I'd see three actual internal functions (_ggigalloccheck,
> > > _ggigallocset, _ggigallocget)
_ggigalloccheck is ok, but why _ggigallocset/_ggigallocget?
I thought, that the access to the resources is left to the extensions
as they know about the special format of them.
I thought that libGalloc is intended for (de)allocation of resources,
because of its name...
> at the core of libGalloc, which
> > > would have to be implemented for each target. Implementing
> > > ggiGallocCheck would look like this, using those internal
> > > functions:
> > >
> > > struct ModeProperties {
> > > struct ResourceProperties res;
> > > ggi_mode mode;
> > > };
> >
> > I moved ggi_mode mode into ggiResource as well.
>
> Umm... well I'd be concerned that we'd start bloating really fast this
> way, and every time a feature with special properties that didn't
> fit came along we'd be changing the structure. Really the video
> mode is just another feature.
We won't bloat, if we do as I said above.
> This is a bit of a sticky situation: LibGAlloc is supposed to be a
> core library,
So the right place for it in the CVS would be
libggi/extensions/libgalloc, right?
> but at the same time if we don't do what you are doing (putting
> everything we could possibly need into the properties), for
> certain targets LibGAlloc will require the headers from many of
> the extensions in order to get at the feature-specific properties
> in order to compile, and if those features change APIs then the
> Galloc target sublibs that implement that feature have to change.
> But if we do do what you're doing, then we end up with a big data
> structure that keeps breaking binary compatibility. Plainly we
> cannot just keep accumulating cruft.
I won't go this way for good maintainance, except another one... :)
This way is much better:
> I think I like what you're doing in this sense: the headers that
> define the feature properties that are needed to negotiate the
> feature are part of LibGAlloc, and extensions include the LibGAlloc
> headers. This would make LibGAlloc able to build without the extensions
> present. But rather than change the resource structure all the time,
> maybe we are best off defining a bunch of unions with the common
> properties, which all keep track of their size/type so they can be
> copied blindly. That way when a new "frag" feature that needs a property
> called "fragalisticness" has to be added, you just need to add a header
> in /usr/include/galloc/extensions/frag.h, and modify just the
> LibGAlloc target sublibs that support the "frag" extension to include
> this file, along with the code to help them negotiate the feature on
> their target.
> > > Actually, the "resource" thing will probably be confused with the
> > > ggiResourceAquire() function which is used to grab a directbuffer
> > > away from the accelerator engine. there is already a
> > > ggi_resource_t, which is awfully close to ggiResource_t.
> > >
> > > The RT_* stuff might end up clashing with "Real-Time" support
> > > libraries at some point, but that's not too horribly likely.
> >
> > Hmmm... You are thinking in the same direction as I do. That's why I
> > asked, if it is ok.
> >
> > Has anyone some suggestions for a clean namespace?
>
> I think "caps" (capability) is politically loaded (There's some
> bad association there to DirectX and "capability flags" which seem
> to be unpopular), so we should not use that. That's why I was
> using "Feature" before.
"Feature" might cause misunderstanding by the users.
> "Aspect" has other graphical meanings, so that's out. Maybe we
> should just use "thing" :-P
That's too common.
What about GA as a prefix? Then we would have GA_ResourceType,
GA_ResourceOption, etc...
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
