OpenArena Message Boards

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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)

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

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.

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.

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

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.

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

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.

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

it only effects windows afaik. I like the way how they increase the portability of the q3 while killing its nativeness :D. 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

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.


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


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?
 

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.

Had to login to mention how ignorant this comment was:


Many games (http://en.wikipedia.org/wiki/List_of_games_using_SDL) 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 (http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50:mss:2637:200805:enmmbjehfdehgjmjalfp) from the mailing list archives.

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.

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

i've got an expensive mouse and it still is affected by this sdl change

just go in setup>system and lower the texture detail. it was enough to have a decent gameplay for me...

Yes but this is just a bandaid, SDL is not so good eh, it is screwing it up for me too, i never liked it.

The mouse input code has been changed in rev1341 of ioQuake3 (yesterday).

It's supposed to behave exactly like the old windows code now on all platforms.

If you play Q3A take these binaries and test it...

Windows: ftp://ftp.suse.com/pub/people/lnussel/ioquake3/ioquake3-1.35_SVN1341-3.1.x86.exe
Linux: ftp://ftp.suse.com/pub/people/lnussel/ioquake3/ioquake3-1.35_SVN1341-6.1.i386.run

If you play OA use these (only Windows and 64 bit Linux):
http://brie.ostenfeld.dk/~poul19/public_files/oabin-test-2008-05-07.zip

the ioquake didnt change anything for me...

bye...

jack thompson sent me a ioquake.i386 (1.45 rev 1341) for openarena and finally i can enjoy openarena _with_ sdl

And, uhm...is there any possibility that not only Jack and his closest cronies enjoy the benefits of this 'project X' forged in the darkness?

PS. Oh, by the way, the 'mouse input -1' doesn't actually do it...

Look three posts above your own.

Three posts above his own later...


I must be missing something really simple here. I am on 32 bit Linux. Are you suggesting me to use the 64 bit version...? Are they interchangeable? If so, why specifying '64 bit' version instead of just 'Linux' version?

I am not suggesting you use the 64 bit version. I was under the impression that there was no problem under Linux and therefore I didn't look for a 32 bit machine to build on. The 64 bit version is only included because it was simple to create it.

Fair enough, sago. I hope this issue gets solved somehow anyway.

heres a 32bit linux binary to use with 0.7.6:
its ioquake 1.35 svn revision 1341:
http://www.sendspace.com/file/8psl3k

You could try glut. I've just started using it instead of SDL in my programs, so I don't really know if it's too different or better/worse.

or move the id's original GPL release from scons to make, make it compile on Mac again, add the download-to-httpd-redirect, and rightfully claim to be the only game that uses id Tech 3... :D

JACK THOMPSON!!

skankychicken!!!! <3

\:D/

oh god

The input on old Q3 versions is definately slightly different from the latest versions. I havent really checked it out but for sure the earlier version is far superior if so.

It's not a major difference but much easier to control at a slower rate, especially if you slowly decrease mouse movements. I understand people might prefer what they are used to but difficult to describe or say it's worse or better if you didnt have the oppertunity to compare them properly. 

Hello all of you! can anyone help me i'm new here...

http://openarena.ws/board/index.php?board=29.0

I repeat myself => It's all about the preferences

in_mouse -1 = Q3 1.16 feeling
in_mouse  1 = Q3 1.32 feeling

Blame direct input for all your whine! ;)

Here a nice description concerning this cvar

in_mouse -1
Captures the position the Windows cursor and passes that info to the game to change the camera angle. Once that is done for a frame, the cursor is returned to the center of the screen. There is nothing else applied to the data until it gets to the sensitivity, acceleration, m_yaw, and m_pitch part of the code.

Pros: -As responsive as you can get
-It's accurate

Cons: -The cursor can clip the edge of the window and not be able to go further, resulting in negative acceleration. The higher your Q3 resolution and framerate, the less you will run into this problem (800x600 is pretty much safe for any sens, 640x480 might have some clipping with low sens). Higher mouse sampling rates or r_finish should also be used to prevent Q3 from getting 2 or more large mouse samples in one frame.
- Must use CPL mouse fix (or alternative) to eliminate Windows enabling Pointer Prescision automatically for games in WinXP.


