[PATCH 2/2] d3drm: Partially Implement IDirect3DRM*::LoadTexture(v2).

[Henri Verbeet]

On 27 March 2016 at 20:23, Aaryaman Vasishta <jem456.vasishta at 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().