[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Bertrand Coconnier wrote:
> Sven Sandberg wrote :
> > 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.
Do we really need to care about that, given that we change the other
functions so that we are sure to break the code for people who use
`clear_zbuffer()' anyway (eg. they must first have `set_zbuffer()'ed
it)? I would assume people just use it one or a couple of places per
program. And it seems more consistent with the rest of the new z-buffer
API, but that's just my opinion of course.
Btw, did we decide whether we should change the API or not in the first
place? No one objected, but not many commented either, and now it is in
a WIP. On the other hand, hardly many people can have had time to use
the z-buffer functions, and they are using WIPs on their own risk
anyway. So I still vote for changing the API.
> 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.
What I meant is that Allegro reads from 32 bit bitmaps using longs (not
ints as I said) in many other places (eg. in src/c/cdefs32.h where
`PIXEL_PTR' is defined to be `unsigned long*'). I thought that even
create_bitmap() did this, but I was wrong, it uses a constant 4. Hence
Allegro does the assumption that sizeof(unsigned long) = 4 =
sizeof(float), so in a way we are both right, except that I said `int'
but meant `long'. Anyway, with all the assumptions on sizeof(unsigned
long) throughout the library, I guess it won't hurt much more if we
assume sizeof(float)=4 in a couple of more functions :-)
> > 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 ?
Because clear_to_color() is more optimized. But again I used the wrong
condition: it should be `sizeof(float)=4'.
> 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).
I would assume it's quite a bit of extra work to fixup the assembler to
work with this new struct though, but you know that better.
> Moreover there would
> have no need to change the BITMAP functions which is "bug-safer" (I
> don't know if this word mean something).
I understand what you mean, it helps people not to write bugs. I think
this is the strongest argument for using ZBUFFER: z-buffers and bitmaps
have logically almost nothing in common.
For this purpose, perhaps we could do a simple `typedef BITMAP ZBUFFER;'
for now so that we have changed the API once and for all, and can do the
actual implementation of `struct ZBUFFER' later, whenever someone cares
to write it.
Sven