in_mouse 1
Uses DirectInput to directly acces the mouse, bypassing the windows cursor. It also applied ~12ms worth of mouse smoothing automatically before reaching the sensitivity and acceleration part of the Q3 code.

Pros: -No negative acceleration
- Works independantly of Windows cursor settings (i.e. sensitivity and Pointer Prescision)

Cons: -Uncontrollable mouse smoothing which adds latency to mouse actions.
- Delay when clicking mouse (click -> wait 12ms -> shoot = bad)

http://www.esreality.com/?a=post&id=1515298

By  arQon ++++ - Reply to #4
Someone's looking at the wrong codebase... :P

1: DirectInput mouse: *by far* the best option
0: no mouse support
-1: WM mouse: crap, still exists solely because it was the pre-1.17 default and the whine was earth-shattering

_____________________________________________________________________


By  cheese81u812 : - Reply to #10
People say there's some automatic filtering when using in_mouse 1, is this true? The aiming feels slower when using it, but that may be in_mouse -1 being kinda twitchy.

_____________________________________________________________________

By  arQon ++++ - Reply to #12
Of course not. It's just one of those absurd stories people like kdawg and Gaz make up to try and convince everyone how clever they are, then other retards repeat it forever as if it was true.

add> and indeed, here's the same lie stated as fact 18 months ago http://www.esreality.com/?a=post&id=1116194 and doubtless every year before that too. sigh.




edit: fyi arQon is the creator cpma and probably the most knowledgable person on this subject.

Fitacus explains pretty much what the differences are accurately, but I have not tried the -1 setting. I dont know who Arcon is but if something is crap then that is NOT a person with knowledge. :D When I can prove it's better for me using defrag maps then if someone tells me it's crap then It does teach me one thing.

Actually the difference is very minimal. I would guess that it might affect users who move the mouse all over the place and have to do it very quickly.

When I played on 1.32 I noticed it really was uncomfortable, or more difficult to slow the mouse at a set point. So I use paper as a mouse pad which was definately far superior than a fabric mouse pad. I compared it doing strafe jumps and with the fabric mouse pad my angle was all over the place. That was because using paper I was able to gently keep the mouse moving for a very slow turn in the air moving at 1 degrees probably about every 0.5 seconds.

With the older mouse input you are better with a normal/default sensitivity and it might take a little more effort to turn at 180 degrees. But with a fast and slow mouse movement you are able to almost stop the mouse but still keep the mouse moving squeezing out more speed - it might only be really noticable for defrag players. On the later versions it is very difficult to do this because it's very easy for the mouse to stop suddenly then you will not be able to move it at such a slower movement.

It might be that some people have had to adjust stuff to what suits them, they might notice it more. But I did not know about that setting and I do reguarly play 1.16 and 1.32. And there are have been at least a dozen people who all mention the mouse issue, the better players notice it right away. Everyone has said the same as me. Maybe if people are so good that they can kill most people with flick shots you might not like people using the older input as they feel that it gives people more control and thats crap when you get killed and your flick shot skills are less effective :D Maybe thats why he thinks its crap

Do you like Defrag's promode physics? It comes from Arqon's CPMA mod. If you're into fancy movement it's pretty cool.

ArQon hates everyone who sticks to conservative things like OSP and eveything which is not that advanced like CPMA. No other things boys and girls ;)

/me ignores missbehaving

You forget arqon helped develop osp fitacus.

Aaah. I get it now.

I like CPM movement. Don't spend alot of time in defrag. That doesn't mean that cpm or vq3 has to be crap. It's not related to this discussion at all. When I first started reading the opinions I trusted they where peoples own opinion and believed the input had got messed up or some bug. It would be good to know if things are peoples genuine opinion or someone elses spam and spread it around like it's gospel.

