[rcore][SDL] Relative mouse motion is overwritten in event loop

[goob228]

Please, before submitting a new issue verify and check:

• I tested it on latest raylib version from master branch
• I checked there is no similar issue already reported
• I checked the documentation on the wiki
• My code has no errors or misuse of raylib

Issue description

Relative mouse motion is frame-rate dependent when using the SDL backend with the cursor disabled. I noticed this after switching to SDL from the GLFW backend in my fps game project. It turns out that raylib overwrites relative mouse motion with the last SDL_MOUSEMOTION event in while (SDL_PollEvent(&event) != 0) loop. It should accumulate xrel and yrel instead. I can submit a PR with the fix.

Here:

raylib/src/platforms/rcore_desktop_sdl.c

Lines 1735 to 1742 in a365e56

	case SDL_MOUSEMOTION:
	{
	if (CORE.Input.Mouse.cursorLocked)
	{
	CORE.Input.Mouse.currentPosition.x = (float)event.motion.xrel;
	CORE.Input.Mouse.currentPosition.y = (float)event.motion.yrel;
	CORE.Input.Mouse.previousPosition = (Vector2){ 0.0f, 0.0f };
	}

Environment

• PLATFORM_DESKTOP_SDL
• GRAPHICS_API_OPENGL_33
• Windows 11 Pro
• MSVC 19.51.36257 for x64

Issue Screenshot

If possible, provide a screenshot that illustrates the issue. Usually an image is better than a thousand words.

Code Example

Provide minimal reproduction code to test the issue. Please, format the code properly and try to keep it as simple as possible, just focusing on the experienced issue.

Any code that uses Vector2 GetMouseDelta(void); function with the cursor disabled.

Below is a slightly modified core_3d_camera_free.c example which allows toggling FPS on and off to reproduce the issue.

#include "raylib.h"

int main(void)
{
    const int screenWidth = 800;
    const int screenHeight = 450;

    InitWindow(screenWidth, screenHeight, "raylib [core] example - 3d camera free");

    // Define the camera to look into our 3d world
    Camera3D camera = { 0 };
    camera.position = (Vector3){ 10.0f, 10.0f, 10.0f }; // Camera position
    camera.target = (Vector3){ 0.0f, 0.0f, 0.0f };      // Camera looking at point
    camera.up = (Vector3){ 0.0f, 1.0f, 0.0f };          // Camera up vector (rotation towards target)
    camera.fovy = 45.0f;                                // Camera field-of-view Y
    camera.projection = CAMERA_PERSPECTIVE;             // Camera projection type

    Vector3 cubePosition = { 0.0f, 0.0f, 0.0f };

    DisableCursor();                    // Limit cursor to relative movement inside the window

    int targetFPS = 60;
    SetTargetFPS(targetFPS);

    // Main game loop
    while (!WindowShouldClose())        // Detect window close button or ESC key
    {

        if (IsKeyPressed(KEY_SPACE))
        {
            if (targetFPS == 0) targetFPS = 60;
            else targetFPS = 0;
            SetTargetFPS(targetFPS);
        }

        UpdateCamera(&camera, CAMERA_FREE);

        if (IsKeyPressed(KEY_Z)) camera.target = (Vector3){ 0.0f, 0.0f, 0.0f };

        BeginDrawing();

            ClearBackground(RAYWHITE);

            BeginMode3D(camera);

                DrawCube(cubePosition, 2.0f, 2.0f, 2.0f, RED);

                DrawGrid(10, 1.0f);

            EndMode3D();

            DrawFPS(10, 10);
            DrawText("- Z to zoom to (0, 0, 0)", 40, 80, 10, DARKGRAY);

        EndDrawing();
        
    }

    CloseWindow();

    return 0;
}

In PLATFORM_DESKTOP_SDL camera rotation slows down when FPS is capped but works normally with unlimited FPS, unlike PLATFORM_DESKTOP_GLFW where it works fine in both cases.

[goob228]

Sorry if I am missing something, because I couldnt find anyone reporting it yet. By the way, here is the commit d7a098e where this code

               if (platform.cursorRelative)
                {
                    CORE.Input.Mouse.currentPosition.x = (float)event.motion.xrel;
                    CORE.Input.Mouse.currentPosition.y = (float)event.motion.yrel;
                    CORE.Input.Mouse.previousPosition = (Vector2){ 0.0f, 0.0f };
                }

was added.

[raysan5]

@Bigfoot71 please, could you take a look to this issue if you have some time? It seems related to a PR you send some years ago...