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:
>
> 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.
>
OK. The sprite-struct is now as follows:
-------------------------------------------------------
struct Sprite {
/* pointer to a directbuffer.
* Note, that this may be shared with other sprites.
* So, you do NOT have to use the read and write members
* of this db-struct.
*/
ggi_directbuffer *db;
/* Pointers to the VRAM adress, if the sprite data
* can be accessed directly. Otherwise, they point
* to some RAM allocated from system memory.
*/
void *read;
void *write;
/* 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).
*/
int (*set)(int x, int y, const void *data, int size);
int (*get)(int x, int y, void *data, int size);
};
-------------------------------------------------------
Is this ok?
The sprite-structure seems to be rather generic.
It seems to me that the Vidovl and Ovlwin-structures (see
above) don't need any special things. Am I right?
If yes, then the union-typefield is unnecessary and can be replaced
by something like this:
struct Overlay {
enum Overlaytype type;
struct Image image;
};
Comments?
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
