On Sat, 7 Apr 2001, Andreas Beck wrote:
> > Before I can start setting up the API for libblt, I need an _exact_
> > definition of what a BOB (= Blitting-Object) is.
>
> A bob in the usual sense is an just something you can "blit" to
> the screen in some accelerated way.
>
> It is used for emulating sprites on hardware that does not have
> enough or too limited hardware sprites. For example the players
> and enemies in 2D-arcade games are usually BOBs.
>
> Basically the idea is that you define a BOB and ask libblit to
> cache it for you in some way so that it can be blitted as fast as
> possible later on
>
> Basically Libblit should facilitate ways to define such objects
> and to put the on screen, eventually using some ROPs or other
> manipulations to combine it with the screen.
See below.
> > Is it a kind of a Buffer? If yes, which one? Texture-Buffer,
> > Raw-Buffer or whatever else?
>
> It is up to the individual target how to implement it. It should
> just fall back to allocating main memory and using the usual
> LibGGI drawing fuctions if nothing better is found, but for
> example on fbcon it should try to allocate offscreen memory and
> hardware-blit from there ^^^^^^^^^^^^^^^^
That's why I asked, if it should be a kind of a (Texture|Raw)-buffer.
It will be stored either onboard or in RAM if not enough VRAM is
available.
Furthermore, using a buffer as a BOB can make use of the advantages
of libGAlloc's allocation-technologie. For example, you can upsize
the BOB's as long as there is free space to allocate.
Please read the docs at
http://mojo.calyx.net/~bri/projects/GGI/galloc/ for more information.
> or for X it should allocate Pixmaps and let the X Server blit.
Why not a "XImage" ?
> While you are at it, Libblit should also contain visual->visual
> blits, to avoid having "libblitbobs" and "libblitvis" ...
Sure. The source-visual should be an array of visuals in order to
support multisource blits.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
