From: Sven S. <ssv...@ya...> - 2001-01-30 16:26:37
|
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/ |