So.... have anyone tested them? I can't feel a difference but I never had a problem so it would be extremely weird if I did.

But it would sure help to get some feedback on this.

Respect ! Yes you are right. I still love ya tho :D but he is absolutely correct. :D

Haven't seen any Mac OS X reports, but in the menu system the cursor is super slow, and in-game I have to crank the sensitivity up all the way and even that's not close to the feel of 0.7.0. I tried /set in_mouse -1 and there was no change (I tried values from -10 to 10 and there was no diff).

O_o
on os x oa always used sdl..

on my macs i noticed little differences in the upgrade and in the menus i have no problems at all...

i don't think that in_mouse -1 is applicable on os x.

maybe you should try to start with a clean installation. to do so, try to remove the "OpenArena" folder in your home>Library>Application Support.

Thanks for the suggestion, but still have mouse issues. To be fair, I use a Logitech TrackMan, which shouldn't really make any difference to OA. But in 0.7.0 it worked great, and now it's like someone turned the sensitivity all the way down. Even with my MS Laser Mouse the responsiveness is slow and laggy.

also, if I use 0.7.0 with the 0.7.6 pk3s it's fine, so it's definitely an engine change. if anyone has any other suggestions pls post em!

i'm trying to compare 0.7.0's sensivity with 0.7.6 one...

it seems to be some difference, you're right...

the only thing that i can suggest is to setup oa differently.
maybe the devs will have some other ideas.

*cough* Fyi you won't get back your desirable sense if you always played with in_mouse 1 (direct input). But I can tell u that -1 feels exactly the same on each OA versions bcuz it's depending on the OS input (afaik only Windows XP). So I'm sry it's not a proper solution!

Actually there are no longer any difference at all between in_mouse 1 and in_mouse -1 as SDL has replaced them both.

Basically there are two known differences:
Mouse sensitivity is no longer boosted in the input-code (the default mouse speed is cut in half, can be changed ingame)
Mouse is no longer being made forcefully smoother.

What I wonder is why a lot of people being used to in_mouse = -1 is having a problem. There should be no change here except speed and that the mouse ignores all Operating system configurations, but most Quake 3 guides I have found requires those off anyway.

For those of you who feel like the controls are "weird"... Does disabling mouse acceleration in your OS change anything?

Yes I too noticed the difference, it seems it completely corrects the problem for me. If that's really the case, it would explain why some people don't see any difference between OA 0.7.1 and OA 0.7.6 (the ones who disabled mouse acceleration).

Here's a place where you can find patches for Windows XP mouse acceleration:

http://www.zonegamerz.com/content-17.html

It's in French, so here are direct link to the two patches you should use:

http://www.zonegamerz.com/download/mouseaccelXP.zip <- Merge with registry nomouseaccel1.reg
http://www.zonegamerz.com/download/accelfix.exe <- Complementary patch to remove acceleration in win32k.sys

You may have to reboot in Safe Mode before using these patch, but myself I didn't had to. Don't fear to test, you can revert back changes for these two patches.

Feedback people if you test.

This is certainly no "fix", because you have to alter your OS experience... But it's clear that OA's SDL is interacting with a different layer of OS input than it perhaps should.

The problem with Windows is that it has a weird way to manage sensitivity, for example you can't customize mouse acceleration except by tweaking registry, so it's really hard for a program to manage sensitivity between multiple platform with a centralized code, and it seems that's what they are trying to do with ioquake3.

I retested the fixes, and effectively it reduces the problem but there's still a difference between 0.7.1 and 0.7.6 (didn't tested 0.7.7 yet). What is weird is that before I reinstall my Windows XP (I reformat each 2 months :p) I hadn't that problem, my sensitivity didn't changed between these two versions. But now I reinstalled I have the same problem as everyone. So it seems there may be a way to correct this problem, but I don't know at all what I might have done for that (my OA config didn't changed)...

Can we get back to the normal mouse speed for the 0.8.0 release??

