Lucas asked:
> Should I correct the tabs and align the
> parameters in the function prototype when I implement them?
If you do a significant rewrite of a function,
or are implementing it for the first time, I think it's
ok to use more standard code style in your new code,
or to update the style of adjacent old code
(like a prototype) related to your change.
Hello everyone. As you may know I'm working on the dinput8 action
mapping support and at the moment I've pretty much finished the mouse
and keyboard and just need to get my patches in.
For the next part, however, I'm going to need to analyze lot's of data
generated by different joysticks to figure out how the mapping works.
Some things are already clear for me, but I have only some simple USB
joysticks here and thus would like your help to collect more useful
data.
If any of you has any sort of joystick (simple gamepads, driving
wheels and whatnot) and would like to help, I've set up a little app
that uses the DI8 action mapping API to construct a mapping for every
connected joystick and outputs it to the terminal. You just need to
run it, redirect the output to a file and email it back to me. Telling
me which version of windows you're running would be nice. If you want
to help but can't use windows, wine with native dinput8.dll is fine
too.
The program can be found here:
https://github.com/downloads/lfzawacki/dinput-samples/devices_test.exe
The code is here:
https://github.com/lfzawacki/dinput-samples/blob/master/devices_test.cpp
Thanks in advance
Cheers
Hi Stefan sorry for the duplicate email. I forgot to also send it to wine-devel.
On Fri, Jun 17, 2011 at 12:02 AM, Stefan Dösinger
<stefandoesinger(a)gmx.at> wrote:
> On Thursday 16 June 2011 10:49:19 Michael Mc Donnell wrote:
>> I've added the test you outlined. It shows you're correct that
>> GetDeclaration only writes up to D3DDECL_END(). I've changed the
>> implementation so that it caches the number of elements and only
>> writes up to D3DDECL_END().
> Looks good to me.
Great!
>> You're right it could potentially read undefined memory depending on
>> the compiler semantics. I think the safest thing is just to read up to
>> D3DDECL_END() in the passed in declaration, then it will never read
>> undefined memory (except if the programmer makes a mistake).
> Looks good, but please write a WARN message in every case where you return an
> error to the application. We believe that we handled the error condition
> correctly, so there's no need for a FIXME, but the broken app behavior may
> have been triggered by some other problem in Wine, so the message is more
> important than a simple TRACE.
Ok I've added WARN message for every case where it returns an error to
the application. I've also reworded the WARN where it uses an invalid
declaration but still must return D3D_OK.
Hi Vincas, i wanted to give bug 27600 a try. So on top of
wine-1.3.23-50-g2497a91 i applied patches:
1. 75818
2. 75819
3. 75831
4. 75830
5. 75829
6. 75820
7. 75821
8. 75822
9. 75823
but i end up with failure during the buildup:
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -fno-stric
t-aliasing -Wdeclaration-after-statement -Wempty-body
-Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith
-Wlogi
cal-op -g -O0 -o input.o input.c
input.c: In function ‘GetRawInputDeviceList’:
input.c:495: error: ‘union generic_request’ has no member named
‘get_raw_input_device_list_request’
input.c:495: error: ‘union generic_reply’ has no member named
‘get_raw_input_device_list_reply’
Regards,
W.
--
IHNED.cz je nový, přehlednější a rychlejší. Přesvědčte se na:
www.ihned.cz
Had to check a few warnings earlier and there hasn't been a warning
report in a while, thought I'd share it. It's also still impossible to
configure with -Werror because of warnings in configure scripts.
Wine version
wine-1.3.22-203-gac90c1b ac90c1bd1878599710605fa5b4e2fe8ce224b280
Enabled packages
alsa freetype gstreamer jpeg ldap openal opengl openssl png x
xinerama xinput2 xml xrandr
Disabled packages
capi cms cups curses esd fontconfig gettextpo gnutls gphoto gsm hal
jack mpg123 nas opencl oss sane tiff v4l xslt xxf86vm
CFLAGS
-msse4 -O3 -Wall
Built on
Linux azura 3.0-0-generic #1-Ubuntu SMP Thu Jun 9 16:32:10 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
J. Leclanche
Hi Jay,
+HRESULT TRASH_RestoreItem(LPCITEMIDLIST pidl){
Nit: the brace should be on its own line.
+HRESULT TRASH_RestoreItem(LPCITEMIDLIST pidl) DECLSPEC_HIDDEN;
+HRESULT TRASH_EraseItem(LPCITEMIDLIST pidl) DECLSPEC_HIDDEN;
These two functions are never called in this patch, so you're
introducing dead code. That's not allowed. Introduce the functions
in the patch that uses them, please. If the resulting patch is too
large, you must split it another way.
--Juan
2011/6/30 Charles Welton <charleswfb(a)gmail.com>:
> ---
>
> + memcpy(buffer_mem, vertices, size);
There is no need to allocate and write into your own buffer then copy
the content, you can directly write into the vertex buffer.
A more important issue: MSDN says "The ID3DXLine interface implements
line drawing using textured triangles", which is probably true (as far
as I know there is otherwise no support in D3D9 to
antialiased/stippled/wide lines, which are instead supported by
ID3DXLine). So, drawing with D3DPT_LINESTRIP primitives in general is
probably not the right way...