2016-09-13 22:11 GMT+02:00 Fabian Maurer <dark.shadow4(a)web.de>:
> Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
It was already mentioned but, at the cost of being annoying, let me
reiterate: d3dx* DLLs can't directly use wined3d data types or APIs.
They have to go through the respective d3d* client library functions.
I suspect that code sharing between d3dx* versions will eventually
happen in a somewhat different fashion and trying to build the "final
solution" from the ground up is going to be hard. Porting the various
pieces of code to d3d[x]11 as necessary, even at the cost of
"duplication" in the short term, is probably a better plan.
In my program I have window with several toolbars that have to show tooltips on its buttons.
As long as the tooltips are dynamical, I am handling the TTN_NEEDTEXTW following way:
1. Send message TTM_GETCURRENTTOOLW to the tooltip control in NMHDR.hwndFrom reveived.
2. Determine from which toolbar the notification comes by using TOOLINFO.hwnd returned.
3. Generate the tooltip text and set the TOOLTIPTEXTW.lpszText to point to the generated text.
4. Return
This procedure works in Windows, but not in WINE.
In WINE, TTM_GETCURRENTTOOLW always returns FALSE.
And there is no other way to determine which of the toolbars generated this message. (or at least I don't know it).
Any ideas about some workaround?
--
http://fresh.flatassembler.nethttp://asm32.info
John Found <johnfound(a)asm32.info>
On 13.09.2016 23:11, Fabian Maurer wrote:
> +/* temporary defines to not break compilation */
> +
> +#define IDirect3DSurface9_GetDesc(p,a) (p)->lpVtbl->GetDesc(p,a)
> +#define IDirect3DSurface9_LockRect(p,a,b,c) (p)->lpVtbl->LockRect(p,a,b,c)
> +#define IDirect3DSurface9_UnlockRect(p) (p)->lpVtbl->UnlockRect(p)
> +
...
> +#define INTERFACE IDirect3DSurface9
> +DECLARE_INTERFACE_(IDirect3DSurface9,IDirect3DResource9)
I don't think this is acceptable. It should be done in a way that
doesn't introduce mess like this.
Howdy all,
I asked this in #winehackers, but got no reply.
I have a program:
http://www.cressi.com/softwarehttp://www.cressi.com/easyUp/software/CressiPcInterface_2_0_1_37_Installer.…
that installs some device drivers that crash when it is starting up.
If I have the crash dialog enabled, I can save their backtraces. If I
disable it, all I see is something like:
wine: Unhandled page fault on write access to 0x0078d000 at address
0x7bc55e7f (thread 00a1), starting debugger...
Is there some way for me to get the backtraces to print to a console
(either of the first wine process or of the later running programs? If
the dialog is enabled, there are several crashes, which makes that
inconvenient.
Thanks!
--
-Austin
GPG: 14FB D7EA A041 937B
2016-09-14 7:25 GMT+02:00 Bruno Jesus <00cpxxx(a)gmail.com>:
> Based on idea by Elias Vanderstuyft.
>
> Signed-off-by: Bruno Jesus <00cpxxx(a)gmail.com>
> ---
> dlls/dinput/effect_linuxinput.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Thanks for giving dinput and force feedback some love and care lately.
I'm going to be a nag though...
> diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c
> index 9205c9c..bb45792 100644
> --- a/dlls/dinput/effect_linuxinput.c
> +++ b/dlls/dinput/effect_linuxinput.c
> @@ -632,7 +632,8 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters(
>
> This->effect.u.periodic.magnitude = (tsp->dwMagnitude / 10) * 32;
> This->effect.u.periodic.offset = (tsp->lOffset / 10) * 32;
> - This->effect.u.periodic.phase = (tsp->dwPhase / 9) * 8; /* == (/ 36 * 32) */
> + /* phase ranges from 0 - 35999 in dinput and 0 - 65535 on linux */
> + This->effect.u.periodic.phase = (tsp->dwPhase / 36) * 65;
Probably I'm missing something but... Why don't you actually use 35999
and 65535 in the expression?
Relatedly, why not do the multiplication before the division instead
of throwing bits of precision away? Maybe phase can go over 35999? If
that's the only reason, I'd adjust the phase before doing this
computation instead.
I guess these points apply to the other effect parameters too.
BTW, you didn't change the corresponding piece of code in
GetParameters (which, for some reason, uses 33 and 36 as scaling
constants...) so that's probably broken now. Or at least more broken
than it was before.
On 16 September 2016 at 15:54, Andrew Kanaber
<akanaber(a)chiark.greenend.org.uk> wrote:
> "Iris Pro Graphics P6300" on all the Xeon E3-1200v4 chips
> (except the E3-1258L v4)
This is missing a "Signed-off-by:" line, but seems fine otherwise.