hello ports@, these aren't entirely 'important' ports, but between my port of chocolate-doom and the existing port of prboom (AND the update to prboom 2.5.0 i have) have been seeing some weird mouse input issues. Unfortunately during the past 8+ months I spent much time away from watching changes in obsd for awhile, and at a certain point mouse input in chocolate-doom became almost unusable.
basically, run chocolate-doom in fullscreen using a mouse, and notice how when you go to turn the player as you're moving around, the mouse is -extremely- choppy. standing in one spot and turning shows the problem a bit, as soon as you start to move and turn the player model almost doesn't turn at all. I tested this with prboom as well as they share sdl for input functions and at first i thought it wasn't affected. However after I enabled the framelimit cap in prboom to match what doom used to run at, the mouse input for it too started to show, to a lesser extent, these signs. Before even investigating PrBoom I had run back through all my previous version of chocolate-doom ports to see if anything in it had changed causing the issue, but no all my previous ports back to 1.2.1 exhibit this same issue. I spoke with Simon Howard (author of chocolate-doom) to see if he had any suggestions of where to look, knowing the issue probably had nothing to do with his program at this point, and he did bring one test-case to the table that made a difference: running chocolate-doom as follows; $ chocolate-doom -window -nomousegrab this of course disables the game from capturing mouse input. moving the mouse over the window while the player is moving/turning seems to actually work fine outside of the fact that it doesn't seem to take long to leave the window and lose focus/mouse movement again. As said in the first paragraph I hadn't been paying enough attention to changes and i am unable to figure out at which time a change occurred...be it in xenocara or sdl...thinking xenocara since we still run a much older version of sdl... that caused erratic mouse behavior in fullscreen applications that expect full mouse control. OpenGL apps don't do this, ioquake3 etc all seem to be fine at this time. I noticed while i used to use SDL_VIDEO_X11_DGAMOUSE to fix a choppy mouse issue a long time ago, setting that environment var either on or off seems to make no difference anymore. I am not sure what other ports may be affected by this but I figured late is better than never, and hours and hours i've spent changing this/that trying to rectify chocolate-doom mouse behavior have left me empty handed. I'm hoping any resident x11/sdl gurus may be able to recall some changes that may have resulted in this behavior. If it helps at all, I at least know all year this year this behavior has been happening (i know, bad ryan for not reporting sooner :/) Also I would love any replies saying that your install works fine and its just me ;) Cheers, -ryan PS. after reading back over my descriptions, the fact that prboom seems mostly fine as long as it is set for no framelimit cap makes me curious as to what would actually happen in something like ioquake3 if i were to set the cap low like the original doom was. could this mean timers in the game to manage framerate are clashing with input updates from mouse? keyboard turning naturally works just fine.
