Alexandre Julliard wrote:
> Charles Davis writes:
>
>> An incomplete list of projects that use force_align_arg_pointer:
>> - liboil
>> - ffmpeg
>> - x264
>> - Gallium3D
>> - KDE
>>
>> Just do a Google search for 'force_align_arg_pointer' and you'll see a
>> whole bunch of pages about this!
>>
>>
On Tuesday 16 February 2010 22:18:50 Henri Verbeet wrote:
> Tweening is indeed unimplemented. We should probably catch
> unimplemented render states in IWineD3DDeviceImpl_SetRenderState()
> though.
No, the pipeline part that would implement this(vertex) should set a state
handler that prints a WAR
Charles Davis writes:
> An incomplete list of projects that use force_align_arg_pointer:
> - liboil
> - ffmpeg
> - x264
> - Gallium3D
> - KDE
>
> Just do a Google search for 'force_align_arg_pointer' and you'll see a
> whole bunch of pages about this!
>
> Now are you convinced this is a good idea
Charles Davis wrote:
> I added this to clang yesterday. Now clang will warn every time it
> encounters the force_align_arg_pointer attribute applied to a function
> pointer. This isn't a problem on Linux, but on Mac OS X those warnings
> are going to clutter the output, since we use it so liberally
On 16 February 2010 21:55, Christian Costa wrote:
> That's clearer. Thanks.
> I've just tested your patch. The incriminated state is
> WINED3DRS_TWEENFACTOR.
> I haven't investigated much though...
>
Tweening is indeed unimplemented. We should probably catch
unimplemented render states in IWineD3D
Hello Marcus,
2010/2/15, Marcus Meissner :
> Hi,
>
> Writing over the end of a struct via char[1] is only well defined if the
> struct
> is standalone and not contained in another struct.
>
> So for gcc 4.5 the strcpy triggers a fortify overflow error and we
> better use memcpy.
>
> Ciao, Marcus
>
Henri Verbeet a écrit :
On 16 February 2010 19:32, Christian Costa wrote:
So we should never enter this function at all. Right ?
Yes.
And what do you mean by "something is broken" ? Are you talking about
wined3d code ?
It means there's code that marks a state dirty that does
On 16 February 2010 19:32, Christian Costa wrote:
> So we should never enter this function at all. Right ?
Yes.
> And what do you mean by "something is broken" ? Are you talking about
> wined3d code ?
It means there's code that marks a state dirty that doesn't exist.
Typically that's because the
Henri Verbeet a écrit :
On 16 February 2010 13:45, Christian Costa wrote:
Ok. What about doing the following :
- when state is 0, don't print any message because it's normal
- when state is not 0, print the state to have a meaningfull message
No, if you see that message at all, someth
Just some ideas by me:
Dan Kegel schrieb:
> Seth Shelnutt wrote:
>> I am wondering what that status of patchwatcher is?
>
> It's waiting around for somebody to have time to start it
> up again. It's ugly code, written in shell and perl, which
> scares most people off. One has to wonder whethe
Dmitry Timoshkov wrote:
>Please don't change the indentation style of the code.
Oops!
>Also, it's not clear to me why you have removed the MCI_WAIT fixme,
Because there's nothing to fix. My tests revealed
no difference w/ or w/o WAIT flag.
> added MCI_WAIT to mciStop,
It doesn't actually matter,
On 16 February 2010 13:45, Christian Costa wrote:
> Ok. What about doing the following :
> - when state is 0, don't print any message because it's normal
> - when state is not 0, print the state to have a meaningfull message
>
No, if you see that message at all, something is broken, that's why
it'
On Tue, Feb 16, 2010 at 9:46 AM, Nikolay Sivov wrote:
> On 2/16/2010 17:34, Justin Chevrier wrote:
>>
>> On Tue, Feb 16, 2010 at 7:25 AM, Alexandre Julliard
>> wrote:
>>
>>>
>>> Justin Chevrier writes:
>>>
>>>
@@ -1357,3 +1362,52 @@ interface ITfThreadFocusSink : IUnknown
On 2/16/2010 17:34, Justin Chevrier wrote:
On Tue, Feb 16, 2010 at 7:25 AM, Alexandre Julliard wrote:
Justin Chevrier writes:
@@ -1357,3 +1362,52 @@ interface ITfThreadFocusSink : IUnknown
HRESULT OnKillThreadFocus();
};
+
+[
+object,
+uuid(95380031-955c-4710-a2ed-
On 2/16/2010 17:34, Justin Chevrier wrote:
On Tue, Feb 16, 2010 at 7:25 AM, Alexandre Julliard wrote:
Justin Chevrier writes:
@@ -1357,3 +1362,52 @@ interface ITfThreadFocusSink : IUnknown
HRESULT OnKillThreadFocus();
};
+
+[
+object,
+uuid(95380031-955c-4710-a2ed-
On Tue, Feb 16, 2010 at 7:25 AM, Alexandre Julliard wrote:
> Justin Chevrier writes:
>
>> @@ -1357,3 +1362,52 @@ interface ITfThreadFocusSink : IUnknown
>>
>> HRESULT OnKillThreadFocus();
>> };
>> +
>> +[
>> + object,
>> + uuid(95380031-955c-4710-a2ed-4a2fafe17fe8),
>> + pointer_de
On 16 February 2010 23:25, David Gerard wrote:
> 2010/2/16 Dan Kegel :
>
>> I have a prototype of how this (and other) info might be used at
>> http://wiki.winehq.org/GameChecklist
>> I think this kind of dashboard would be quite handy.
>
>
> Are there other game-specific encyclopedias that might
Henri Verbeet a écrit :
On 16 February 2010 12:25, Christian Costa wrote:
Did you test this? "state" is supposed to be always 0. Also,
debug_d3dstate() is much more readable than the state number.
Yes I tested it. Indeed, it's 0.
Ok. I will send a new patch using debug_d3dstate. Tha
wrote:
> This will allow me to enable one more testcase when I'll eventually
> submit the long awaited update to mciwave tests.
> -if (dwFlags & MCI_WAIT)
> -{
> - FIXME("MCI_WAIT not implemented\n");
> +if (wmw->hFile == 0) {
> + FIXME("Save file with zero-length sample\n");
2010/2/16 Dan Kegel :
> I have a prototype of how this (and other) info might be used at
> http://wiki.winehq.org/GameChecklist
> I think this kind of dashboard would be quite handy.
Are there other game-specific encyclopedias that might be useful, for
those games not notorious to make Wikipedia
Justin Chevrier writes:
> @@ -1357,3 +1362,52 @@ interface ITfThreadFocusSink : IUnknown
>
> HRESULT OnKillThreadFocus();
> };
> +
> +[
> +object,
> +uuid(95380031-955c-4710-a2ed-4a2fafe17fe8),
> +pointer_default(unique)
> +]
> +interface ITfLangBarMgr: IUnknown
This isn't de
On 16 February 2010 12:25, Christian Costa wrote:
>> Did you test this? "state" is supposed to be always 0. Also,
>> debug_d3dstate() is much more readable than the state number.
>>
> Yes I tested it. Indeed, it's 0.
> Ok. I will send a new patch using debug_d3dstate. Thanks.
>
That also means the
Henri Verbeet a écrit :
On 16 February 2010 11:49, Christian Costa wrote:
-ERR("Undefined state.\n");
+ERR("Undefined state %d\n", state);
Did you test this? "state" is supposed to be always 0. Also,
debug_d3dstate() is much more readable than the state number.
Yes I te
On 16 February 2010 11:49, Christian Costa wrote:
> -ERR("Undefined state.\n");
> +ERR("Undefined state %d\n", state);
Did you test this? "state" is supposed to be always 0. Also,
debug_d3dstate() is much more readable than the state number.
On Tue, Feb 16, 2010 at 10:35 AM, Alexandre Julliard
wrote:
> Erich Hoover writes:
>
>> I'm sorry it's taken me so long to get back on this issue, I've been
>> attempting to come up with, and test, an alternative solution. The
>> original patch was approached with a mind toward keeping the code
Erich Hoover writes:
> I'm sorry it's taken me so long to get back on this issue, I've been
> attempting to come up with, and test, an alternative solution. The
> original patch was approached with a mind toward keeping the code as
> similar as possible to what is currently done. I have attache
26 matches
Mail list logo
