Michel DÃnzer wrote:
On Tue, 2004-01-06 at 11:50, Keith Whitwell wrote:
I haven't looked at them, but these sound like problems arising from the fact that size-3 color arrays can now make it through to the driver for incorporation into vertices.
The easiest way to deal with this is to convert to using t_vertex.[ch] instead of t_dd_vbtmp.h for building vertices.
Thanks for the pointer; is that the only affected template?
I'd appreciate any more hints to get me started in the right direction, I'm a bit lost. :\
In the next couple of days I'll convert a couple of the drivers to this scheme. From there it should be obvious what needs doing for the rest.
To clarify the high-level problem: If glColor3 is used instead of glColor4, the alpha value is supposed to default to 1.0. But we're not explicitly promoting 3-value colors to 4-value colors in the glColor3 functions. When we've got a vertex buffer full of 3-value colors and begin rendering we either have to explicitly fill in the alpha values with 1.0 or tell the driver/rasterizer to assume alpha is 1.0 for all vertices. Neither of these was happening in Mesa 5.1 until Keith's recent fix. One demo that exhibited the resulting problem was progs/demos/paltex.c in which blending was enabled but the vertice's alpha values were undefined.
-Brian
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
