[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote :
>
> > I think it can be handled in a simpler manner. If we
> > use the offset values (x_ofs and y_ofs) of the
> BITMAP
> > we are currently drawing on, we can compute the
> > z-buffer address this way :
> >
> > info->zbuf_addr = bmp_write_line(_zbuffer, y +
> > bmp->y_ofs) + (x + bmp->x_ofs) * 4;
>
> That's what I mean with (1). Note that it won't work
> very well with the given code: Assume you do
> pageflipping, so you first create two sub-bitmaps of
> screen. Then you create a z-buffer the size of those
> sub-bitmaps, and finally you draw to the two screen
> pages. In this case this offset will generate a gpf,
> since the top left corner of the z-buffer will
> correspond to the top left corner of the virtual
> screen, and not the top left corner of the bitmap
> which we draw to.
Yes, you are right.
>
> > I now think that we can keep the 3.9.34 prototype of
> > "clear_zbuffer" (i.e clear_zbuffer(float) ). This
> > function should clear the current z-buffer i.e. the
> > one the user selected with "set_zbuffer". If no
> > z-buffer has been selected so far, the clear
> function
> > does nothing.
>
> Why isn't it better to do `clear_zbuffer(BITMAP *zbuf,
> float x)'? That gives slightly more flexibility.
Well, I thought the API should have been changed as slighty as possible.
>
> > This is true for ASM functions which must do an
> > assumption on the size of float anyway. But the C
> > version functions use pure float variable to read
> and
> > write values to the buffer, they never use an
> integer
> > to read the z-buffer.
>
> As long as the buffer was allocated by
> create_bitmap(), each pixel will only be sizeof(int)
> bytes long. Hence when reading a pixel as a float, you
> assume that sizeof(float) = sizeof(pixel) =
> sizeof(int).
Hmmm, you get confused between pixels and z coordinates. Yes, the
z-buffer is created with create_bitmap but you don't read or write any
pixel in it. And there are NO integer read/write. So far, the z-buffer
is created and cleared along with the assumption that sizeof(float) == 4
but bitmap_color_depth(bmp) is not necessarily equal to 32 :
sizeof(pixel) != sizeof(float).
The only assumption is sizeof(float) == 4 because in ASM functions the
z-buffer pointer is incremented by 4 octets (not by sizeof(int)) and
create_bitmap_ex is called with 32 bits depth. No assumption is made on
sizeof(int).
>
> If we really care about being sizeof-safe here, we
> could hack create_bitmap_ex() so that it accepts a
> color depth of 0, meaning that we allocate pixels with
> sizeof(float).
It is far too complicated ! Why not use a good old
"malloc(width*height*sizeof(float))" in create_zbuffer ?
> To keep speed, we could make
> clear_zbuffer() use clear_to_color() if
> sizeof(int)=sizeof(float), and a simple double loop
> through all pixels on other platforms.
Why not use the double loop whether sizeof(float)==sizeof(int) or not ?
>
> OK, enough talk, here's my suggestion of how things
> should work:
> - Sub-bitmaps are not handled in any particular way,
> instead we support sub-z-buffers. This is easy to
> think about for the user and seems to be the most
> flexible solution (see above for motivation).
I agree although IMHO it is not elegant but I can't think of another way
to do that. So your suggestion is the best one !
> - Use BITMAPs for z-buffers. This way we don't need
> to change anything, and we can reuse code for the
> sub-z-buffers.
Ooohh ! Too bad ! You change your mind just when I change mine :-) I now
like your idea of the ZBUFFER struct since it is portable (even on 64
bits CPU) and light weigthed (no extra datas). And I even think
create_sub_zbuffer would be easier to code with such a struct (just a
matter of updating the *dat and *line[] pointers). Moreover there would
have no need to change the BITMAP functions which is "bug-safer" (I
don't know if this word mean something).
Bertrand.