(resend after subscribing to the ML - if the first post comes through, pls excuse the spam then :P )
Just tracked down a crash in the game Dark Age of Camelot (daoc) when pixelshaders are enabled. The game issues a GetDeviceCaps() and then checks if MaxVertexBlendMatrices >= 4, which on wine is set to zero on my videocard (Geforce 6800), whereas a windows box returns 4.
I found this old post concerning MaxVertexBlendMatrices causing issues in another game (EQ): http://www.winehq.org/pipermail/wine-devel/2008-February/062432.html http://www.winehq.org/pipermail/wine-devel/2008-February/062437.html
So I was wondering what the proper way to fix this would be? Should this be made overrideable by a registry setting for certain games? Or should the GL check be changed? Or is that software emulated vertex blending patch needed to correctly fix the issue?
Bugzilla has 3 other games where the simple 'fix' of returning 4 makes the game work (Warhammer, EQ, Shin Megami Tensei Online): http://bugs.winehq.org/buglist.cgi?quicksearch=MaxVertexBlendMatrices
-- For reference the daoc bug is http://bugs.winehq.org/show_bug.cgi?id=10832
So I was wondering what the proper way to fix this would be? Should this be made overrideable by a registry setting for certain games? Or should the GL check be changed? Or is that software emulated vertex blending patch needed to correctly fix the issue?
The correct fix is to implement a fixed function pipeline replacement shader and emulate vertex blending with vertex shaders. I have started such a replacement pipeline, but have paused it because it did not achive the intended results(performance improvements). This was about a year ago. Someone rebased it to wine git a few months ago, the results are in the wine-devel archies.
Note that my replacement pipeline does not yet implement vertex blending, but it is needed to add this emulation on top of it.
So I was wondering what the proper way to fix this would be? Should this be made overrideable by a registry setting for certain games? Or should the GL check be changed? Or is that software emulated vertex blending patch needed to correctly fix the issue?
The correct fix is to implement a fixed function pipeline replacement shader and emulate vertex blending with vertex shaders. I have started such a replacement pipeline, but have paused it because it did not achive the intended results(performance improvements). This was about a year ago. Someone rebased it to wine git a few months ago, the results are in the wine-devel archies.
Note that my replacement pipeline does not yet implement vertex blending, but it is needed to add this emulation on top of it.
Unfortunately, I know next to nothing about D3D or OpenGL...
I do wonder why the game appears to work fine.. I haven't noticed any anomalies in the graphics output as far as I can tell. If this is also the case for those 3 other games, wouldn't an override via the registry for this value not be an acceptable solution?!
Unfortunately, I know next to nothing about D3D or OpenGL...
I do wonder why the game appears to work fine.. I haven't noticed any anomalies in the graphics output as far as I can tell. If this is also the case for those 3 other games, wouldn't an override via the registry for this value not be an acceptable solution?!
No
Wie can't lie about our abilities. It may fix those 3 games, but then 20 other games will start using the broken functionality and break.
As for a registry key, I don't want this to become a mess-with-the- registry-fest. Things should work without requiring custom registry keys(or DLL overrides for that matter). This may sound cruel, but sometimes keeping things broken is the best way to motivate people to fix it.
Unfortunately as you say, this vertex pipeline replacement stuff is a quite advanced topic, and D3D is pretty advanced by now so there are very few bugs that are an easy job for beginners to fix There are certainly no weekend jobs left.
-
Karl Vogel -
Stefan Dösinger