My Idea for GSOC

Daniel Oom daoo314 at gmail.com
Sun Mar 25 08:36:12 CDT 2012


Hi again, so I've been messing around with this a bit and have some
questions.
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.
As for now I'm only able to get D3DVT_VERTEX and D3DVT_LVERTEX to render
all black.

Also is there some documentation available for early versions of directx
available I can not seem to find any?

On Fri, Mar 23, 2012 at 13:22, Daniel Oom <daoo314 at gmail.com> wrote:

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


More information about the wine-devel mailing list