Re: [AD] Z-buffer API

[Sven Sandberg <ssven.geo@xxxxxxxxxx>]

Bertrand Coconnier wrote:
> >    ZBUFFER *zbuf;
> 
> Actually the z-buffer is a memory BITMAP.

Yes, but if we put it in the API I figured it might be
better to use an own structure, just to make a
distinction. A ZBUFFER ought not to need any of the
extra stuff that is in a BITMAP anyway, or does it?

> Why not ! BTW I wonder if current z-buffer API is
> sub-bitmap friendly ? What happens if you try to
draw
> a z-buffered polygon on a sub-bitmap ?

Interesting: really, what _should_ happen? One
solution could be this: Assume the z-buffer was
created for the bitmap `bmp' and the z-buffered
polygon drawing routine is called with the bitmap `x'
as argument. Then 5 different cases that can occur:
 - `x' is equal to `bmp'. This is handled as usually.
 - `x' is a sub-bitmap of `bmp'. This needs to be
handled specifically by adding an offset to addresses
within the z-buffer.
 - `bmp' is a sub-bitmap of `x'. This should be
illegal, since the polygon might be drawn outside
`bmp', ie outside the z-buffer.
 - `bmp' and `x' are two different sub-bitmaps of the
same parent bitmap. This should be illegal for the
same reason as above.
 - `bmp' and `x' are two different bitmaps. With the
same logic as above, this should also be illegal.

But on the other hand, you may actually want to use
the same z-buffer for two different bitmaps, eg if you
do page-flipping such that you draw every second frame
to bmp1 and every second frame to bmp2. It could then
be nice to reuse the same z-buffer for both bitmaps.

So another way to handle sub-bitmaps could be to
support sub-z-buffers. To draw to a sub-bitmap of the
bitmap for which the current z-buffer was created
would then require an explicit call to set_zbuffer()
with the corresponding sub-z-buffer. I.e. like this:

   BITMAP *bmp, *sub_bmp;
   BITMAP *zbuf, *sub_zbuf;
   bmp = create_bitmap(640, 480);
   sub_bmp = create_sub_bitmap(bmp, 5, 5, 200, 200);
   zbuf = create_zbuffer(bmp);
   sub_zbuf = create_sub_zbuffer(zbuf, 5, 5, 200,
200);
   set_zbuffer(sub_zbuf);
   polygon3d(sub_bmp, ...);

Maybe this is how it should be handled? This also has
the advantage that it doesn't require any changes
except that someone needs to write
create_sub_zbuffer(), but that will only be a new
feature, not a bug fix :-)

> Suggestions : you'll have to change
> clear_zbuffer(float) into clear_zbuffer(BITMAP*
zbuf,
> float) and destroy_zbuffer() into
> destroy_zbuffer(BITMAP*). I think BITMAPs that are
> used as zbuffers should be marked (by OR'ing their
id
> with a BMP_ID_ZBUFFER). This way all zbuffer
routines
> can make sure the BITMAP they receive is a zbuffer.

Either that way, or we could do

   typedef struct ZBUFFER
   {
      int w, h;
      float *dat;
      float *line[ZERO_SIZE];
   } ZBUFFER;

That won't make any assumptions about sizeof(float)

> > Also, the current code does
> > the assumption that sizeof(int) == sizeof(float)
> > (since the z-buffer is stored in a 32 bit bitmap);
> > is this true on all platforms?
> 
> Actually, this assumption is only done in
> clear_zbuffer. 

Isn't each pixel in the z-buffer a float, which is
stored in a pixel in a 32-bit BITMAP? That ought to
imply that the drawing code does the assumption every
time it reads or writes to the buffer.

I attach a patch that updates poly3d.c, exzbuf.c,
allegro.h and allegro._tx. I have kept BITMAPs as the
structure for storing z-buffers but I haven't added
the BMP_ID_ZBUFFER that you were talking about.

I'm still not sure wether it's best to use BITMAPs or
to create a new structure for z-buffers. I can't think
of any situation when a z-buffer would need any of the
existing functions that operates on BITMAPs, except
for clear_to_color() which is used internally. It's
also safer in case Allegro will ever be ported to a
platform where sizeof(float)!=32 (although it would
still be possible to hack create_bitmap() so that it
could allocate an array of floats if we ever run into
the problem) and it might be a little bit more
intuitive to give it another name. On the other hand
it would probably require many changes, both in C code
and assembler version.

Sven

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/