Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HL1/HL1SDK] Mouse input issues #1377

Open
RichardRohac opened this issue Oct 8, 2013 · 46 comments
Open

[HL1/HL1SDK] Mouse input issues #1377

RichardRohac opened this issue Oct 8, 2013 · 46 comments

Comments

@RichardRohac
Copy link

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)

@ghost ghost assigned alfred-valve Oct 8, 2013
@alfred-valve
Copy link
Contributor

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.

@RichardRohac
Copy link
Author

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.

@RichardRohac
Copy link
Author

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.)

@dtugend
Copy link
Contributor

dtugend commented Oct 9, 2013

SDL_GetRelativeMouseState( &deltaX, &deltaY );

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.

@dtugend
Copy link
Contributor

dtugend commented Oct 9, 2013

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..

@dtugend
Copy link
Contributor

dtugend commented Oct 10, 2013

@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).

@RichardRohac
Copy link
Author

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.

@dtugend
Copy link
Contributor

dtugend commented Oct 10, 2013

I sadly can't reproduce the mousewheel problem.

I am more interested in 2), since 1) probably won't work as you said:

  1. 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
  1. 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

@RichardRohac
Copy link
Author

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.

@dtugend
Copy link
Contributor

dtugend commented Oct 10, 2013

@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/

@RichardRohac
Copy link
Author

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.)

@alfred-valve
Copy link
Contributor

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).

@RichardRohac
Copy link
Author

Yeah okay, so I guess this can be taken as solved then :).

@dtugend
Copy link
Contributor

dtugend commented Oct 11, 2013

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).

@dtugend
Copy link
Contributor

dtugend commented Oct 14, 2013

@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:

  1. compiled as /MT (not /MD), just as Valve probably does
  2. 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 :)

@RichardRohac
Copy link
Author

@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

@Tele42
Copy link

Tele42 commented Oct 14, 2013

@slouken committed the fix, so this issue report should probably be reassigned to him.

@dtugend
Copy link
Contributor

dtugend commented Oct 14, 2013

@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.

@Tele42
Copy link

Tele42 commented Oct 14, 2013

@ripieces Slouken is currently employed by Valve.

@RichardRohac
Copy link
Author

@ripieces

He means http://hg.libsdl.org/SDL/rev/d8fb783475d5 - the fixed code is by @slouken

@sixcentgeorge
Copy link

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

@dtugend
Copy link
Contributor

dtugend commented Sep 12, 2014

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.

@sixcentgeorge
Copy link

so any news ?
i played again my mod and saw that there is still the bug....while it is simple to correct : like i said a year ago , it is a question of path ...the mouse behave like in 1998 when the name is gearbox...but is "limited when the path is having an other name....
valve is having a bunch of lazies .....that make bad games and now kill others games..except black mesa the half-unfinished game that is a copy of hl made with "decomposition" of maps...
http://forums.steampowered.com/forums/showthread.php?t=3288444
yesterday i made a post in this topic with a link to http://www.consumerreports.org/cro/food/how-safe-is-your-ground-beef
that was silently removed...i hate forum that does these cleaning...they only tell lies and show the world as a paradise ...while it is a lot more like the "american burger" that has not only cows inside...
that is "funny" to see the difference between hl2 and hl3...the first was asked every day while the second interests only nobody..

@thopvna
Copy link

thopvna commented Aug 6, 2016

You can try: mouse & touchpad -> disable scroll inactive windows when i hover over them

@djdallmann
Copy link

djdallmann commented Aug 6, 2016

Doesn't SDL_GetRelativeMouseState get the last state since the previous mouse update and not current mouse position which then causes mouse movement to be off by one update or am I misunderstanding this SDL function?

I also noticed SDL for half-life/counter-strike 1.6 in windows is using version 1.3.0.0 and not the latest 2.0.4, hopefully there are no bugs in this version and I wonder if using a newer dll would get you VAC banned on windows?

@SamVanheer
Copy link

See #1900

@RichardRohac
Copy link
Author

@mikela-valve Seeing that some work is being done on the engine again, could this be looked into?

I experience the same mouse issues with the current engine version.

