On Fri, 9 Feb 2001, Brian S. Julin wrote:
>
> On Fri, 9 Feb 2001, Christoph Egger wrote:
> > > 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.
>
> > hmm... is libmisc that one, which is already in libggi?
>
> Yes. LibMISC would use LibGAlloc to find out if (or demand that)
> any of the miscellaneous features that it provides an API for are
> available on the target along with the desired video mode.
So it can be used as an example code for the others extensions,
right?
> > > Lib3DMem - 3D textures, AGP, Z-buffer, etc.
> >
> > Does libxmi fit here as well?
>
> Libxmi would use Lib3DMem to allocate it's VRAM, but It's a
> pseudo-wrapper library which is quite a lot more than a "feature
> API implementation"; listing it "under" LibGAlloc didn't really
> do it justice.
Please explain "pseudo-wrapper".
> > Regarding to my question above:
> >
> > Textures - if 2d or 3d - are usually distorted by the (3d) rendering
> > engine. That's why I asked, if the "features" can really be handled
> > by LibOVL. But looking at your sketch, textures and all kind of
> > buffers should be handled by Lib3DMem, no?
>
> Just the part of the process that gets the texture-capable VRAM
> from the target; once the VRAM is allocated, it is handed over to
> a higher level library to actually manipulate it. In the case of
> a 2D application, another kind of "feature" it might want to get
> along with the texture is a "BLT engine", because some cards have
> more than one drawing engine, which would allow the app to use
> multithread access without calling ggiResourceAcquire. I suppose
> the same kind of thing must be true for 3D; Steffen Seeger's KGI
> allows multiple communications channels to be defined to the
> video card, and LibGAlloc would be able to pass these channels to
> the 3d cards "pipelines" to a 3d library.
OK.
To not lose the stuff libOVL should handle, I want to sum up:
It (de)allocates resources for sprites, video overlayers and generic
window overlayers like YUV viewports. Furthermore it displays the
layers _only_ in hardware. Anything else is handled by higher/other
libs.
OK, so far?
If yes, then I think that those "features" makes sense in libOVL:
------------------------------------------------------------
#define GGI_FT_SUBTYPE_MASK 0x00000fff /* defined by extension */
#define GGI_FT_TYPE_MASK 0x000ff000
#define GGI_FT_FRAME 0x00001000 /* frame of main framebuffer */
#define GGI_FT_SWATCH 0x00002000 /* generic drawing area in same
format as the main fb */
#define GGI_FT_STEREO 0x00003000 /* Right/left eye data */
#define GGI_FT_SPRITE 0x00004000 /* Sprite/hw cursors */
#define GGI_FT_VIDEO 0x00005000 /* video */
#define GGI_FT_WINDOW 0x00006000 /* any window */
#define GGI_FT_PASSTHRU 0x00007000 /* e.g. feature connector */
#define GGI_FT_OVERLAY_MASK 0x0ff00000 /* # of hardware "layers" */
/* Subtypes for sprite features */
#define GGI_FT_SPRITE_DONTCARE 0x00000000
#define GGI_FT_SPRITE_POINTER 0x00000001 /* Hardware pointer cursor */
#define GGI_FT_SPRITE_CURSOR 0x00000002 /* Hardware text cursor */
#define GGI_FT_SPRITE_SPRITE 0x00000003 /* True sprite (a-la C-64) */
/* Subtypes for video features */
#define GGI_FT_VIDEO_DONTCARE 0x00000000
/* Subtypes for window features */
#define GGI_FT_WINDOW_DONTCARE 0x00000000
#define GGI_FT_WINDOW_YUV 0x00000020 /* YUV-Viewport */
------------------------------------------------------------
> > > > 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.
> >
> > err... the comment says, it is FOR EXAMPLE a feature connector.
> >
> > A feature connector of what?
>
> What I'm referring to is a 26 pin header or 2x13 edge connector
> on older SVGA cards that used to be used to plug into video
> capture cards and off-board 3d graphics processors like the
> original 3dfx cards. Some of the SVGA cards would just turn off
> the whole screen and let the data from that connector run through
> the CRTC. Others would actually allow you to define a window
> where the data would show through instead of the VRAM data.
But this _not_ the job of LibOVL...
Christoph Egger
E-Mail: [EMAIL PROTECTED]
