[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote :
>
> 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.
OK
>
> 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.
Yes of course. There is no way to support several zbuffers and
sub-zbuffers without breaking the API. (Moreover in WIP, P means
progress :-)
>
> 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 :-)
So Allegro is still being a pure 32 bits lib ;-)
>
> > 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.
No ASM hack to do while we keep using sizeof(float)==4. (ASM functions
use 32 bits float read/write)
>
> 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.
Yes I definitely agree.
>
> 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.
So it may be added to the todo list.
OK, it seems we both agree now :-)
Bertrand.