Fast mouse movement goes undetected

[Henry00]

Hello everyone!

For some reason (this goes for all the demos as well) no matter whether full-screen or windowed moving the mouse cursor very fast (settings in windows and alike) causes the mouse movement to not be registered. Everything just stops moving until you slow down. I feel like this should be reported in the bug section unless it's my fault.

Thanks!

edit:
This is happening to me with my current mouse settings because I like a fast cursor and is something that could cause issues for others playing my game.

[Samuel]

I also prefer a faster mouse cursor and have had similar mouse issues when using the screen mouse commands.
I've also seen similar problems in some fairly recent games (The Elder Scrolls V anyone?).
Not sure why these issues exist.

It seems using Purebasic's WindowMouse commands or API calls you can collect and update your mouse cursor a lot faster. Same goes for mouse clicks.

Give this code a try. For me it runs faster than using the screen mouse.

Note: ShowCursor_(0) will only work on Windows. If you're on a different OS then you'll have to look up the command to hide your cursor.

Code: Select all

If InitEngine3D() = 0
  End
EndIf
If InitSprite() = 0
  End
EndIf
If InitKeyboard() = 0
  End
EndIf

Enumeration
  #Window
  #Camera
  #SpriteCursor
EndEnumeration

WindowW = 800
WindowH = 600

If OpenWindow(#Window, 0, 0, WindowW, WindowH, "Mouse Testing : Press Escape to Exit", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  If OpenWindowedScreen(WindowID(#Window), 0, 0, WindowW, WindowH)

    CreateSprite(#SpriteCursor, 32, 32, #PB_Sprite_AlphaBlending)
    StartDrawing(SpriteOutput(#SpriteCursor))
      Box(0, 0, 32, 32, RGB(255,128,255))
      Box(14, 0, 4, 32, RGB(255,255,255))
      Box(0, 14, 32, 4, RGB(255,255,255))
    StopDrawing()
    
    TransparentSpriteColor(#SpriteCursor, RGB(255,128,255))
    
    CreateCamera(#Camera, 0, 0, 100, 100)
    CameraBackColor(#Camera, RGB(40,40,40))
    
    ShowCursor_(0)
    
    Repeat
    
      Event = WindowEvent()
      
      ExamineKeyboard()

      WinMX = WindowMouseX(#Window)
      WinMY = WindowMouseY(#Window)

      RenderWorld()
      DisplayTransparentSprite(#SpriteCursor, WinMX-16, WinMY-16)
      FlipBuffers()
    
    Until Event = #PB_Event_CloseWindow Or KeyboardReleased(#PB_Key_Escape)

  EndIf
EndIf
End

[Henry00]

When OGRE's frame-rate drops so does the mouse detection. When you end up with 5 fps you can forget mouse movement being picked up by the engine in general. I have yet to try the mentioned solution (I did that in C# though and it's perfect).
Although this should be fixed... I cannot expect everyone that wants to play my game to change their mouse settings.

[DK_PETER]

When OGRE's frame-rate drops so does the mouse detection. When you end up with 5 fps you can forget mouse movement being picked up by the engine in general. I have yet to try the mentioned solution (I did that in C# though and it's perfect).
Although this should be fixed... I cannot expect everyone that wants to play my game to change their mouse settings.

If framerate drops to 5 fps (unplayable), then you've created a 'bottleneck' somewhere or doing way too much.
However, without any code it's impossible to determine where the problem lies.
Furthermore it's actually quite normal to add an ingame option for mouse speed changes.

[luis]

Furthermore it's actually quite normal to add an ingame option for mouse speed changes.

The ingame options are to change the mouse sensitivity from the point of view of the game engine altering the way incoming data is processed, what Alexi suggested was to change the DPI in the mouse driver settings, changing the rate of the output data, and that's what Henry00 find not very practical.

I have a different mouse, and I remember using it with the PB ogre demos and I can confirm it was not working well at all, sluggish, unresponsive, etc.
The FPS were perfectly normal (high).

Since I'm not interested in using PB ogre I didn't spend time any more time on it, don't know if it can be fixed through PB code (so the demos are at fault) or not but I can confirm it, and changing the DPI settings somewhat helped.

Elsewhere the mouse always worked with no problems.

[DK_PETER]

Furthermore it's actually quite normal to add an ingame option for mouse speed changes.

The ingame options are to change the mouse sensitivity from the point of view of the game engine altering the way incoming data is processed, what Alexi suggested was to change the DPI in the mouse driver settings, changing the rate of the output data, and that's what Henry00 find not very practical.

I have a different mouse, and I remember using it with the PB ogre demos and I can confirm it was not working well at all, sluggish, unresponsive, etc.
The FPS were perfectly normal (high).

Since I'm not interested in using PB ogre I didn't spend time any more time on it, don't know if it can be fixed through PB code (so the demos are at fault) or not but I can confirm it, and changing the DPI settings somewhat helped.

Elsewhere the mouse always worked with no problems.

@Luis
I know what he meant..
I can't recognize this behaviourm though. I got a Logitech G602 set to 2500 dpi.
If using the normal MouseDeltaX() and MouseDeltaX(), the mouse moves too fast (skips).
Changing (decreasing) the values of the above functions can slow the movements considerably
and thereby behave smoothly. This can be done without changing the mouse dpi. (At least...It works for me).

[Henry00]

This can be done without changing the mouse dpi. (At least...It works for me).

I tried this but that didn't change the hanging until you slow down. Even if it did the Window3D mouse cursor still gets stuck.

[PMV]

Maybe this will help you, just try my code from that (german) thread:
http://forums.purebasic.com/german/view ... =4&t=25908
(don't know if this code still works with latest version)

High DPI Input needs to be called much faster then screen. If not, there is no high DPI.
So, if you want to use high dpi input, you must use threads.

MFG PMV

[Henry00]

Very nice solution PMV, bit worried about the fact there isn't a single mutex in place but the concept is clear and it works perfectly with my mouse!
Too bad the PureBasic functions aren't doing this kind of setup by themselves. Many thanks you saved me a lot of trouble!

[Danilo]

Just got a Logitech Performance MX because my very old mouse didn't work anymore correctly,
and the PB 3D examples work fine with it.
At which sensor resolution (DPI) does the problem occur? 1000 DPI? 1500 DPI?

[Henry00]

Just got a Logitech Performance MX because my very old mouse didn't work anymore correctly,
and the PB 3D examples work fine with it.
At which sensor resolution (DPI) does the problem occur? 1000 DPI? 1500 DPI?

I am using the G502 Proteus Core. I cannot say for sure and indeed at many other computers with various common mice (school, work, etc.) I am unable to get OGRE to hang, yet at home it's slow boring mouse movement that already stops OGRE from responding. I am going to make PMV's solution a configurable setting or even the primary input procedure in my game engine.

[PMV]

By doing that, consider to make an event-system for mouse-buttons and wheel.
Otherwise there is a chance, that clicks and wheel-changes will get lost inside of
this thread. Especially on low FPS.

MFG PMV

[Azur]

Hello.

I had the same problem.

http://www.purebasic.fr/english/viewtop ... ming+mouse