Quake's mouse code is written stupidly

[Baker]

[mh]

Ha ha - I guess most people just notice the renderer and stop right there, but this is actually where probably the most work ended up being done.

Really nice input code that works at least reasonably consistently on all of your target platforms is surprisingly difficult (but interesting and rewarding). It took me so many false starts to get to what you see today, and a good chunk of the end result must be attributed to a lot of time spent trying to fix what I thought was jerkiness in the input code (it turned out to be using a frametime instead of cl.time somewhere in the view.c stuff).

There are a lot of little gotchas in that code by the way. It uses the frame time from the previous frame for rebalancing movement events (quite intentional because there is some latency between when an event actually happens and when the message arrives to your window procedure - this seems to average things out better). It relies on Sys_SendKeyEvents being run every pass through your main loop, even if you're not running a frame. There's additional code in the window procedure for handling the mouse wheel in menus and the console (because WM_INPUT messages are no longer recieved when in menus or the console in an SP game and a windowed mode).

[daemonicky]

[Baker]

[Baker]

[Baker]

[mh]

[goldenboy]

[Baker]

Old thread. Pain revisited. Trying to fix up FitzQuake's input code.

My "mistake" was changing FitzQuake to set windowed or fullscreen mode once on startup. This busts the mouse code at least on some setups.

For instance, the set video mode code deactivates and reactivates the mouse. And this is before mouse initialization . Also Windows ShowCursor () is not kind ... if you do ShowCursor (TRUE) twice, you better call ShowCursor (FALSE) twice -- otherwise you will attempt to "hide the mouse" (but you didn't) or "show the mouse cursor" (but you didn't).

The single pass video mode startup didn't break anything. Starting it with -window is enough to cause it fits apparently for some versions/configurations of Windows. I just made it far more obvious since starting in windowed mode is easier to do.

Input code in my humble opinion is probably the least fun thing to have to deal with. Startup, switching away from the active app, switching back, suspending it, re-enabling it ... no fun. And just to get back to even. There isn't much of a "win" because the time invested just gets it back to "properly functional".

[r00k]

I've been through this as well, personally as a player I prefer raw input, oddly with m_filter 1. I can feel the graininess of the poll rate with m_filter 0. Which might just be a timing issue...

[mh]

[Baker]

[mh]

[Spike]

IN_Accumulate is because the mouse is clipped to be within the window. consider how fast you can move your mouse 160 pixels across - can you do that within the course of one frame? probably. what happens when you reach the side? it gets clamped. which is bad. its even worse if windows doesn't honour ClipRect for some reason, which can result in clicking on other windows!
you don't need it for dinput/rawinput because those are movement deltas already, rather than absolute cursor coords.

q3 supposedly has a much cleaned up input system. events are shoved into a queue by whatever windowing system code is active, and handled in a single unified place. instead of different input code on every single platform.
which reminds me that I need to do the same thing myself some time. hrmph.

[mh]

...and S_ExtraUpdate is obviously being (mis)used as a more generic "stuff anything else that we want to bring up to date if we're running slow in here" routine...