Re: Device.c and set render states
Stefan Dösinger wrote: >> Ok I have a machine at home that I think has a GeForce card in it >> or >> a Radeon (I cant remember) that I will run on. Would it be better to >> write the test code or find something like 3D mark or the like? > Look at dlls/d3d9/tests/*.c for how the Wine tests work > > Ok looking at the d3d9 directory I found visual.c which has quite a few calls to the set render state.. So would I go through and make sure that all of the calls which I added in the type checking are in the test? What about failure tests to make sure the function is working right esp on windows? Sorry for the questions but I am not finding anything out there on writing the wine test cases =) chris
Re: Device.c and set render states
Stefan Dösinger wrote: >> Ok I have a machine at home that I think has a GeForce card in it >> or >> a Radeon (I cant remember) that I will run on. Would it be better to >> write the test code or find something like 3D mark or the like? > Look at dlls/d3d9/tests/*.c for how the Wine tests work > > Ok thanks... will do =) Chris
RE: Device.c and set render states
> Ok I have a machine at home that I think has a GeForce card in it > or > a Radeon (I cant remember) that I will run on. Would it be better to > write the test code or find something like 3D mark or the like? Look at dlls/d3d9/tests/*.c for how the Wine tests work
Re: Device.c and set render states
Stefan Dösinger wrote: >> Ok I will work on the test case when I get a chance... (I think I can >> do >> this in a vmware session if not it is going to have to wait till I get >> to the house where I have a windows machine). > Actually, you have to be careful with D3D and vmware. D3D is highly driver > dependent, up to the point where we diverge from the reference rasterizer > because games depend on a driver bug. VMware has its own D3D driver, which > fails miserably in Wine tests(last someone checked). > > So you can certainly use vmware to write the test, but before using it to > implement the same behavior in Wine or submitting the test, you should > really test with a Windows machine, preferably one that has a GeForce or > Radeon card > > Ok I have a machine at home that I think has a GeForce card in it or a Radeon (I cant remember) that I will run on. Would it be better to write the test code or find something like 3D mark or the like? Chris
RE: Device.c and set render states
> Ok I will work on the test case when I get a chance... (I think I can > do > this in a vmware session if not it is going to have to wait till I get > to the house where I have a windows machine). Actually, you have to be careful with D3D and vmware. D3D is highly driver dependent, up to the point where we diverge from the reference rasterizer because games depend on a driver bug. VMware has its own D3D driver, which fails miserably in Wine tests(last someone checked). So you can certainly use vmware to write the test, but before using it to implement the same behavior in Wine or submitting the test, you should really test with a Windows machine, preferably one that has a GeForce or Radeon card
Re: Device.c and set render states
Stefan Dösinger wrote: > My performance concern is about the switch statement itself, less about the > actual value checking. If you have something like > > switch(renderstate) { > case WINED3DRS_A: > case WINED3DRS_B: > doSomething(); > break; > > default: break; > } > > The binary code generated by the compiler still checks 239 states against > D3DRS_A and D3DRS_B(the only exception is D3DRS_A, which is never compared > against D3DRS_B). That is where my worries come from, not the doSomething() > itself. > > But beyond that, I think checking the value ranges is just wrong, at least > we need a test to show Windows does that as well. > > Ok I will work on the test case when I get a chance... (I think I can do this in a vmware session if not it is going to have to wait till I get to the house where I have a windows machine). Ahh ok... I also this morning moved the check to see if the call is just resetting the same value over and over to before the switch statement so that if we are getting the same value it just returns like it did before however it does not set it over again. Chris
RE: Device.c and set render states
My performance concern is about the switch statement itself, less about the actual value checking. If you have something like switch(renderstate) { case WINED3DRS_A: case WINED3DRS_B: doSomething(); break; default: break; } The binary code generated by the compiler still checks 239 states against D3DRS_A and D3DRS_B(the only exception is D3DRS_A, which is never compared against D3DRS_B). That is where my worries come from, not the doSomething() itself. But beyond that, I think checking the value ranges is just wrong, at least we need a test to show Windows does that as well.
Re: Device.c and set render states
2008/7/28 Chris Ahrendt <[EMAIL PROTECTED]>: > Please comment on the attached patch and let me know what you think.. Almost all of my comments on the original patch still stand. In addition, you're adding trailing spaces, and you've got an unnecessary whitespace change in there.