Do you like the new SDL input?

[fromhell]

We'll need this poll to show that we don't like it. Hey, i don't like it either, but to keep up with security updates I have to have the old feel sacrificed, i don't have a choice

[pikaunforgiven]

mind sharing the actual security issues (with urls for evidence) in question as to why SDL was forced upon us?  also enlighten us as to why the old method is apparently "so bad" it needed to be scrapped altogether instead of fixed. i for one would like some answers, and im sure others who have experienced the same problems do too.

any programmer ive ever talked to (probably 5 of em) has told me SDL is absolute crap for heavy load uses such as gaming, and my experience with open arena and other games that use SDL seem to agree. now granted im no programmer, im just going by what others ive talked to have told me and personal experience.

[sago007]

mind sharing the actual security issues (with urls for evidence) in question as to why SDL was forced upon us?  also enlighten us as to why the old method is apparently "so bad" it needed to be scrapped altogether instead of fixed. i for one would like some answers, and im sure others who have experienced the same problems do too.

It is not forced open anyone, you are free to use another binary if you want. I even provided version 1.34 (the last version with legacy input) not long ago.

The old engine used 3 different methods for handling mouse input (with individual hacks), the ioquake project hopes to simplify matter by merging them to one.

any programmer ive ever talked to (probably 5 of em) has told me SDL is absolute crap for heavy load uses such as gaming, and my experience with open arena and other games that use SDL seem to agree. now granted im no programmer, im just going by what others ive talked to have told me and personal experience.

SDL is an excellent API specially optimized for games. It contains several ways of reading input and processing data (some for slow games, some for action games). The default way of handling input might not fit in the engine at the moment but with the other two inputs gone, there should be hope for the future.

There is no way around SDL for cross platform gaming.

[pikaunforgiven]

dunno, to me the old input method worked just fine in windows and linux. what i want to know is why we absolutely have to have sdl in the official binary even though its buggy and nobody seems to like it. could have just as easily used the legacy input binary in the official release instead and all would have been well. some other games even provide multiple binaries (one sdl, one not for example) just because they know things like sdl dont always work as expected on every system.

There is no way around SDL for cross platform gaming.

not at all true, there are many other open source methods available that work just as well if not better, sdl just happens to be the most well known. the ioquake people could have even just unified the original code or wrote their own input library, but unfortunately they didnt.

i know i seem to be highly critical and im sorry for that, but if i dont speak up nobody else will.

[fromhell]

Maybe there could be a tiny engine-only patch for those out there who absolutely hate the SDLness. It WOULD NOT be a version increment, though.

I've also noticed the new binary uses a smaller heapsize, causing OA to quickly run out of memory when like loading more than 5 player models.

[pikaunforgiven]

i'd be satisfied with that. all we really need is a separate non-sdl client download (even if it is just a binary) that is on parity with the current sdl one for the majority of us who have problems with the sdl client. maybe a disclaimer on the download page that says "download this binary if you are having problems with the current SDL-based client" or something too so people dont have to be constantly searching the forums for the url.

i havent really noticed any memory related problems so far using the max amount of bots allowable offline in different game modes, unless the performance problems most people including myself experience are related to it.

[Lemonzest]

I LOVE the new SDL Input, much smoother and I can rail a gnat from across the map (wrackdm17)

[Fitacus]

I don't feel any change in comparison to the old mouse input. Maybe bcuz I play in_mouse -1?

[aantipop]