@SamVanheer This is all great, but the actual SDL build needs to be updated as well.
The SDL version that comes with the engine is too old to handle wheel scrolling quirks of some (Microsoft) mouse types. This was solved some time ago (http://hg.libsdl.org/SDL/rev/d8fb783475d5).

@SamVanheer
Copy link

Yeah the SDL2 library needs updates for a couple reasons, see also #1887

@mikela-valve mikela-valve self-assigned this May 24, 2019
@mikela-valve mikela-valve added this to the Future Release milestone May 24, 2019
@djdallmann
Copy link

Yes, plz update SDL

@jirikivaari
Copy link

jirikivaari commented May 25, 2019

Yeah some mouse wheel issues were fixed in another mod by replacing the SDL2 in HL1 folder.

@HalfWayLambda
Copy link

@mikela-valve Could you take a look at this issue?

@djdallmann
Copy link

Would really like to see this get fixed :(

@sixcentgeorge
Copy link

@mikela-valve can you make the two "mod" 's dlls for a mod i am making .. or give me somebody that can do it .. i am ready to give a little amount of money .
i want something basic like the gearbox engine dlls . i asked at gearbox steam community but no one is there except "customers having bugs" . how to get the source code ? or how to buy the "commercial hlsdk " ?

for those having the bug.. they should test using a well known steam path : like gearbox or dmc...
it is an added "end of life" error to force people uses the source "engine" that no one likes so much..

@SamVanheer
Copy link

SamVanheer commented Jan 13, 2021

@mikela-valve i looked into this and i think the solution is as Alfred said above to add a way to hint the engine that SDL is being used.

Currently the engine sets relative mouse mode using SDL_SetRelativeMouseMode if BUsesSDLInput returns true. BUsesSDLInput only considers official Valve games using an app id and client dll path check. If the client could hint to the engine that it's using SDL2, as any Half-Life mod using the current SDK is doing, then the engine can correctly set up SDL state as it does for official Valve games.

To test this i hex edited the engine to replace the filename for gearbox\cl_dlls\client to updated\cl_dlls\client. When i ran my mod it no longer had the issue. Mouse sensitivity did go down, probably as a result of the mouse data being received by the client being different.

It's probably easier to test by putting a mod dll in place of an official game dll, like valve\cl_dlls\client.dll. But this confirms that it works with files that don't have the path of an official game dll.

A new engine function could be used to provide the hint:

//In APIProxy.h
	pfnEngSrc_pfnVguiWrap2_GetMouseDelta_t pfnVguiWrap2_GetMouseDelta;
    void (*SetClientUsesSDL)(int usesSDL);
} cl_enginefunc_t;

Then on startup, probably in Initialize the client tells the engine:

//In cdll_int.cpp, function Initialize
memcpy(&gEngfuncs, pEnginefuncs, sizeof(cl_enginefunc_t));

gEngfuncs.SetClientUsesSDL(1);

The value provided would be used by BUsesSDLInput. If the client does not tell the engine it should default to identifying the client as it does now.

So the engine should perform these steps:

  • Initialize global int g_bUseRawInput to -1
  • Load and initialize client dll
  • Check if g_bUseRawInput is either 0 or 1
  • If not, check if it's an official game using existing logic
  • g_bUseRawInput should now be either 0 or 1

In code:

int g_bUseRawInput = -1;

qboolean BUsesSDLInput()
{
    return g_bUseRawInput != 0;
}

void CL_SetClientUsesSDL(int useSDL)
{
    g_bUseRawInput = useSDL != 0;
}

void DetermineSDLInput()
{
    if (g_bUseRawInput != 0 && g_bUseRawInput != 1)
    {
        g_bUseRawInput = 0;

        if (BIsValveGame())
        {
            g_bUseRawInput = 1;
        }
        else if (Q_strstr(g_szfullClientName, "valve/cl_dlls/client"))
        {
            g_bUseRawInput = 1;
        }
        //Remaining filename checks here
    }
}

Alternatively a function could be added to the client dll interface to ask it whether it uses SDL or not:

//In APIProxy.h
	CLIENTFACTORY						pClientFactory;
    int (*ClientUsesSDL)();
} cldll_func_t;

//in cdll_int.cpp
extern "C" int DLLEXPORT CL_ClientUsesSDL()
{
    return 1;
}

The rest is pretty straightforward: if the client provides this function it's used, otherwise the app id and filename checks are used.

