On Tue, 18 Sep 2001, Sven Garbade wrote:
> I have played with ggi for some days yet, now I'm wondering about
> rewrite some of our applications with ggi. I currenty use SDL to display
> some simple animations, but the SDLUpdateRects() function doesn't care
> about vertical retrace sync in such an accurate manner I need. I think
> ggi can be the altenative, because libggimisc does exactly what I need
> (and it work for me). The SDL programs work in this way: allocate some
> VRAM surfaces and draw some primitives onto it (e.g. lines, circles,
> load bitmaps etc.), blit them around using SDLs blitting facilities,
> update chaneged areas on screen with the restriction regarding to
> retrace sync.
Do you need a featured Blit (color keying, ROPs) or are you just interested
in copying the data unaltered? If the former, under the LibGGI core,
you can allocate VRAM by setting a mode with a larger virtual area,
then draw off the sides of the screen and use ggiCopyBox to move the
data onto the screen. This is OK for a lot of purposes, but if you
are using backbuffers (called "frames" in GGI) then this can be a bit
annoying to work with because your extra RAM is divided up among your
"frames" and you have to use ggiSetReadFrame, ggiSetWriteFrame appropriately.
If you need alpha or Z, LibBuf should be in full working order soon
(though it may be slow until accelerated drivers are written).
If you need actual ROPs, then you'll have to wait for LibBlt.
> there a way to use video hardwaresurfaces to generate simple animations
> with ggi (and which functions are provided)? Or must every frame be
> redrawn with ggis primitives?
Hmmm, The above answer wasn't for sprites, we have special handling
for those in LibOvl.
To me, it sounds like you would be interested in working on LibBSE,
which uses either a true sprite from LibOvl, or emulates a sprite-like
object. I think it is exactly what you want to do. If you have the
inclination to help us out with developing that library, we can give
you some pointers to start.
--
Brian
