On Thu, 8 Feb 2001, Christoph Egger wrote:
> > 1) A pointer to a "sprite family" db struct; that is, the db
> > struct would be able to be shared between more than one
> > sprite. Since it is shared, the "read" and "write" members
> > of the db struct itself would be invalid, so you need:
>
> Do you mean with "db" "database" or "directbuffer"? Sorry, but I am
> not sure yet.
Directbuffer.
> 1. "FT" stands here for Framebuffer-Type, right?
"feature type". But you shouldn't feel obliged to keep that.
That's just the way it was in the proposal.
> 2. Can these "features" really handled by LibOVL?
> I am not sure, if this is the case.
> For example, the texture-stuff - isn't that something that
> belongs to libblit?
The GGI_FT* stuff was for a layer that would end up being below
LibBSE, the same way LibBSE is below LibOVL and Libblit. It would
end up something like this, but I'm making up some of these library
names on the fly:
LibGGI
LibGAlloc - Feature Negotation/Allocation API
LibBSE
LibOVL
LibSprite
LibVideoPort - YUV port, VGA feature connector,
TV capture, etc.
LibBlit
LibMISC - Splitline, frame-flip-on-sync, etc.
Lib3DMem - 3D textures, AGP, Z-buffer, etc.
For now, LibBSE would handle everything it could itself, but when
the time comes that other features not handled by BSE are implemented,
libBSE, LibGAlloc would be written and LibBSE would switch to
making calls to LibGAlloc to find the resources it needs.
The general idea is that the higher levels are simpler to code with,
while the lower levels are capable of squeezing more resources out of the
hardware, but they do not contain any code to actually use the resource,
they just know how to allocate the resource. The primary function in
LibGAlloc would be a supercharged version of setmode/checkmode that
allows you to ask for a prioritized list of features along with the video
mode.
> 3. Can anyone explain me, what GGI_FT_PASSTHRU is intended to be and
> should allow?
Video overlay, e.g. from a TV capture card.
> 4. These #defines are all bitwise. So, it is possible to combine and
> use them at once?
Yes. So say you want to allocate enough system RAM to hold data
for a hardware cursor offboard, you would use:
GGI_FT_SPRITE | GGI_FT_MEMVIS | GGI_FT_SPRITE_POINTER
Of course, some things don't make sense. You probably won't
see too many multi-layer character font cells with a Z-buffer :-)
> > ...and then the "BSE" specific stuff:
> >
> > /* Subtypes for sprite features */
> > #define GGI_FT_SPRITE_DONTCARE 0x00000000
>
> What does this mean?
It means when you ask for a sprite, you don't care whether it is
any particular kind of sprite. That #define is a bit superfluous,
I admit.
Another example -- you want an access to the actual sprite buffer,
and you do not care whether the sprite is a hardware cursor or
a real sprite, you'd use:
GGI_FT_SPRITE | GGI_FT_SPRITE_DONTCARE
> > #define GGI_FT_SPRITE_POINTER 0x00000001 /* Hardware pointer cursor */
> This is the mouse/trackball/joystick, right?
Yes...
Most SVGA cards implement a single, stripped down sprite for a mouse
pointer. A few actually have a second one for a text cursor (and in
VGA text mode the hardware cursor can be considered a sprite). These
sprites tend to have very minimal features compared to "real" sprites --
like they usually only have four colors, they can't have a priority
relative to other sprites, and they don't have very many available
raster OPs. However, they can sometimes have features which
"normal sprites" (if there even are any) do not have that make them more
useful for the specialised job of being mouse cursors than a
"normal sprite" is.
> > /* Attributes common to sprites, BLTs, and video overlays. */
> > struct ggi_sprite_attrib {
> > int active; /* if in active slot, is it on or off. */
> > ggi_coord res_mul; /* pixel scaling numerator ( < 0 is flipped) */
> > ggi_coord res_div; /* pixel scaling denominator ( < 0 is flipped) */
> > ggi_coord pos; /* position on screen (units 1/res_div pixels) */
> > ggi_coord pos_offset; /* hot spot offset (units 1/res_div pixels) */
> > ggi_coord pos_snap; /* grid for position (units 1/res_div pixels) */
> > ggi_coord size_snap; /* grid for sizing (units 1/res_div pixels) */
> > uint priority; /* priority (depth) relative to other sprites */
> > } ggi_sprite_attrib;
> >
> > /* Attributes common to sprites/BLTs */
> > struct ggi_rops_attrib {
> > uint rops; /* Mask of available raster ops. */
> > ggi_visual_t palown; /* If non-null, non-inverse/transparent
> > pallette entries are shared with this visual */
> > ggi_pixel rop_cmp; /* Value for ROP compare */
> > ggi_pixel rop_mask; /* Dontcare bitmask for ROP */
> > ggi_pixel trans_cmp; /* Value for transparency */
> > ggi_pixel trans_mask; /* Dontcare bitmask for transparency */
> > }
>
> Where does these structs belongs to? LibOVL? LibBlit? LibBSE?
Wherever they fit... these are just old notes from an old proposal,
so cram them in wherever they seem to belong, and feel free to simplify
them. It is important that the LibOVL and Libblit interfaces are
"user friendly". It's OK if we have to have more than one layer of
structure with different detail-to-simplicity ratios.
When I wrote those structures, I was trying to group the members
in a way that there wouldn't be too many members in a structure
that a certain type of feature wasn't going to use, but also so that
there wouldn't have to be a structure for every single attribute a
feature could possess. You may figure out a better way to group them.
--
Brian