Also, given that many mods' source code is unavailable or lost, it might be good to add a liblist.gam entry to force this behavior for mods that use SDL, but that can't be updated to include the fix.

MegaBrutal pushed a commit to MegaBrutal/SevenKewp that referenced this issue Mar 11, 2022
Apparently, the problem is caused by this issue:
ValveSoftware/halflife#1377

Which Solokiller has a fix for:
twhl-community/halflife-updated@92ffa23

But seems to be originated from L453rh4wk:
ValveSoftware/halflife#1546 (comment)
wootguy pushed a commit to wootguy/SevenKewp that referenced this issue Mar 12, 2022
* Make project compile on Linux

- Updated CMake files to support build on Linux
- Deleted original Linux makefiles as they are not needed since CMake is introduced
- Fixed minor problems in the code which prevented the project from compiling

It likely breaks the Windows build, but hopefully it only causes minor problems
those are easy to fix in a way that allows the project to compile on both platforms.

The Linux CMake files don't try to deploy the built libraries to the game mod
directory (people likely build in a separate environment, not where they have the
game installed).

* Explicitly link SDL2 to client library

- Added SDL2 to the list of linked libraries to client.so
Not sure if it helps anything, the library loaded without it successfully,
but it doesn't hurt either.

- Fixed symlinks to Linux and MacOS builds of SDL2
They were supposed to be symlinks and they are in Valve's repo, but in
Solokiller's fork they lost their symlink flag with this commit:
twhl-community/halflife-updated@6509102

* Port fix for getting mouse stuck in box

Apparently, the problem is caused by this issue:
ValveSoftware/halflife#1377

Which Solokiller has a fix for:
twhl-community/halflife-updated@92ffa23

But seems to be originated from L453rh4wk:
ValveSoftware/halflife#1546 (comment)

Co-authored-by: MegaBrutal <megabrutal@devcentre>
wootguy pushed a commit to wootguy/SevenKewp that referenced this issue Mar 12, 2022
* Make project compile on Linux

- Updated CMake files to support build on Linux
- Deleted original Linux makefiles as they are not needed since CMake is introduced
- Fixed minor problems in the code which prevented the project from compiling

It likely breaks the Windows build, but hopefully it only causes minor problems
those are easy to fix in a way that allows the project to compile on both platforms.

The Linux CMake files don't try to deploy the built libraries to the game mod
directory (people likely build in a separate environment, not where they have the
game installed).

* Explicitly link SDL2 to client library

- Added SDL2 to the list of linked libraries to client.so
Not sure if it helps anything, the library loaded without it successfully,
but it doesn't hurt either.

- Fixed symlinks to Linux and MacOS builds of SDL2
They were supposed to be symlinks and they are in Valve's repo, but in
Solokiller's fork they lost their symlink flag with this commit:
twhl-community/halflife-updated@6509102

* Port fix for getting mouse stuck in box

Apparently, the problem is caused by this issue:
ValveSoftware/halflife#1377

Which Solokiller has a fix for:
twhl-community/halflife-updated@92ffa23

But seems to be originated from L453rh4wk:
ValveSoftware/halflife#1546 (comment)

* Add CTriggerOnce.cpp to server library

Co-authored-by: MegaBrutal <megabrutal@devcentre>
@SamVanheer
Copy link

SamVanheer commented May 8, 2022

Addendum: the way the engine detects whether a game uses SDL causes it to hide the mouse cursor in VGUI1 menus when m_rawinput is 0. I encountered this issue in Half-Life: Opposing Force Updated.

Edit: turns out this was caused by the workaround for the mouse-stuck-in-box issue which didn't account for VGUI1 making the cursor visible the same way the engine does.

@djdallmann
Copy link

djdallmann commented May 11, 2022

Is it possible to make HL use newer SDL2 without breaking hl or potentially getting vac banned? File link, replace file (steam.exe -noverifyfiles). In relation to not having fixed win10 version.

@SamVanheer
Copy link

If you run the game with -insecure then VAC won't be enabled when running listen servers but playing on VAC secure servers will still carry the risk of getting banned.

@Frambooisier
Copy link

OpenSuse Tumbleweed without raw input option, the mouse feels jittery and loses track when fast mouse movement is applied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests