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

[Aaryaman Vasishta]

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 at gmail.com> wrote:

> 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().
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160328/96e07909/attachment-0001.html>