It seems that during the porting of d3d8 to use wined3d some of there was some breakage. Age of Mythology was working fine, but now all vertex data is totally messed up (2D is menus and stuff is fine). It has been this way in CVS for the past few days, when I first noticed it. I thought it might be my local changes so I didn't report it, but testing with the new 0.9.9 it had the same behavior (i.e. not my fault :)
After debugging things for a while it seems that problem lies in vertex data with RHW set. It seems that AoM is using all pre-lit and pre-transformed vertex data and this is not being processes properly. I think the problem is with drawprim.c:drawStridedSlow() but I haven't been able to figure out exactly where yet. If anyone has any ideas (or patches!) I'd be glad to help debug.
Regards, Aric
Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't work using wined3d yet. Last week I experimented a bit with it and I managed to get some simple vertex shader examples working (for instance http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the dolphin sample from sdk although with small issues). If I run bigger apps like 3dmark2001 and others there are huge drawing issues. I'm not very familiar with the shader/drawing code (and vertex shaders in general) so it is very difficult for me to debug. You can try the patch attached to this email but it is far from complete. If you or someone else with enough experience can look at it, you're welcome as my time is limited.
Regards, Roderick
On 3/4/06, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't work using wined3d yet. Last week I experimented a bit with it and I managed to get some simple vertex shader examples working (for instance http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the dolphin sample from sdk although with small issues). If I run bigger apps like 3dmark2001 and others there are huge drawing issues. I'm not very familiar with the shader/drawing code (and vertex shaders in general) so it is very difficult for me to debug. You can try the patch attached to this email but it is far from complete. If you or someone else with enough experience can look at it, you're welcome as my time is limited.
Thanks for the patch and info Roderick.
I'll take a look and see if I can get things working a bit better. Using your patch and the old d3d8 code I hope to whip something together.
Regards, Aric
-- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)
On 3/4/06, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Right now d3d8's SetVertexShader is disabled because d3d8 shaders don't
work
using wined3d yet. Last week I experimented a bit with it and I managed
to
get some simple vertex shader examples working (for instance http://www.codesampler.com/source/dx8_vs11_shader_simple.zip and the
dolphin
sample from sdk although with small issues). If I run bigger apps like 3dmark2001 and others there are huge drawing issues. I'm not very
familiar
with the shader/drawing code (and vertex shaders in general) so it is
very
difficult for me to debug. You can try the patch attached to this email
but
it is far from complete. If you or someone else with enough experience
can
look at it, you're welcome as my time is limited.
Thanks for the patch and info Roderick.
I'll take a look and see if I can get things working a bit better. Using your patch and the old d3d8 code I hope to whip something together.
I installed AOM (trial) here and I think the issue is related to the FVF. The function initializeFVF is only partially implemented and in case of the new code with my patch I see values '0x1c4 / 0x2' while using the old code I see other values too (0x112, 0x2d2, 0x212, 0x152). So I think we should look there and check what the old code did. (the code is quite differently)
Roderick
On 3/5/06, Roderick Colenbrander thunderbird2k@gmx.net wrote:
On 3/4/06, Roderick Colenbrander thunderbird2k@gmx.net wrote:
I installed AOM (trial) here and I think the issue is related to the FVF. The function initializeFVF is only partially implemented and in case of the new code with my patch I see values '0x1c4 / 0x2' while using the old code I see other values too (0x112, 0x2d2, 0x212, 0x152). So I think we should look there and check what the old code did. (the code is quite differently)
Yes I noticed that the new code was always 1c4 as well, but hadn't gone back to see what the old code was doing. But 1c4 definitely seems wrong since the vertex coordinates are all messed up and invalid according to MSDN. For example z is supposed to be [0,1] but I get large values, and rhw is also supposed to be between [0,1/MaxVertexW] but I was getting negative values. I'll look into the FVF code more.
Regards, Aric
-- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)
Yes I noticed that the new code was always 1c4 as well, but hadn't gone back to see what the old code was doing. But 1c4 definitely seems wrong since the vertex coordinates are all messed up and invalid according to MSDN. For example z is supposed to be [0,1] but I get large values, and rhw is also supposed to be between [0,1/MaxVertexW] but I was getting negative values. I'll look into the FVF code more.
I think that those 'wrong' values appear in the cases where 0x1c4 shouldn't be used. The fvf is set by the SetFVF call which is called from d3d8's SetVertexShader. (the comment in drawprim.c saying that the fvf needs to be set in the stateblock from d3d's SetVertexShader can be ignored I think as it appears that's already done by this call) The FVF received by SetFVF is the vertex shader itself. I think something goes wrong with selecting the vertex shader but I haven't looked at this yet.
Roderick
-
Aric Cyr -
Roderick Colenbrander