http://bugs.winehq.org/show_bug.cgi?id=8051
--- Comment #108 from Stefan Dösinger stefandoesinger@gmx.at 2011-04-26 05:28:42 CDT --- (In reply to comment #107)
Last I checked, Wine hardcodes the constant instead of actually checking the hardware.
Where would that be? Wined3d reads the constants from the opengl library. It subtracts a number of constants from the available ones on certain drivers(e.g. fglrx and OSX) where we know that the driver needs some for its own purposes. This doesn't change the number of constants that is advertised to the d3d app though. The driver reserved constants are there to avoid GLSL compile errors with shaders that use indirect addressing(and thus potentially use all available constants)
We do limit the hardware shader constants to 256 in d3d9 and d3d8 because there are some games that break if more constants are supported. d3d9:Set*ShaderConstantF rejects constants >= 256 as well. This seems incorrect with software vertex processing and we should probably change the check a bit. (e.g. check against the HW capabilities, and if hardware VP is used cap the constants at 256, otherwise 8192)
But what I've never understood about this bug is, lots of bugs are filed that prevent an application or game from starting, and they might be the only affected app/game, but people pay attention and usually attempt to fix the problem. This bug for some reason has been demoted its entire life as unimportant.
There are three things in play here: (a) the effort needed for a proper fix, (b) the limited effect on other games(we'd probably just fix a single game) and (c) that implementing a proper fix requires a lot of knowledge how wined3d works.
(a)+(b) prevent the main wined3d developers from working on this bug, (c) makes it unlikely that a new volunteer shows up and writes a patch.