Hi,
I'm trying to get projective textures working on hardware that doesn't support homogenous texture coordinates with the new vertex setup code (t_vertex.[ch]). The problem with this is that the W coordinate of the hardware vertex must be computed from two vertex attributes, which is why the new vertex setup code can't generated it directly.
The solution I'm proposing emits homogenous texture coordinates and then calls a vertex post-processing hook in the driver that can compute W and 2D tex coords suitable for my crippled hardware from homogenous tex coords.
I'm attaching two patches. The first one implements the driver-independent functionality for hooking up a post-processing function. The second one demonstrates the changes to the Savage driver to support projective texturing using the post-processing hook.
I'd appreciate feedback (Keith?) if this is good for CVS or if there are other/better ideas for solving the same problem.
It's a hack, of course, but hardware like this really makes it difficult to keep things nice. There are quite a few drivers that are stuck waiting for a solution to this issue.
One question is what happens with the 'rastersetup-to-dma' fast render stages for unclipped primitives? It looks like in this approach you emit vertices from t_vb.c which are 1 dword larger than hardware expects and then fix things up afterwards, right? So you'd want to make sure you weren't doing that into a dma buffer...
Secondly, is the obvious counter-concern -- what happens with clipping? The 'post processing' probably needs to be undone so that clipping can proceed, then be re-done on the clipped vertices, right?
Also, the above point about two different vertex sizes isn't really clear in the code & could use some explanation.
In balance, I think I prefer a slightly different solution to the problem:
1) Make sure rastersetup-to-dma isn't used with these types of vertices.
2) Emit vertices with a seperate 'q' coordinate, as if the hardware supported projective-textured vertives.
3) Create point, line, triangle functions which translate from idealized to hardware vertices and make sure that they get used for all primitives.
This probably works out slightly slower but is going to be much easier to make work correctly, and there is a much better chance of getting a correct result.
Keith
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
