#591 mouse slowdown

Always occurs!
Win32 (67)

this might be a tough one. I've noticed this before, but not as pronounced. It has occured in all the alpha builds for windows, but possibly not in 132 beta. I'm running winxp, 2.5 gig processor, with 256mb ram, and 64 mb video memory, on my ati card. I do have a rather unusual setup for my keyboard, mouse, and moniter, a kvm switch, which at times is a bit quirky, but with doom seems to always run perfectly. It allows me to run the comp described above with an old win95 comp with all the updates available on the planet, and a voodoo 1 card. I still run some games requiring 3dfx acceleration, so I keep it. Although it has dos, dos box on the new one runs them better. Sorry for veering off the topic. I can only describe this "mouse slowdown" as such. Basically it's a change in the sweep of the mouse vs. distance covered, most noticable in the x axis . the slowdown occurs when there is a lot of graphic activity ( I think) usually large detailed spaces, or small confined "busy" areas with lots of graphics and animations. Where the graphics are in normal quantity, say for arguments sake, the first level of doom2. One swipe of my mouse, with adjustments @ mousesensy "12"
mousesensx "15" will completely reverse my position on the x axis. When experiencing this "mouse slowdown" the same swipe will only move my position 1/2 the distance it did before. So it will take 2 swipes of the mouse to completely reverse my position. I hope that explains the problem clearly enough. While this is happening, there is NO, I repeat NO, slowdown of any other sort in frame rate. Its only the Mouse. I've noticed this in various wads described in the forum, but never mentioned it before because I felt it might be my system. But maybe not. Almost like in certain games you have the option of putting "mouse filtering" on. This is kind of the same effect, but only occurs during times of intense visuals. The most recent wad, I've always wanted to try, is called bludwrks. Here is a link http://www.doomwadstation.com/descent/bludwrks.zip ...... this version is for legacy. When you run it, (using alpha 3 for windows, here) , it begins to load, and then seems to stop. It takes my comp approx 2 minutes for it to finally startup, and begin the actual level, after the loading screen... so you just have to sit there and wait....it starts in a blackened tunnel, and you go forward to the first area, where I experienced much of this "mouse slowdown". Alpha 3 renders it beautifully in opengl. I also noticed something strange with the y axis opening position. It always seems to open up about 45 degrees straightup. If you're unaware of this, it can be disorienting.. so just lower your y axis, and move straight ahead. this may be a separate bug for a separate bug report, but I figured I'd mention it here because it's related. As I've said, its not only in this wad, but many other intense/outdoor/indoor graphical wads.,with lots of animation. It is not necessarily related to many enemies. As a matter of fact, I don't think the number of enemies appearing on screen at the same time really has any affect at all. It's something else. Curious to see if anyone else has ever experienced this problem. Thanks


  • Andrew

    Andrew - 2011-09-08

    Sorry, forgot to add this bit of information. I always hate to do it, because legacy is the port of choice for me, no questions asked. but.... when running this wad, bludwrks, ((the same version)), with gzdoom, the y axis does not begin 45 degrees up, and there is no mouse slowdown at all.

  • Wesley Johnson

    Wesley Johnson - 2011-10-01
    • priority: 5 --> 3
  • Wesley Johnson

    Wesley Johnson - 2011-10-01

    Tried bludwrks.wad. Very interesting effects. Appears to work fine on my Linux 2.4 (32bit) machine. No mouse slowdown detected.
    I do not have a windows machine that runs DoomLegacy, and it would probably behave differently from yours anyway.

    Which windows ?? Win98, XP, Vista, S7 ?
    Have you tested with software render to see if it also occurs in those conditions.
    Does simpler wads do it, and is it related at all to wad complexity ?

    Most likely the mouse update handler (in SDL or the system) is being preempted by heavy video card use, and it is missing mouse interrupts/events. This could be very specific to windows and your machine.

  • Andrew

    Andrew - 2011-10-01

    thanks for the response Wesley. I'm using windows XP Service pack 3. As I've stated , this "mouse slowdown occurs generally when there is a lot of animation with 'effects'. I get the feeling , legacy for windows, opengl, is not rendering quickly enough, as it lags. Very weird though, as there is not a drop in the frame rate, only the mouse. It never occurs when backgrounds are simple, or if you exit say from a 'busy' area to a less animated area. The mouse picks up immediately. It does occur in software too, but not as bad. As I've mentioned before, and I hate to make comparisons, but when using gzdoom, in opengl with my same system, same wad, same map, same area... no mouseslowdown, no matter what I try to do. Maybe its a mousebuffer problem in legacy? Or possibly a memory buffer problem, as Gzdoom runs silky in those same problematic areas. Although , with the generation of cool lighting in legacy, it's possible there might be a larger system requirement, which gzdoom is not asking for. Be interested in hearing your thoughts. Thanks

  • Wesley Johnson

    Wesley Johnson - 2011-10-07

    I play tested bludwrks.wad.
    This is a vanilla doom wad with heavy use of non-standard tricks, like 3D floors.
    It uses overlapping line segments that sector polygon routines do not understand.
    This hides the floor from the drawing routines, but also confuses polygon determination for OpenGL.
    Tricks like these are banned on most large wad projects because they are not reliable on most Doom source ports.

    It works well on DoomLegacy using the software renderer.

    The -opengl renderer is having many problems with the sectors.
    1. Has 63 polygons with more than 256 sides, one with 1363 sides. This is a failure to resolve the overlapping line segments. It is the cause of the long load time.
    2. Many sectors where floors and ceilings fail to draw. Can see sky through the floor.

    GzDoom will have different routines for converting Doom wad sectors to OpenGL polygons, and so its response to a wad that violates standards will be entirely different.

    On Linux:
    1. Starting view is straight ahead, (not 45 degree up).
    2. No mouse slowdown detected. Only slight slowdown when going through blood showers.

  • Wesley Johnson

    Wesley Johnson - 2011-10-07
    • labels: 101189 --> Win32
  • Wesley Johnson

    Wesley Johnson - 2011-10-11

    SDL 1.2.14 reports a fix for mouse responsiveness problem.
    Which SDL do you have?

  • Andrew

    Andrew - 2011-10-11

    The SDL.dll is v , and the SDL_mixer.dll is v
    These are the ones downloaded with the alpha3 for windows.

  • Andrew

    Andrew - 2013-01-05

    I'm not sure what was done to Alpha 4 win32 version using opengl, but where mouse slowdown as described above was present in various wads in Alpha 3, it no longer exists in Alpha 4. Good job Wes!-Fixed

  • Andrew

    Andrew - 2013-01-05
    • status: open --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks