[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Sven Sandberg wrote :
>
> Hello,
> In the new z-buffer API, you initialize z-buffering by
> doing:
>
> create_zbuffer(bmp);
>
> This sets up a global zbuffer which is private to
> Allegro, ie. the user of Allegro can't access it.
> Wouldn't it be better if you had to do:
>
> ZBUFFER *zbuf;
Actually the z-buffer is a memory BITMAP.
> zbuf = create_zbuffer(bmp);
> set_zbuffer(zbuf);
>
> ? The difference is that you can have several
> z-buffers around at the same time. This gives more
> freedom to the programmer, and could be much more
> efficient for people who use more than one z-buffer
> (eg in a split-screen game).
Why not ! BTW I wonder if current z-buffer API is sub-bitmap friendly ?
What happens if you try to draw a z-buffered polygon on a sub-bitmap ?
Hmmm... I'll take a look at that.
> AFAICS the changes would
> be easy to do, and I'd be happy to code it if everyone
> agrees. (I thought I'd better mention this before the
> API freezes at 3.9.34.)
Suggestions : you'll have to change clear_zbuffer(float) into
clear_zbuffer(BITMAP* zbuf, float) and destroy_zbuffer() into
destroy_zbuffer(BITMAP*). I think BITMAPs that are used as zbuffers
should be marked (by OR'ing their id with a BMP_ID_ZBUFFER). This way
all zbuffer routines can make sure the BITMAP they receive is a zbuffer.
> Also, the current code does
> the assumption that sizeof(int) == sizeof(float)
> (since the z-buffer is stored in a 32 bit bitmap); is
> this true on all platforms?
Actually, this assumption is only done in clear_zbuffer. This is a hack
Calin Andrian did (so I'm not culprit ;-) in order to clear the zbuffer
by calling clear_to_color (there is no function in Allegro which can
clear a BITMAP using a float value). Anyway, it works on any 32 bits
platform. There are many other "32 bits assumptions" in Allegro and
AFAIK no 64 bits port is scheduled (May be Allegro 5.0 ? ;-)
Bertrand.