i cant play with the  new sdl input. its hard to describe but i will try: if i move my mouse fast in circles for example, and then stop moving it, the crosshair still moves a while, looks like its processing the input queue, but not in realtime, its like lagging behind. not noticable when i dont move my mouse fast, though. when i changed in_mouse -1 things got even worse (shouldn't this variable loose its effect now).
i also noticed that some keys did not work when moving the mouse from time to time
so i would be happy about a engine-only patch, since there are some bugs with the combination i use at the moment (0.7.0 binary with 0.7.6 game-data), like smarine model not working :/

edit:
its much better with m_filter 1 and maybe r_finish 1, but im not sure about the impact of syncing every frame. i had to increase my sensitivity..but still its not noticing all the input i give :/

[Fitacus]

Look wot I've found @ http://svn.icculus.org/quake3/trunk/README?revision=1312&view=markup ->  cl_platformSensitivity - read only, indicates the mouse input scaling
                                     
So mayb this has something in common with the new mouse behaviour? The readme only gives a description concerning the SDL Keyboard Differences.

[BrainChemistry]

SDL is a good choice but it shouldn't prevent someone from playing. Do you really expect no similar problems when using other cross platform libraries? The way to unify the input routines for any system is desired, especially for the programmers. Maybe they can fix this.

For me there is no difference in accuracy and speed btw.

[jackthompson]

i had a look at the code and cl_platformSensitivity is just multiplied with the sens value... probably to compensate for missing platform sensitivity that SDL might bypass on some OS depending on which API or layer it uses to access the mouse input...

it just scales... but it does not fix the deceleration when someone moves the mouse very fast... mouse lag is the result on slow(er) systems... it happens IMO because SDL lacks what the original input code had...

from code/unix/linux_glimp.c (ioquake3 svn revision 1160)

Code:

// Time mouse was reset, we ignore the first 50ms of the mouse to allow settling of events
static int mouseResetTime = 0;
[...]
#define MOUSE_RESET_DELAY 50
[...]
mouseResetTime = Sys_Milliseconds ();
[...]
t = Sys_XTimeToSysTime(event.xkey.time);
[...]
if (t - mouseResetTime > MOUSE_RESET_DELAY )
{
  Sys_QueEvent( t, SE_MOUSE, mx, my, 0, NULL );
}

if i understand this code right it practically flushed the mouse input queue every 50ms... this code has been replaced by SDL... SDL doesn't flush the input every 50ms and so, i guess, fast moves can cause input lag on slow(er) systems because, now, every single input is processed by the engine... so people with different hardware will experience different input lag (or deceleration on fast moves) now... people with fast(er) systems probably won't notice a difference at all since the engine has no problem processing and displaying even very fast input from a queue that isn't flushed every 50ms... using a 2000dpi mouse with a 1kHz pollingrate on the usb port on a slow(er) system might result in the worst input lag...

someone tell this the ioq3 team... i'm not interested in reading their statement how much easier SDL it makes to maintain the code instead of the old input code (which did work, btw)...

then again... i might be wrong... and something else is the cause...

[fromhell]

I'd tell them, but i'm a 'f0rqu3-lackey' to them because I don't pointlessly reject and ban him on my forums and channels and such (because he actually helps rather than give in to trem hype), so i'm null to them.
An ioq3 fork should be done.

[sago007]

because, now, every single input is processed by the engine...

In ioquake3 this is the case. In fact I too considered this to be the problem. However due to some event queue overflowing (if the mouse produced lots of events) I replaced the event code for the mouse. The mouse in the binaries does generate only one event every time input is read by the engine. Mouse/Joypad events are dropped from the queue instantly.

The reason for my change is that some players had problem with Key_Up events not being caught if the queue overflowed causing it to be considered permanently pressed.

[Lemonzest]

Am i the only one who likes the new input code and sago's fix?

[andrewj]

from code/unix/linux_glimp.c (ioquake3 svn revision 1160)

As far as I know, everybody complaining about the new mouse handling are Windows users.  I'm a Linux user and have not noticed any difference between 0.7.1 and 0.7.6 mouse input.

[BrainChemistry]

As far as I know, everybody complaining about the new mouse handling are Windows users.

I am Win user and like the new input since it is no difference for me and I know SDL is a good choice for independent platform applications. My system is old at all (2 GHz, 1,5 GB RAM, Radeon 9600).

[skankychicken]

I once had a problem with the mouse, but it was a bit of blu-tak stuck to the bottom. I didnt notice much difference with the new version. Too busy getting shot probably.

[sago007]

I have looked a little around on the Internet and found that it might be possible to compile a new SDL.dll that has working Caps Lock/Num Lock keys and solve mouse problem.

Caps and Num Lock works in Debian because Debian has 'fixed' the problem. That fix should be possible in Windows too. (The SDL documentation recommends a custom SDL compile if you want to allow Caps Lock to work as a normal button)

The mouse problem might be related to this: http://listas.apesol.org/pipermail/sdl-libsdl.org/2001-December/022048.html It is an old fix, but the problem does sound like the current one. Although since I can't reproduce the bug it is hard for me to tell.

I'll try compiling a version then I get back to my home computer.

EDIT:
I have compiled a custom SDL.dll:
The file: http://brie.ostenfeld.dk/~poul19/public_files/SDLalternative.zip
The source: http://brie.ostenfeld.dk/~poul19/public_files/SDLalternative-1.2.13.zip

[iLeft.bye]

it only effects windows afaik. I like the way how they increase the portability of the q3 while killing its nativeness . I wonder how long they will continue playing the three monkeys
three monkeys: google link for you
http://images.google.com/images?q=three+monkeys

[kernel panic]

No, I don't like the new mouse input. Actually, I find it so bad that it completely kills the game for me, transforming it in a crappy shoot'em up'n'run. All strategy and freedom of movement gone.

it only effects windows afaik

You don't know much. Many of the people experiencing problems are on Linux.

I don't feel any change in comparison to the old mouse input. Maybe bcuz I play in_mouse -1?

Maybe, and I hope so. I've been told in IRC to try it out and so I did. Hard to tell for the sensitivity changes depending on the method used and I had already screwed the settings up trying to tame the new mouse handling, but it seems to get better. Perhaps it was a matter of faith more than anything else, I'll check more thoroughly with some online matches.

I still don't get why ioquake3 people scrapped a perfectly working code and replaced it with shit, especially given the critical importance of the issue for the games based on 'their' engine. If they don't play perhaps they should be developing other stuff, reading poetry or playing chess. I don't get either the apologetic posture of some of those who don't notice anything due to pure luck or lack of perception.  Portability? What, we couldn't play OA in Windows and Linux before they snafued all up?
 

[jackoverfull]

i suggest you also to lower the texture detail: oa is more demanding than q3 and 0.7.6 is (at least for me) more demanding than 0.7.1, it lagged a lot with my old graphic config.

[Blaenk]

Had to login to mention how ignorant this comment was:

any programmer ive ever talked to (probably 5 of em) has told me SDL is absolute crap for heavy load uses such as gaming, and my experience with open arena and other games that use SDL seem to agree. now granted im no programmer, im just going by what others ive talked to have told me and personal experience.

Many games use SDL especially for Linux ports of games, including triple A games like ET/ET:QW, UT2K4, UT, UT2K3, Doom III, Quake 4, and many more. Also, how can you claim to know by 'personal experience' when you said you weren't even a programmer?

If you guys are wondering how the 'negotiation' between you guys and the IOQuake3 developers are going, read the thread from the mailing list archives.

[skankychicken]

i suggest you also to lower the texture detail: oa is more demanding than q3 and 0.7.6 is (at least for me) more demanding than 0.7.1, it lagged a lot with my old graphic config.

oh great.. just when i get my config right theres more glitter. how do i disable all this shit and see what the gameplay is like?

I love art and design with all the effects, but i also like to play with weapons and  not a panoramic kodak to run around taking snap shots.

[Fitacus]

I don't get either the apologetic posture of some of those who don't notice anything due to pure luck or lack of perception.

Lack of compassion that you don't have got the right mouse which compensates the sdl input crap