halflife
halflife copied to clipboard
ValveSoftware
[HL1/HL1SDK] Mouse input issues
Raw input works correctly on current (non beta) Half Life Steam build (just running regular Half Life), I get no lock on mouse rotation. But, compiled latest (8/10/2013) Half Life SDK (VS2010), I get the rotation lock when running the mod and raw input is enabled (same engine build is running, must be SDK issue I guess).
I also get no mouse wheel input whatsoever (every current GoldSrc game). (Microsoft Wireless Mouse 1000)
(Windows build)
Do you have a sample mod you could point to with this issue? I have an idea of what the problem will be but I need to reproduce the problem to be sure.
Basically I've just compiled the clean newest SDK you have here, those two dlls it gave life to and liblist.gam. Windows VS2010 build. I can upload it if interested..anyway.
Here is the sample mod after all
http://www.sendspace.com/file/4tkll7
But like I said it's just clean current SDK build.
About reproducting mouse wheel being ignored, taking in case you guys would notice it not working if it'd be global issue, I guess it's this wireless mouse special problem, some HW incompatibility or so. But it's never working, no current GoldSrc game, doesn't matter if it's raw input or not. (It worked on old engine builds and it works elsewhere of course.)
https://github.com/ValveSoftware/halflife/blob/a06e5a1f53bd1b8e2096f1dd33b6adfa44561a00/cl_dll/inputw32.cpp#L494
SDL_GetRelativeMouseState( &deltaX, &deltaY );
deltaX and deltaY get 0, also if you press the windows key to get out of the game you see that the mouse is stuck in a window corner or edge.
I am not SDL2 savvy, so I don't know if it's an SDL problem or if some other SDL functions (i.e. for Message Pumping) need to be called inbetween.
I tried a separate SDL2 test-program (with SDL-2.0.0-7046).
SDL_SetRelativeMouseMode(SDL_TRUE); Keeps the mouse in the midle of the window as it should, don't know yet if Half-Life calls that or not with the custom client.dll.
Have to go to bed, will try to debug Half-Life tomorrow, maybe I'll find s.th..
@alfred-valve :
Well yeah, with the custom mod SDL_SetRelativeMouseMode is not called by Half-Life.
With the default valve mod SDL_SetRelativeMouseMode is called from inside hw.dll.
I think one could do the calling of SDL_SetRelativeMouseMode in the client (IN_ActivateMouse, IN_DeactivateMouse and where it re-checks the m_rawinput CVAR), but I am not sure if that's the right way to do, or if we should relay on hw.dll instead, as it is for the default Half-Life mod?
Btw dmc and ricochet client.dll inputw32.cpp doesn't have m_rawinput handling in the SDK, they always do rawinput, I suppose that is wanted this way (I am fine with that)?
@RichardRohac
Regarding the mwheel issue, have you tried pressing attack (i.e.ENTER or Mouse button 1), after doing mwheel? You might be a bit confused, because it doesn't load the HUD sprites for the weapon menu from the valve folder (I think you will have to put them in your mod folder).
It's strange game input gets handled differently for each game / MOD like this. Anyway, I'd say it doesn't really matter if SDL_SetRelativeMouseMode would be engine or SDK handled, keeping it engine wouldn't hurt anything I guess, not even code customizability.
About the wheel issue, wheel !movements! are completly ignored. Wheel as button works, but moving the wheel does nothing, and that's pretty serious. Now I don't know if it happens globally or it's just my mouse, but that'd be weird, it works elsewhere perfectly.
I sadly can't reproduce the mousewheel problem.
I am more interested in 2), since 1) probably won't work as you said:
- Try this:
- enter the game (map boot_camp in console)
- in console: bind mwheelup "echo test"
- resume into the game, move mousewheel up
- now look into the console if it says test
- Try this:
- go to options Keyboard
- select a mapping and hit Edit Key
- move the mousewheel
- if this works it should recognize the mouse wheel and change the bind to MWHEELUP / MWHEELDOWN
Both cases don't work. Now, message pump or whatever way SDL handles it never creates MWHEELUP/DOWN events at all. Seems to be specific mouse issue, but I don't get ..why it's not working here.
@RichardRohac @alfred-valve The mousewheel not working might be due to the following:
I found this: http://techietalkz.com/2011/04/10/how-to-workaround-for-microsoft-wireless-mouse-5000-scroll-wheel-issue/
Most (almost all) mouse drivers cause mouse wheel events with a "delta" of ±120. This is an arbitrary value that has been chosen by Microsoft in the past to allow finer control. Since then, several programs use that value directly to test whether the mouse has been scrolled down or up (delta / 120 == 1 -> down, delta / 120 == -1 -> up, or something like that). However, the Intellipoint software causes mouse wheel events with smaller "delta" value (the expected finer grain control), and programs which use the 120 value that way just fail to register the wheel movement, because in integral values, 30 / 120 = 0…
(The post linked above, might also contain solutions for you @RichardRohac )
And I looked into the SDL2 code to find this in SDL_windowsevents.c
case WM_MOUSEWHEEL: { // FIXME: This may need to accumulate deltas up to WHEEL_DELTA short motion = GET_WHEEL_DELTA_WPARAM(wParam) / WHEEL_DELTA;
SDL_SendMouseWheel(data->window, 0, 0, motion); break; }
And SDL_SendMouseWheel won't send the event when motion is 0.
I won't blame that on the SDL2 developers since Microsoft themselves isn't too clear about how to use WHEEL_DELTA: http://msdn.microsoft.com/en-us/library/windows/desktop/ms645617.aspx
Maybe someone file a bug report at SDL2 maybe (not me please): https://bugzilla.libsdl.org/
Following the article I got the problem fixed, so this is definitely SDL2 releated then, thanks for bothering, software for this mouse might get handy in future, fixing mousewheel in other applications as well.
Mousewheel issue shouldn't be marked as Half Life bug then (?).
Now there's yet to fix the rotation lock. (I mean calling SDL_SetRelativeMouseMode(SDL_TRUE) when in game for MODs as well, engine or SDK side whatever, as that is r e s o l u t i o n to this problem for me, I've tested it.)
The not seeing SDL relative mode is a bug in HL1, I'll need to add a hinting API so that mods can tell the engine they support SDL2 (rather than the older OS specific methods).
Well, as expected I ended up being the one to submit the bug to libsdl.org sigh :( https://bugzilla.libsdl.org/show_bug.cgi?id=2147
Though you guys would need to update the SDL2.dll (that is in case they fix it).
@RichardRohac
They fixed the bug in SDL2 in the hg repository. In case you can't download compile it yourself (has a VC++ 2010 Express Edition project inside), I put together a compiled version of the SDL2.dll at rev d8fb783475d5 here. However that version differs form the hg version as follows:
- compiled as /MT (not /MD), just as Valve probably does
- no XAUDIO2 support, because I don't have enough harddisk space to install the DirectX SDK
It would be cool if you could test if that DLL file or your own compiled version of it (rename the original one for backup and don't join any VAC servers while using the modified one), solves the mouse issue in default settings (I mean with the driver normally installed where you got the problem). (You might need to scroll several lines before it reacts, but it should react now. Maybe try once with the old DLL first to verify the problem exits and then with the new DLL to test if it's gone.)
But I assume we won't see a fix in Half-Life too soon, since @alfred-valve will probably want to wait for a stable SDL2 version I guess :)
@ripieces
Thanks for all this bothering, they really have fixed the issue, scrolls instantly :) Until VALVe won't update the dependency I'll have to stick using the fixed driver anyway.
@alfred-valve
I guess it'd be senseful to wait for stable SDL build, but, this is pretty serious for most of Microsoft mouse owners, I'd consider moving the fix to your current SDL build or so.
edit:
http://hg.libsdl.org/SDL/rev/d8fb783475d5
@slouken committed the fix, so this issue report should probably be reassigned to him.
@Tele42 what do you mean, on libdsl.org the issue is assigned to him? https://bugzilla.libsdl.org/show_bug.cgi?id=2147
This issue on github.com is for ValveSoftware. SDL and Valve have connections, but they are two different organisations.
@ripieces
He means http://hg.libsdl.org/SDL/rev/d8fb783475d5 - the fixed code is by @slouken
thank you for reporting the bug in a previous topic that is assigned . the sdl2,dll should fix the bug ? dominik.matrixstorm.com/SDL2_d8fb783475d5.zip have you made also a sdl2.so file ? i tried it but it changes nothing , i am even sure that my mouse bug does not come from this file : because i launched the game with this file renamed in dll.old , mod was playing with the same bug . your file made hl did a crash with the error in kernelbase.dll , sorry
@sixcentgeorge you must have misunderstood s.th.:
The SDL2.dll file is just for fixing the mousewheel not working on some mices. After some of the recent updates the SDL2.dll file won't work anymore unless a debugger is attached (didn't look into why this happens so far).
As I said and linked in your issue you need to do SDL_SetRelativeMouseMode manually in your code until the engine is fixed. An exmaple can be found in Matherunner's fix here, which is also linked above your post.
i do write the dlls , i used the one coming from opposing force mod. so bug is incredible and i have no idea where is the bug
Please click the link I posted in the previous comment where it says "here". It includes the file and function names and also the place where to add the required modifications and the modifications itself!
thank you again for your help , i did mistake in my post with not ... if you did not played my current beta , you can do it using won sierra opfor dll and a previous hl like won i reedited hl maps and story with new models and the opfor monsters that are a lot more than with original hl . i used original dlls to use also metamod and bots made for it made by metamod-p writer
may be you can build some dlls without the bug , i would be pleased to try them , i made a second mod using svencoop dlls , all models monsters and maps are reworked and optimised by me [ i used ripent and some scripts to find errors ] may be your dlls could cover the single and multi player coop....if you want to do that , i agree we can try . here is the post of my mod at steam forum : http://forums.steampowered.com/forums/showthread.php?t=3132642
the single player hl coop has maps from decay and azure sheep added and is real kisckass reread to be sure of no errors inside ;']
this morning with linux , i tried the beta [ that changed nothing ] and then i renamed the folder from oplife to gearbox and got the mouse behaving like normal . there should be a path bug somewhere in the code of valve : i go play and test the mod with the new dlls
So issue with mouse look in mods is still here. Even if you take shared object from original Half-Life linux version and put it to mod folder the issue remains (I mean rotation lock. It's here in both raw and not raw inputs). Maybe it's time to push fix to github repo?
Ok, anyone can fix it himself with SDL_SetRelativeMouseMode, but what about modifications which uses Opposing Force dynamic libraries (there are some). We don't have source code of Opposing Force to fix it ourselves (hey, maybe you release it already? :))
i do not know if you work for valve or not . i tested my mod that uses vanilla--hmmmm--genuine dll from opposing force . the files never were updated except recently by valve for steampipes i changed the dlls and played my mod to see i have the mouse bug . after changing path to gearbox , there was no more the bug . may be with your mod you should use valve or dmc or cstrike [ according to the steamid number you selected ] to see if you still have the bug . i think there is a path bug in the source code of the hl1steampipes .
valve should select if steam makes games or not and instead of sparing money and becoming billionnaire : g.newell should buy some people to update its games and CHECK$ WHO DID THE WORK.....
Why isn't this fixed yet, input is a critical part of game..and all that's needed is to update SDL library (most important) and add call to SDL_SetRelativeMouseMode(SDL_TRUE) for MODs as well, on the engine side (less important as everyone can call this on client side)..
As @L453rh4wk pointed out in #1546 the workaround above by @Matherunner won't work properly for m_rawinput 0 on Windows because it doesn't honor whether m_rawinput is 0 or 1.
Also I am not sure if the game will call IN_ActivateMouse and IN_DeactivateMouse upon change of m_rawinput on Windows (which it might do, but I am unable to check atm, because Steam Client Bootstraper just crashes on my old laptop after the last update), meaning not sure if these are the right places to place those calls.