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