[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
This is a mail I sent to Johan Henriksson and that I forgot to sent to
the conductor's list.
Johan Henriksson wrote :
>
> Hi! A few suggestions:
>
> * Add POLYTYPE_ZBUF_READ, a mode where polygons
> are drawn as usual but no data is sent to the Z-buffer, allowing
> several polygons to be drawn on top of each other.
You want to use transparent z-buffered polygons, don't you ? :)
Why not ? But polygons rendering functions are already numerous
(speaking of the inner routines in the lib). Does everybody agree to
extend them more ? Or should we prevent the 3D stuff of the lib to grow
(in size) anymore ?
>
> * Add something like
> int zbuffer_put(int x, int y, float z);
> Adding the Z if it is closer, returning TRUE or FALSE depending
> on if this was done or not. This allows for a simple manual interface
> with the Z-buffer. Right now, this undocumented stuff feels
> like a ticking bomb...
You mean that zbuffer_put should also provide clipping tests in order
to
prevent segmentation faults ?
If so, zbuffer_put may be a *slow* routine compared to direct access to
z-buffer. But we can, like we did for BITMAPs, describe in docs 2 ways
to access z-buffer :
- the indirect one (zbuffer_put) slow but secured
- the direct one faster but hazardous
>
> * Possibly normal read and write to Z-buf
Isn't it the purpose of zbuffer_put anyway ?
>
> * In my dreams: What about a drawing mode were pixels
> are tested against Z? Have no idea how this would be implemented
> with the current API though...
You just need to add 'void zpixel(BITMAP* bmp, V3D v)' and 'void
zpixel_f(BITMAP* bmp, V3D_f v)' functions (or whatever their name are).
It seems that zbuffer_put and zpixel should be easy to add to Allegro.
But you must be more specific about what zbuffer_put is intended for if
you want it to suit your needs.
POLYTYPE_ZBUF_READ is also feasible provided that the size of 3D in
Allegro is allowed to grow.
Bertrand.