InitFrom* tests would require CreateObject to work, for which I am thinking of implementing as a seperate series of patches. For now I'm thinking of implementing InitFromFile for use by LoadTexture. Will that be okay? I could add todo_wine tests for InitFromFile, and once CreateObject is implemented, the todo's can be removed.
Cheers, Aaryaman On Mon, Mar 28, 2016 at 5:34 AM, Henri Verbeet hverbeet@gmail.com wrote:
On 27 March 2016 at 20:23, Aaryaman Vasishta jem456.vasishta@gmail.com wrote:
The max resolution I tried which passed the tests was greater than 65535, hmm. Am I missing something?
What were the dimensions you tried that succeeded exactly? 13k x 13k @ 24bpp would mean an allocation of about 640 MiB, which is a considerable part of the 2 GiB address space you get (by default) as a 32-bit process. It's perhaps not quite large enough that it's guaranteed to fail, but I don't think it's all that surprising if there no contiguous allocation of that size available.
It's not so clear if d3drm is concerned with hardware limitations at all. The more immediate/obvious issue there is is that if you're storing the image size in a 32-bit unsigned integer, the maximum size a square texture can have is 0xffff x 0xffff, since 0x10000 squared is 0x100000000. That's for a 8 bpp format, for 32 bpp it goes down to 0x7fff x 0x7fff. On the other hand, a non-square 32 bpp texture could e.g. be 0x3fffffff x 0x1. I.e., your immediate concern is that you don't overflow UINT_MAX when calculating the allocation size for the image, and there's a good chance the rest will follow naturally from that.
Not being able to instantiate textures with CoCreateInstance() makes sense, but it's good to verify. Not being able to instantiate IDirect3DRM objects is more surprising, particularly since the documentation explicitly mentions it as something that's supposed to work. It may make a difference to use IID_IDirect3DRM2 or IID_IDirect3DRM3 instead of IID_IDirect3DRM, I wouldn't put it past d3drm to be picky like that. It might also be worth a try to call DllGetClassObject() directly, to get a better idea of what works and what doesn't. At this point all that is mostly just curiosity though.
The main conclusion so far is that I think we'll want to implement file loading in InitFromFile(). While I think using d3drm_texture_create() in LoadTexture() makes sense, implementing CreateObject() should help for writing tests for InitFromFile(). InitFromImage() looks like it should be fairly trivial to implement, maybe it makes sense to implement that before InitFromFile().