[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Bertrand Coconnier wrote:
> Sven Sandberg wrote :
> > Interesting: really, what _should_ happen? One
> > solution could be this:
[snip]
> I don't think the normal optimised code should
> execute these tests.
Perhaps not, but IMHO the important thing here wasn't
the tests, but rather how z-buffered drawing to
sub-bitmaps should be treated in general. What I meant
was to suggest a way to define what shall happen when
drawing to sub-bitmaps, since you could think of at
least two different philosophies. Here are my two
approaches again:
(1) Automatically detect that we draw to a
sub-bitmap, and find the corresponding sub-area of the
z-buffer. (This is tricky: note that the sub-bitmap
must be a sub-bitmap of the bitmap that was used when
calling create_zbuffer(bmp), so strange things happen
eg. when the bitmap we draw to is instead a sub-bitmap
of screen.)
(2) Don't do this test; always make the top left
corner of the z-buffer correspond to the top left
corner of the bitmap which we draw to. This is how it
is currently handled. We could provide a
create_sub_zbuffer() function in case someone actually
uses sub-bitmaps of the z-buffered bitmap (though I
think this is likely to be much less common than using
eg. "parallel" sub-bitmaps of screen).
> > 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.
>
> In 3.9.34 this is not an issue since there is only
> one z-buffer : you automatically reuse the same
> z-buffer from one bitmap to another one.
No, but it would be an issue with approach (1). So I
would propose to use (2).
> 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.
> 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.
> 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).
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). 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.
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).
- Use BITMAPs for z-buffers. This way we don't need
to change anything, and we can reuse code for the
sub-z-buffers.
This requires only my previously posted patch. We
might add the sizeof()-safe code (that's easy to
implement), and perhaps also sub-z-buffers (that's
just a matter of writing a wrapper to
create_sub_bitmap(), it's easy too).
Is that ok?
Sven
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/