-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
Your mails ended up in my spam folder for some reason. Google says it has large similarities to other known spam mail, which seems unlikely to me.
Am 2015-10-04 um 19:52 schrieb Andrew D'Addesio:
To avoid confusion, CreateDirect3D/ReleaseDirect3D is also renamed to CreateDirect3D7/ReleaseDirect3D7.
dlls/ddraw/tests/d3d.c | 167 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 154 insertions(+), 13 deletions(-)
New tests should be added to ddraw*.c, ideally in all ddraw versions that offer the tested feature. The long term goal for d3d.c, dsurface.c, etc is to be migrated to those files.
If you want to modify an existing test in d3d.c please move the existing code to ddraw*.c, then add your new test features to it. These files have some exising helper functions like create_device, so you don't have to take stuff like d3d3_create_objects along.
Cheers, Stefan
On 10/05/2015 01:54 AM, Stefan Dösinger wrote:
Hi,
Your mails ended up in my spam folder for some reason. Google says it has large similarities to other known spam mail, which seems unlikely to me.
Hmm, I hope it's not a problem with my SMTP server having a bad reputation.
On 10/05/2015 01:54 AM, Stefan Dösinger wrote:
Am 2015-10-04 um 19:52 schrieb Andrew D'Addesio:
To avoid confusion, CreateDirect3D/ReleaseDirect3D is also renamed to CreateDirect3D7/ReleaseDirect3D7.
dlls/ddraw/tests/d3d.c | 167 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 154 insertions(+), 13 deletions(-)
New tests should be added to ddraw*.c, ideally in all ddraw versions that offer the tested feature. The long term goal for d3d.c, dsurface.c, etc is to be migrated to those files.
If you want to modify an existing test in d3d.c please move the existing code to ddraw*.c, then add your new test features to it. These files have some exising helper functions like create_device, so you don't have to take stuff like d3d3_create_objects along.
Cheers, Stefan
Sure, I can do that. By a quick eyeballing I see that lots of tests are duplicated across ddraw*.c (test_palette_gdi, test_palette_alpha, ...). Currently FindDevice is a Direct3D1 test; would you want me to duplicate that test for Direct3D 1, 2, 3, & 7 into ddraw(1|2|3|7).c?
With this change I can remove patch #3 ("ddraw/tests: Restore strings modified by D3D7EnumLifetimeTest"). I wrote patch #3 because my D3D*EnumTest tests depend on the device strings being unchanged (so either D3D7EnumLifetimeTest must occur after my EnumTest tests or it must be changed to restore the device strings it modifies). If I move the EnumDevices test into ddraw*.c, then I no longer need to modify D3D7EnumLifetimeTest, so I can remove patch #3.
I wrote patch #1 ("ddraw/tests: Don't skip d3d1-2 tests if DirectDrawCreateEx isn't present") mainly to simplify the START_TEST(d3d) function a little bit, in order to keep patch #2 clear, but it also has the benefit of doing the correct thing (I believe currently none of the tests in d3d.c are running in systems with DirectX < 7.0; this patch fixes this). So patch #1 still seems kind of important, but moving CreateDirect3D to ddraw1.c would mean moving all of the Direct3D1 tests to ddraw1.c, which is a little excessive for my first patchset. So I might want to resubmit patch #1 separately.
Unless we just don't care about systems that old; in that case patch #1 is not important and I can remove it as well.
Regards, Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2015-10-05 um 20:05 schrieb Andrew D'Addesio:
Sure, I can do that. By a quick eyeballing I see that lots of tests are duplicated across ddraw*.c (test_palette_gdi, test_palette_alpha, ...). Currently FindDevice is a Direct3D1 test; would you want me to duplicate that test for Direct3D 1, 2, 3, & 7 into ddraw(1|2|3|7).c?
Yes please, if the function exists in all versions. In this particular case it is especially interesting to test all versions because the bug you're fixing is related to how the different versions interact.
Note that we put IDirectDraw, IDirect3D, IDirect3DDevice (version 1) into ddraw1, version 2 into ddraw2. IDirectDraw4 + IDirect3D3 / IDirect3DDevice3 go into ddraw4, and everything 7 into ddraw7.
One example where all versions doesn't make sense is test_private_data. The functionality it tests only exists in 4 and 7.
With this change I can remove patch #3 ("ddraw/tests: Restore strings modified by D3D7EnumLifetimeTest"). I wrote patch #3 because my D3D*EnumTest tests depend on the device strings being unchanged (so either D3D7EnumLifetimeTest must occur after my EnumTest tests or it must be changed to restore the device strings it modifies). If I move the EnumDevices test into ddraw*.c, then I no longer need to modify D3D7EnumLifetimeTest, so I can remove patch #3.
Yup
I wrote patch #1 ("ddraw/tests: Don't skip d3d1-2 tests if DirectDrawCreateEx isn't present") mainly to simplify the START_TEST(d3d) function a little bit, in order to keep patch #2 clear, but it also has the benefit of doing the correct thing (I believe currently none of the tests in d3d.c are running in systems with DirectX < 7.0; this patch fixes this). So patch #1 still seems kind of important, but moving CreateDirect3D to ddraw1.c would mean moving all of the Direct3D1 tests to ddraw1.c, which is a little excessive for my first patchset. So I might want to resubmit patch #1 separately.
We don't really care about pre-XP systems anymore, and the testbot doesn't run anything before Windows 2000. Those always have ddraw7.
However, as this example kinda shows, Windows 98 behavior is sometimes relevant for games, so keeping the tests runable on Win98 may be a good idea. But I think Windows 98 can be upgraded to DirectX9, so the version checks shouldn't be needed there either.
As far as official policy is concerned you can remove all the version checks from d3d.c, but it doesn't really matter because d3d.c should go away in the long run.
-
Andrew D'Addesio -
Stefan Dösinger