1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/doors/syncdoom/syncdoom.c

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sun Jun 28 00:21:32 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/08a80d9075f1cb72d08646d5
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: use shared termgfx_geom_fit/center (phase 2 of the geometry unification)

    SyncDOOM's compute_geometry computed the fit-to-canvas image size and the center offset inline; SyncDuke now calls the same logic in termgfx/geometry.c. Replace Doom's inline math with termgfx_geom_fit() + termgfx_geom_center() so the
    two doors share one implementation instead of parallel copies.

    This is a pure refactor -- verified bit-identical to the old inline code across 8910 (vw, vh, cap) cases, 0 mismatches. The sixel-640 cap selection, the PPM / no-scale-fit branches, and the sixel-without-real-cell-size top-left override all
    stay in Doom (they're tier/door policy around the shared fit/center core).

    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sun Jun 28 00:21:32 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/2c96f1868ad988483e1de4dd
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: client-side sixel scaling (bandwidth reduction, like SyncDuke)

    emit_frame_sixel sent a full-resolution sixel (pan=1) at the display size; now it
    encodes at 1/SIXEL_SCALE and emits the "pan;pad raster aspect so the terminal scales it back up -- SyncTERM integer-doubles (pad=2), other sixel terminals get
    the 2:1 pixel aspect (pad=1). The encoded height is clamped to whole 6-row bands
    (a partial final band garbles under pan>1). Lossless on SyncTERM: Doom's indexed
    buffer (I_VideoBuffer) is natively 320x200, so a SyncTERM frame encodes at native
    res, not a downscale.

    ~1/4 the sixel bytes on SyncTERM (320x198 vs 640x400), ~1/2 on other sixel terminals -- and the two doors now emit byte-identical sixel frames. Reuses the
    shared termgfx sixel_encode_aspect.

    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Sat Jul 4 00:42:13 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/26de4325a8dc95431a70852e
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: decode the End/Home key on all terminals, not just kitty

    The menu already jumped to the last/first item on KEY_END/KEY_HOME, but the door only mapped CSI H/F (the standard Home/End) while the kitty keyboard protocol was active -- so on a non-kitty Windows Terminal, End (ESC[F) was dropped and the selection wouldn't move to the bottom of the menu. Map
    Home/End unconditionally (they're standard on every xterm-family terminal),
    and cover the other forms for good measure: SS3 F/H (application-cursor mode), ESC[1~/4~ (vt220), ESC[7~/8~ (rxvt), and bare ESC[K (SyncTERM's End without evdev). This brings SyncDOOM to parity with SyncDuke, whose parser already handled both the Windows Terminal (CSI F) and SyncTERM (CSI K) End forms.

    Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Sun Jul 5 16:57:04 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/05469f4d4b76030981fc0f45
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: fix -Wmisleading-indentation warnings (unstack crammed lines)

    GCC's -Wall flagged six lines where multiple statements were crammed onto
    one line so the trailing statement was misleadingly indented as if guarded
    by an if/else that didn't guard it:

    evdev_edge() case 29/97 (Ctrl) and 56/100 (Alt): "... ; else ...; return;"
    parse_byte() case 'P'/'Q'/'S' (kitty F1/F2/F4): "if (kitty) k = KEY_x; break;"
    sd_ingame_recv() the Ctrl-A strip: "if (*s==1) { if (s[1]) s++; continue; }"

    Purely a reformat -- one statement per line at the correct depth (tabs, per uncrustify.cfg) -- no behavior change. This is the one -Wall class that IS formatting-driven, so unstacking the lines clears it.

    Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Jul 9 01:55:11 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/716fdefcfab4f09a178bde67
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: move onto termgfx keymode

    The last of the four doors to stop carrying its own copy of the terminal key-mode negotiation. termgfx/keymode.h (cf67bccb2a, thrown-29-throw) now supplies the evdev/kitty enable and restore sequences, the evdev-wins precedence, the enable-time settle window, the 88-entry evdev->ASCII
    table and the modifier classifier.

    g_kitty_active and g_evdev_active stay as plain int globals, because
    m_menu.c reads them to grey out the key-feel sliders once a native
    key-up path is negotiated, and m_menu.c is vendored. They are now
    mirrors, set from the shared state after an enable succeeds and cleared
    in the restore -- rather than the state itself.

    The restore is a single termgfx_keymode_restore() emitting only what was actually enabled, in place of two hand-guarded literal writes.

    No change to the bytes on the wire, the settle window's 500ms, or the
    evdev key handling: Shift still asserts the engine's Run + Strafe
    scancodes, Ctrl and physical Alt are still tracked and never forwarded (SyncTERM reserves Alt+key), and the Shift-folds-to-upper-in-menus-only
    rule is unchanged.

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Aug 17 02:35:26 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/92c2fd33bdff650976b48e11
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: on a tty, VMIN=0 makes "no input" indistinguishable from EOF

    The *nix stdio path put the terminal in raw mode with VMIN=0/VTIME=0 and
    relied on O_NONBLOCK to report an empty read as -1/EAGAIN. A tty does not
    work that way: with VMIN and VTIME both zero the read timeout is zero, and
    the kernel returns 0 before it ever consults O_NONBLOCK. conn_read() maps 0
    to EOF, so the first input pump with nobody mid-keystroke set g_hangup and
    the door exited with status 0 on its very first frame -- immediately after "ST_Init: Init status bar.", and with no diagnostic.

    VMIN=1 restores the distinction conn_read() depends on: -1/EAGAIN when no
    byte is waiting, 0 only when the client really has gone. O_NONBLOCK is what keeps the read from blocking.

    This left stdio mode unusable on every *nix host, whether the door was
    started from a shell or handed its stdio by a BBS. The path had only ever
    been exercised over pipes, where tcgetattr() fails, the termios block is skipped, and 0 does mean EOF. A BBS gives a stdio door a pty, so the door applied VMIN=0 there as well -- overriding, under Synchronet's XTRN_STDIO,
    the cfmakeraw() the BBS had just done.

    Socket doors are unaffected: raw_input_on() returns early on one.

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net