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.
> > 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.
> 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.
> > > 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.
> And what could it be else?
Nowadays there are video capture cards that transfer the video
data over the system bus or through an S-Video cable,
instead of through a "feature connector". You mentioned something
I had not heard of, YUV viewports, so you tell me what else :-).
> Should GGI_FT_MEMVIS force to use system RAM or does it say "Fall
> back to system RAM if not enough VRAM is available" ?
It forces use of system RAM. It's for those times when you want to
create values to load into a feature using API functions from some
higher level library, so you can flush them later into the
"real live" feature, but you don't know or care how much data the
feature state uses.
"Fail back to system RAM" would be default behavior meant for
libraries on the LibBSE level to implement; LibGAlloc would not
be spongy at all.
--
Brian
