[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH v2 2/6] wined3d: Introduce wined3d_stateblock_get_state().
From:       Henri Verbeet <hverbeet () gmail ! com>
Date:       2019-11-29 17:59:05
Message-ID: CAOsNvwy0qFHsWF-Gmcooh+qVf5fnbu_vLFfOan2FQJ7shTajuQ () mail ! gmail ! com
[Download RAW message or body]

On Fri, 29 Nov 2019 at 18:47, Zebediah Figura <z.figura12@gmail.com> wrote:
> On 11/29/19 1:25 AM, Henri Verbeet wrote:
> > On Thu, 28 Nov 2019 at 09:24, Zebediah Figura <z.figura12@gmail.com> wrote:
> >> +#define LIGHTMAP_SIZE 43
> >> +#define LIGHTMAP_HASHFUNC(x) ((x) % LIGHTMAP_SIZE)
> >
> > Although wined3d is an internal Wine interface, it still seems
> > unfortunate to expose this particular implementation detail in the
> > public wined3d interface.
> >
>
> Understandable, though I'm not immediately sure what do about it.
>
> We could introduce individual wined3d_stateblock_get_*() helpers, though
> at the last point of conversation regarding stateblocks, I recall you
> seemed to prefer allowing direct access to struct wined3d_stateblock_state.
>
Generally yes.

> I guess another option is to hold a pointer to wined3d_light_state
> instead of exposing it directly.
>
I don't necessarily have a clear solution either, but I'm thinking
along those lines, yes.

[prev in list] [next in list] [prev in thread] [next in thread]