https://gitlab.synchro.net/main/sbbs/-/commit/ea7b94702b931de835f5ab17
Modified Files:
src/doors/syncdoom/syncdoom.c src/doors/syncduke/Game/src/config.c player.c src/doors/syncduke/syncduke_input.c
Log Message:
SyncDOOM & SyncDuke: terminal-mouse FOLLOW (relative mouse-look) mode

Terminals report only absolute, screen-clamped cell coordinates -- no
relative motion, and the host can't recenter the pointer -- so the
existing STEER model turns the player by the pointer's offset from the
image centre (a virtual joystick). That never runs out of travel but
keeps turning while the pointer sits off-centre, which some players
dislike.

Add FOLLOW as a second, opt-in style: turn by the pointer's change in
column since the last game tic, so the view stops the instant the
pointer stops -- the DOS-game mouse-look feel. Because the coordinates
are absolute and clamped, a pointer pinned at the window edge would
otherwise stall; a slow edge-creep (bounded by the idle timeout) lets a
big turn finish anyway. The delta reference re-anchors after an idle gap
so a resumed pointer doesn't lurch.

Ctrl-O now cycles OFF -> STEER -> FOLLOW -> OFF (was on/off), and the
mode persists per-user: SyncDOOM [input] mouse = off|steer|follow (with
"on" accepted as a legacy alias for steer); SyncDuke [SyncDuke] MouseMode (legacy MouseSteering still honored). SyncDuke's existing sensitivity
slider scales both styles.

SyncDuke's player.c getinput() drains a per-tic delta accumulator (syncduke_mouse_turn_tic) rather than reading the steer level; config.c persists MouseMode; the on-screen flash names the mode.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)