Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Grader

Members
  • Content count

    10
  • Joined

  • Last visited

About Grader

  • Rank
    Warming Up
  1. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    My guess is - you changed the code so that calling SDL_GetRelativeMouseState(&x, &y) and centering the mouse is done more often and results are accumulated untill next calling of D_PostEvent(&ev), right?
  2. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    My bad :( Misunderstood you. mouse_accumulate_motion is added and set to 0 by default. Setting it to 1 DID help! You did it, man, thanks! :)
  3. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Yep. It's still has it. But I guest it's fine, since you always can set 1280x1024 and/or lower mouse resolution... And maybe add this to FAQ...
  4. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    So you are saying that when WINDIB is used there's no way around to "free" the cursor?
  5. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Yep, odamex also has this flaw - tested it with logitech g9 today. And yes - -derectx helps. Btw, there did you find command line switches for odamex? Distro doesn't have it and I browsed http://odamex.net/ for half an hour without luck =) Also tested logitech setpoint software - it does allow lowering sensetivity. So basically "Windows GDI" SDL driver is also playable, providing you lower sensitivity via supplied drivers and set resolution 1280x1024 and higher. I guess using old optic mice like MX510 with 1280x1024+ is also a solution. But I'm goning to report this bug to SDL developers anyway. Unfortunately, it is well may be design flaw of windows gdi and not the SDL problem at all.
  6. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Man, I've modified choco's sources to log mouse movements, don't you think I know that kind of stuff too? ;) It was disabled for years already :)
  7. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    :) Resolution can be set via chocolate-doom.cfg. 320x200 was used to confirm the theory behind the bug. Anyway, 640x480 should be available via setup. High DPI mouse (razers, g5/g9) + 640x480 + prDoom/choco(GDI) = 180 angle rotation fail. Tested on core2duo E8400 / geforce 275gtx / WinXP SP3 / razer daimondback and core2duo E6300 / geforce 8800gt / WinXP SP3 / logitech g5. A friend of mine tested it on his rig with g5 too and also confirmed "slips" when GDI driver is used.
  8. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Acceleration is, of course, disabled - mouse_acceleration 1.000000 mouse_threshold 0
  9. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    DOS exe works ok. Anyway, I've tested it more and found out that: 1) logitech BT58 = FAIL, it "slips" even in windows; 2) prDoom+ has those mentioned problems and I found two solutions: a) set higher resolution; b) set lower "master" sensitivity via mouse drivers (works fine with razer diamondback, logitech g5 & g9 have built-in feature - DPI switch) 3) choco-doom both have this problem and not, depending on the video driver selected (!!!): a) DirectX = fine, no problem, except that it feels kinda laggy even when played solo; b) Windows GDI = BUGGED, lowering sens in drivers and getting resolution up helps. YET has faster responce and no lag. Actually, that's exactly why I stucked with the bug in the first place - I've switched the driver, liked faster responce of it and kept it. Anyway, it's definitely SDL bug that appears when Windows GDI driver is used. I guess it should even be bug reported...
  10. Grader

    Mouse in SDL Ports (Choco, EE, Odamex, PRBoom)

    Hi. Having the same issues here with latest versions of choco & prDoom+ The bug can be easily reproduced: set resolution to 320x200 and fullscreen, then try to move mouse fast as you usually do to rotate 180 degrees. The game won't - you'll end up much less or with no rotation at all. So, I got deep into the code... Both into choco & sdl 1.2.14. Made a simlple mods to the choco's code to see how much of an x movement is recieved. And you know what? It is limited to the resolution: for 320x200 it is [-160;159], for 800x600 it is [-400;399] and so forth... So, if the mouse responsiveness (dpi) is high, like logitech g5/g9, the game becomes unplayable, unless you set hi-res, like 1600x1200+... Bug appears when mouse cursor coords try to go over "screen limit" - movement is just trimmed. Choco and prDoom+ behave simularly in that aspect, so it is the SDL problem. Digging into SDL sources now, trying to take off those limiters, but there's no luck for know...
×