On Wed, 7 Feb 2001, Brian S. Julin wrote:
> On Wed, 7 Feb 2001, Christoph Egger wrote:
> > > struct Overlay {
> > > enum Overlaytype type;
> > > union {
> > > struct Sprite sprite;
> > > struct VidOvl vidovl;
> > > struct OvlWin window;
> > > }
> > > }
> >
> > Should "struct Sprite", "struct VidOvl" and "struct
> > OvlWin" contain a pointer to a directbuffer?
>
> This has been one of those "up in the air" questions.
> Not all sprites have db access, but we decided it was
> impractical to have a full renderer/visual attached
> to the object to get data in, because it would waste
> a lot of space if there were a lot of sprites.
>
> I would suggest this:
>
> 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.
> 2) Pointers to the buffer data for read and write access,
> to be used instead of (overloading) the read and write members
> of the sprite family db struct. If the sprite data can be
> accessed directly, then these point to the VRAM address.
> If they cannot, they point to some RAM allocated from system
> memory.
>
> 3) Pointer to set/get functions. These functions will
> transfer the contents of a system RAM buffer to/from the
> sprite. If you are writing to VRAM directly, the function
> will do nothing, unsuccessfully, returning something like
> -E(INFO_DOESNOTHING). Simple apps would ignore the
> error. Sophisticated apps would check the error and stop
> making the calls to that function to save CPU cycles.
>
> Below are some other snippets I have on files from when
> this was discussed. Consider merging them, and what Andy has
> in his libs, and if you don't get what something is doing there,
> feel free to ask.
>
> This first is part of a proposal for something even more low-level
> than libbse, to handle all "features".
>
> #define GGI_FT_SUBTYPE_MASK 0x00000fff /* defined by extension */
> #define GGI_FT_TYPE_MASK 0x000ff000
> #define GGI_FT_NONE 0x00000000 /* used with ZBUFFER/ALPHA
> when not accompanying
> another type of buffer. */
> #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_3DTEXTURE 0x00004000 /* texture usable by 3d engine */
> #define GGI_FT_2DTEXTURE 0x00005000 /* texture usable by BLT */
> #define GGI_FT_CHARCELL 0x00006000 /* Character font cell */
> #define GGI_FT_SPRITE 0x00007000 /* Sprite/hw cursors */
> #define GGI_FT_PASSTHRU 0x00008000 /* e.g. feature connector */
> #define GGI_FT_OVERLAY_MASK 0x0ff00000 /* # of hardware "layers" */
> #define GGI_FT_ZBUFFER 0x10000000 /* with a Z-buffer */
> #define GGI_FT_ALPHA 0x20000000 /* with separate alpha buffer */
> #define GGI_FT_MEMVIS 0x80000000 /* emulate/cache offboard */
1. "FT" stands here for Framebuffer-Type, right?
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?
3. Can anyone explain me, what GGI_FT_PASSTHRU is intended to be and
should allow?
4. These #defines are all bitwise. So, it is possible to combine and
use them at once?
> ...and then the "BSE" specific stuff:
>
> /* Subtypes for sprite features */
> #define GGI_FT_SPRITE_DONTCARE 0x00000000
What does this mean?
> #define GGI_FT_SPRITE_POINTER 0x00000001 /* Hardware pointer cursor */
This is the mouse/trackball/joystick, right?
> #define GGI_FT_SPRITE_CURSOR 0x00000002 /* Hardware text cursor */
> #define GGI_FT_SPRITE_SPRITE 0x00000003 /* True sprite (a-la C-64) */
>
> /* 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?
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
