Quote:I have compiled the mesa drivers for windows and it supports (by software):
Opengl 1.1:100%
Opengl1.2:100%
Opengl1.3:100%
Opengl1.4:100%
Opengl1.5:66%
If someone is interested in this driver I can e-mail it for testing
I donīt have enough time to test it.
Now, I am working in its glide driver.
Hehehe! Well, you seem to be a hotshot, right? No offense, but you managed what nobody else could do before.
The thing is, if your dll works, it's just because your applications don't make use of those 1.4/1.5 features, allright! Let me know when you hit a total rasterization fallback.
You see, the fetch_texel routines (heavily used in TRF) cannot cope with some of the filtering modes. I won't go into details; anyway, checkout "Mesa/progs/tests/dinoshade.c" from the CVS server, compile it and run it in 16bits.
Let me explain a bit better: 16bit modes can't do HW stencil. That particular demo makes heavy use of stencil. That means you'll hit a TRF each time the shadow is casted upon the floor. Then tell me why the floor looks so shitty after a certain Z values.
Hint: when the pixel/texel coverage hits a certain ratio, the fetch_texel callback runs berserk.
Of course, that could be solved by changing the fetchers. So the answer is YES, it can be done -- but SW paths will become even slower, so I didn't bothered with them. Anyway, if you find the time to fiddle with them, let me know... I will commit the changes.
Oh, and one more thing: I hope you updated the compulsory HW checks before the T&L pipeline is being run. It seemed useless to me to bulk in all the goddamn tests, since not all extensions were supported. But now, with so many features, you need to be safe!