-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-11-27 11:31, schrieb Henri Verbeet:
Actually, new tests should in general go into device.c although we haven't really been enforcing that, in part because we currently don't have the get_surface_color() / getPixelColor() helpers in device.c. Merging would help with duplication of helper functions, and also be more consistent with the ddraw, d3d10core and d2d1 tests. D3d9 in particular is weird because it has the device/visual split for d3d9, but a single file for d3d9ex.
Well, there's one point of separation: device.c and d3d9ex.c test device and resource creation, which is an area with differences between d3d9 and d3d9ex. Visual.c tests rendering once resources are created, and so far we haven't seen a difference here between d3d9 and d3d9ex.
Is there some overlap between device.c and visual.c? Sure. But I don't think that means we should put everything into one huge file.
Ddraw is somewhat different because the differences between ddraw versions are bigger and actually affect rendering.
(Note that this isn't something I'd wager a holy war about. I just think fairly minor overlap between device.c and visual.c leads you to the opposite extreme of Java's tiny files.)
Perhaps some of the mode setting tests can be merged together, although obviously at the cost of increased complexity,
I'm pessimistic about that. I looked a bit into it (not much I must admit, just a bit), and I ran into problems pretty quickly, e.g. that the w8 ddraw driver crashes when calling GetSurfaceDesc after an external mode change. Reactivating a device on Windows in d3d8/9 is tricky, fvwm doesn't make this any easier on the other side, etc. I don't think we'll be able to cut down the number of mode changes substantially without sacrificing reliability.