Re: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture

2008-07-14 Thread H. Verbeet
2008/7/14 Stefan Dösinger <[EMAIL PROTECTED]>:
>> As you note in your comment, most of this should go into wined3d. I
>> also think this should for the most part use the same code that is
>> used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would
>> probably be able to help you best there, but he's currently away.
> I am not sure, ddraw has different pool requirements and behaviors I think.
> e.g. ddraw can create sysmem render targets it seems. (Of course ddraw
> doesn't do volume textures, but I think we shouldn't apply different rules
> to volume and 2D textures)
>
I was referring to the usage flags.




RE: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture

2008-07-14 Thread Stefan Dösinger
> As you note in your comment, most of this should go into wined3d. I
> also think this should for the most part use the same code that is
> used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would
> probably be able to help you best there, but he's currently away.
I am not sure, ddraw has different pool requirements and behaviors I think.
e.g. ddraw can create sysmem render targets it seems. (Of course ddraw
doesn't do volume textures, but I think we shouldn't apply different rules
to volume and 2D textures)







Re: [4/8] [d3d9] handle invalid usage/pool combinations in CreateVolumeTexture

2008-07-14 Thread H. Verbeet
2008/7/14 Tobias Jakobi <[EMAIL PROTECTED]>:
> Hi there,
>
> this patchset fixes conformance of volumes/volumetextures creation (plus
> locking) in d3d8 and d3d9. Currently creating volumes/volumetextures
> always succeeds regardless of the usage and pool type specified.
>
> A testcase for both d3d8 and d3d9 is included in the last two patches.
> The test was verified on Vista and XP systems.
>
> Further fixes to volume/volumetexture locking are planned (the behaviour
> is still not quite correct) and some of the fixes in this patchset could
> be moved over to wined3d. That's also something that can be done when
> the hardest work is over.
>
> Cheers,
> Tobias Jakobi
>
As you note in your comment, most of this should go into wined3d. I
also think this should for the most part use the same code that is
used for CheckDeviceFormat in dlls/wined3d/directx.c. Roderick would
probably be able to help you best there, but he's currently away.