It is possible to measure the mouse's effective DPI in game (described here: http://openarena.ws/board/index.php?topic=1863.0 (http://openarena.ws/board/index.php?topic=1863.0)) and I found 0.7.7 to be 33% less than 0.6.0 -- that is more 'steppy'/'jaggy'.

On my Mac the effective DPI is about 100 -- really quite bad, and feels very jaggy.

the bad movement is extremely noticable in extreme low framerates, try 1-7fps for good measure

when playing 0.7.7 mouse input has been extremely difficult to get used to, no where near how it felt in 0.7.1.

in 0.7.1 i had sensitivity 12.5 and mouse acceleration turned off. now i've tried to fiddle some more with the settings in 0.7.7 and made some progress.
using a sensitivity of 9 and a negative mouse acceleration (cl_mouseaccel -0.2) i get something that i can get used to.

so from now on i'll visit some 0.7.7 servers too :)

Thanks for that :) Didnt know there was - accell

I tried 0.7.7 and worked just fine, definately a step in the right direction. I preferred the in_mouse -1 setting. Can anyone remind me what that does?

in_mouse -1 disables direct input => mouse behaviour same to your OS (in WinXP).

The new input TOTALLY SUX!

I just can get aprox 30% of my aiming skill while playing under 0.76 or 0.77.
Its no fun if u aim very good under 0.71 and now be forced to play like a noob only by mouseinput.
I try out many settings to compensate this but no chance. ( sensivity, smouthmouse, mouseaccel etc. )
I nearly hit nothing under 0.76 or 0.77 .... 

Really no fun at all

again you can thank ioquake3.org for going sdl where it's not necessary instead of just fixing bugs

I think that I was actually able to reproduce the acceleration problem people are talking about.

People who have the problem, you should disable mouse acceleration in Windows. It is done in the Control Panel under Mouse settings. Note that 'Enchance pointer precision' is the same as 'Accelerate the mouse'

(http://brie.ostenfeld.dk/~poul19/public_files/mouse_acceleration.PNG)

If people say it solves the problem then a solution might be possible.

This change was put out at the same time as delag. They WILL notice  a difference.

It is impossible to get any decent feedback if you have no idea of someones skill, or what they have been used to using previously.  Servers are now recommended to run at sv_fps 20 or max at 30. Most admins probably realise this but whenever I see someone ask a question, noone seems to know if there is a mod running or not.

The cg_optimiz issue can be very noticable if the sv_fps is greater than snaps or some crap.

But I do think I know what this accell issue is :D Actually, me and sns found we changed a  couple of things then suddenly our whole movement seemed accelerated.

I have a rough idea what it is, but will be reinstalling everything. If an admin log of what we changed in game would help then I will of course, help in any way I can and send it on.

It happened to both of us at the same time and it's a strange one.. you would probably need to read through a whole load of crap. But that would be one issue. Someone else might be playing on a server with 9 maxpackets, rate 25000 and snaps at 94, maybe delag wouldnt affect his mouse now, but it certainly will now




 

----

* topic cleaned of flames and pointless quakelivery *

Not about SDL, but still worth mentioning.  Both on 0.7.0 and 0.7.6/7.

XFree86-DGA is reportedly disabled by default (at least when using xorgconfig or similar).  Looks like this:



However, if DGA is enabled, mouse may be delayed or lagging on high load, including menus.  (This was from running OA with a nice'd bzip2 in the background, on an old Pentium III (yay) -- not sure if this applies on a real computer, hence the "may.")


(Apparently trying to run Open Quartz on glxquake (http://mfcn.ilo.de/glxquake/), which needed DGA enabled.)

Maybe somebody is interested in ready this interesting topic about mouaccel -> http://www.esreality.com/?a=post&id=1268470

----

The new mouse is shit....i cant play new version with such fucked mouse. I hope, it will be normal again. The free movement is totally banned!

i started with oa 0.7.6
i like the sdl input. i tested the binary with 7.1 sens and i was upset, its too high. the sdl feels like my sens in quake3 under windows, so its perfect =)

----

----