Alpha Centauri - Mouse jumps during movement instructions

[vv221]

In Alpha Centauri, one way to give a movement instruction to a unit is to press the left mouse button, move the mouse while keeping the button pressed, and releasing it when the cursor is over the destination tile.

With a real libSDL-1.2.so.0 library, this works as expected.

When libSDL-1.2.so.0 is provided by sdl12-compat, an unexpected behaviour happens: when the mouse button is pressed, the cursor jumps to another part of the screen, leading to unexpected movement instructions if the mouse button is released to early. You need to first move the cursor back to where you want the unit to go before releasing it.

The mouse cursor does another jump when the mouse button is released, but this has no big impact on gameplay because it seems to happen after the movement instruction is given to the unit.

System details

I got the same behaviour on two distinct systems:

• Debian Bookworm
• sdl12-compat 1.2.60
• SDL 2.26.5

• Debian Trixie/Sid
• sdl12-compat 1.2.64
• SDL 2.28.3

Apha Centauri setup

The build I tested has a slight difference with the out-of-the-box Loki version: to avoid the requirement on old compatibility libraries, a small shim is preloaded that allows it to run on top of current libraries.

The game is run from the dynamic binaries (smac.dynamic), not the static ones.

Here is a copy of the shim:

#define _GNU_SOURCE

#include <stdio.h>
#include <stdlib.h>

void *__builtin_new(size_t size)
{
    return malloc(size);
}

void __builtin_delete(void *ptr)
{
    free(ptr);
}

void *__builtin_vec_new(size_t size)
{
    return malloc(size);
}

void __builtin_vec_delete(void *ptr)
{
    free(ptr);
}

And its source: https://github.com/ZeroPointEnergy/smacshim

[sulix]

I can reproduce this here. It seems to only occur when running fullscreen — the game's fine windowed. This is partly because the game normally uses a hardware cursor, but switches to a software one (and relative mode?) when moving a unit this way. Since the game is pillarboxed in fullscreen, this makes me suspect the mouse scaling. SDL_MOUSE_RELATIVE_SCALING has no obvious effect, so it might be something subtler.

Indeed, removing the extra code to reset the position in UpdateRelativeMouseMode seems to fix this, so maybe there's something funny going on in SDL2's logical scaling with SDL_GetMouseState(). Apparently that was added to handle Wolf4SDL, and I know there are a few other games which try to synchronise the position of a hardware / software cursor, so this merits further testing.

[vv221]

It seems to only occur when running fullscreen — the game's fine windowed.

Thanks for the tip, it works fine here. I will use that combined with tweaking the desktop resolution to approximate a fullscreen mode until a more durable fix can be found.

[sulix]

So this appears to be caused by our using SDL_GetMouseState() when entering relative mode, despite SDL_GetMouseState() returning raw coordinates (without SDL_Renderer's logical scaling applied). All the other coordinates we get from the message queue, which is scaled by a filter, and then track ourselves anyway.

PR #320 fixes this for me. We could call SDL_RenderWindowToLogical() instead, but personally I think relying on the message queue for everything is cleaner. Happy to change it if you prefer, though.