Hi again, so I've been messing around with this a bit and have some questions.<br>However I'm not able to properly set up lighting/materials, I think I want a function like SetMaterial in d3d7 to "activate" a material with some emissive color.<br>

As for now I'm only able to get D3DVT_VERTEX and D3DVT_LVERTEX to render all black.<br><br>Also is there some documentation available for early versions of directx available I can not seem to find any?<br><br><div class="gmail_quote">

On Fri, Mar 23, 2012 at 13:22, Daniel Oom <span dir="ltr"><<a href="mailto:daoo314@gmail.com">daoo314@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I think I accidentally dropped wine-devel, I have re-added and hope it does not create any trouble.<br><br>And thanks for the explanation, but I'm not sure I fully understand how the different versions of direct3d interact within wine's implementation. I will probably figure it out in time.<br>



<br>Also I will try to come up with a better test that compares lighting-settings as this was fun and fine introduction to wine.<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Wed, Mar 21, 2012 at 15:18, Stefan D�singer <span dir="ltr"><<a href="mailto:stefandoesinger@gmx.at" target="_blank">stefandoesinger@gmx.at</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Did you run the test on Windows? The purpose of the tests is not do document<br>
what we think should happen, but figure out how Windows behaves, and then<br>
replicate the same behavior.<br>
<br>
Is suspect your test fails on Windows because you're verifying that lighting<br>
is on or off in the wrong way. IDirect3DDevice2_GetRenderState(device,<br>
D3DRENDERSTATE_LIGHTING, &value) will most likely not work in this way because<br>
D3DRENDERSTATE_LIGHTING does not exist in IDirect3DDevice2. You have to set up<br>
the d3d states in a way that rendering produces a different result with<br>
lighting on vs lighting off, then read back the rendering result(there's<br>
already a get_pixel_color function for that) and verify that you get the<br>
correct color.<br>
<br>
A basic recipie for that: With lighting off, you get the diffuse color in the<br>
vertex as final color(well, assuming that stuff like texturing, fog, etc. are<br>
off too). With lighting on it runs through the d3d lighting calculations[1].<br>
If you disable all lights(d3d default), set the global ambient light to<br>
black(in later d3d there's a renderstate for that, in d3d2 I suspect that's<br>
part of D3DLIGHT and IDirect3DLight*), and set the emissive material property<br>
to a color != black, your emissive color will be the final color(since the<br>
ambient, diffuse and specular components of the equation are zero). By setting<br>
the vertex color and emissive material color to different colors you can tell<br>
if lighting is on or off.<br>
<br>
Cheers,<br>
Stefan<br>
<br>
PS: It's prefered to keep such discussions in public, ie with wine-devel CCed.<br>
I haven't CCed wine-devel yet, and I'm not sure if you dropped it or if I<br>
dropped it accidentally.<br>
<br>
1: <a href="http://msdn.microsoft.com/en-" target="_blank">http://msdn.microsoft.com/en-</a><br>
us/library/windows/desktop/bb147178(v=vs.85).aspx<br>
<br>
Am Mittwoch, 21. M�rz 2012, 09:25:40 schrieb Daniel Oom:<br>
<div><div>> I have poked around a bit with the source and managed to add tests that<br>
> checks if lighting is disabled/enabled in device2 and device7. I also added<br>
> SetRenderState in IDirect3DDeviceImpl_2_DrawPrimitive. The tests works but<br>
> I have not checked what effect the change has in other circumstances.<br>
><br>
> I attached a patch in hopefully the preferred format.<br>
><br>
> On Sat, Mar 10, 2012 at 22:04, Stefan D�singer<br>
<<a href="mailto:stefandoesinger@gmx.at" target="_blank">stefandoesinger@gmx.at</a>>wrote:<br>
> > Am Samstag, 10. M�rz 2012, 17:22:51 schrieb Daniel Oom:<br>
> > > Hi,<br>
> > ><br>
> > > Writing tests, or implementing the command line tools seems like<br>
> > > something I could do. I'm kinda leaning towards the command line<br>
> > > tools, since it would offer a chance to thoroughly learn the shading<br>
> > > languages.<br>
> ><br>
> > For learning purposes writing tests and fixing bugs uncovered by them<br>
> > will be<br>
> > better. The command line tools are mostly about parsing parameters and<br>
> > forwarding them to d3dx9 functions(*).<br>
> ><br>
> > If you want to look a little bit in either proposal(we recommend that in<br>
> > general):<br>
> ><br>
> > For the test stuff, take a look at IDirect3DDeviceImpl_2_DrawPrimitive<br>
> > in<br>
> > dlls/ddraw/device.c. It thunks IDirect3DDevice2::DrawPrimitive to<br>
> > IDirect3DDevice7::DrawPrimitive. The main difference is the VertexType<br>
> > parameter. It is a D3DVERTEXTYPE in the IDirect3DDevice2 method, and a<br>
> > DWORD<br>
> > with D3DFVF_* flags in Device7. Our thunk simply converts between these<br>
> > two,<br>
> > but a deeper difference a user noticed is that D3DVT_LVERTEX in Device2<br>
> > disables lighting calculations, whereas the equivalent D3DFVF flag<br>
> > collection<br>
> > in Device3 and Device7 does not. Device3 and newer have<br>
> > D3DRENDERSTATE_LIGHTING to enable / disable lighting, but this render<br>
> > state does not exist in Device2.<br>
> ><br>
> > Fixing this is fairly straightforward, just call<br>
> > SetRenderState(LIGHTING,<br>
> > ...)<br>
> > in the thunk, but it needs some tests to answer / show the following:<br>
> ><br>
> > * Show that D3DVT_LVERTEX indeed disables lighting, and D3DVT_VERTEX<br>
> > enables<br>
> > it<br>
> > * Show that D3DFVF_LVERTEX does not influence lighting in Device2 and<br>
> > Device7(D3DFVF_TLVERTEX disables all vertex processing in all d3d<br>
> > versions, this is already tested and implemented)<br>
> > * Test what happens when you call SetRenderState and GetRenderState in<br>
> > Device2.<br>
> > * Probably others<br>
> ><br>
> > There are numerous things like that that need testing and probably<br>
> > fixes.<br>
> > This<br>
> > is just one example that happens to be on my todo list. ddraw tests go<br>
> > to<br>
> > dlls/ddraw/tests/ddraw*.c. The other files should be moved to the<br>
> > tests/ddraw*.c files and extended to cover all ddraw versions.<br>
> ><br>
> > For the command line tools, download an older version of the directx sdk<br>
> > that<br>
> > still has vsa.exe and psa.exe(I think 2007 ones were the last ones) and<br>
> > compare their command line parameters to<br>
> > d3dx9.D3DXAssembleShaderFromFile<br>
> > and<br>
> > friends.<br>
> ><br>
> > The tests are certainly the more useful task. vsa.exe and psa.exe would<br>
> > mainly<br>
> > serve developer convenience when writing d3d8 and d3d9 tests since we<br>
> > wouldn't<br>
> > need an ancient dx sdk to assemble our own test shaders. d3d tests and<br>
> > fixes<br>
> > fix actual games.<br>
> ><br>
> > Enjoy,<br>
> > Stefan<br>
> ><br>
> > (*) Actually, that's not how native vsa/psa work. They seem to have<br>
> > their<br>
> > own<br>
> > copy-pasted version of the compiler and assembler, or they link<br>
> > statically. We<br>
> > should probably do it by calling d3dx9 though, especially for tools that<br>
> > mainly serve developer convenience.</div></div></blockquote></div><br>
</div></div></blockquote></div><br>