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 Sat Jun 20 14:04:41 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/4820eaed990ac607d5ece6da
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: anchor the sixel image at top-left when terminal pixels are unknown

    Sixel is positioned by text cell, but the image is sized in pixels; on a terminal
    that doesn't report its real cell-pixel size (e.g. xterm with allowWindowOps off)
    the door assumed 16px-tall cells, so the "centered" row landed too low and the frame looked bottom-anchored. When real geometry is unknown, anchor the sixel at
    row 1, col 1 -- predictable, and what a user expects. JXL/PPM (SyncTERM, real geometry) still center via the APC DX/DY offsets.

    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 Jun 20 14:04:41 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/b4c533c170213b49b9820604
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: cap the text-tier render grid on oversized terminals

    A maximized terminal can measure huge (e.g. 561x105); the text tier then renders
    the full grid -- ~330 KB per frame, 1.5+ MB/s -- which floods the link and trips
    the dead-client watchdog, so the door looks like it auto-terminates. Beyond Doom's own detail the extra cells add only bytes, so cap the text grid to [video] text_max_cols x text_max_rows (default 200x80; 0 = uncapped). Invisible for normal terminals; it only bounds the maximized case.

    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 21 02:00:51 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/13c434bacedb40ab7da9e4da
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: stats-overlay display fixes (letterbox clear, shrink, MB/s)

    Three fixes to the Ctrl-S overlay (and the Ctrl-T/N/F4 labels), reported on a large Windows Terminal / SSH window where the centered game frame never repaints
    the top row:

    - Clear on dismiss: when a label's dwell ends (or the overlay is toggled off) the
    top row is wiped (ESC[1;1H ESC[2K) and a full repaint forced. In a letterboxed
    window that row is in the margin, so it was stranding the text otherwise.
    - Shrink-gap blanking: the overlay is right-justified, so a narrower redraw (fewer
    fps/lag digits, or KB/s -> MB/s) left the previous wider text's left end behind.
    Track the prior width and blank exactly the now-uncovered cells.
    - Throughput reads fractional MB/s above 999 KB/s (KiB/MiB of wire bytes) so the
    field stays narrow on a fast link (LAN sixel runs 3-6 MB/s).

    Confirmed fixed live on Windows Terminal (LAN).

    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 21 04:35:45 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/a79701f82e3843aa41c490d7
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: anchor text-mode overlay + labels to the rendered grid width

    In text mode the grid is capped (text_max_cols, default 200), so on a terminal wider than the cap the stats overlay (right-justified) and the centered labels (DEPTH/DITHER/STATS/video) were positioned against the full g_cols and landed off
    to the right of the actual game view -- the overlay flew past the edge, the labels
    drifted right. Add overlay_cols() = the rendered width (g_text_cols in text mode,
    g_cols for the graphics tiers, where the overlay sits in the centered image's margin) and route the overlay's right-justify + all four label centerings through
    it. g_text_cols is set in setup_text_mode to the capped tcols.

    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 21 15:31:28 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/a71b247db0bd90b40efae432
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: resolve a bare -iwad/-file against the [wads] dir, not CWD

    The door exports DOOMWADDIR from the [wads] dir so a bare
    "-iwad freedoom1.wad" -- the direct-exec single-player install entry --
    can locate the WAD in the configured directory. But the arg-rewrite that
    makes WAD paths absolute before the sandbox chdir ran abscopy(), which
    resolves a relative name against the door's CWD: "freedoom1.wad" became "<doordir>/freedoom1.wad" before Doom's own IWAD search ran, defeating DOOMWADDIR and failing with "IWAD file '<doordir>/freedoom1.wad' not
    found!" whenever the WAD lives in the wads/ subdir (the default layout).

    Add wadcopy(): a relative -iwad/-file/-merge value resolves against the configured (absolute) [wads] dir when the file is found there -- the same
    place the JS lobby loads from -- falling back to CWD-relative (abscopy) otherwise. The lobby, which passes absolute WAD paths, is unaffected.

    The installer's single-player launch string needs no change.

    Reported by Accession.

    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 21 15:31:28 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/7f44fc1de5d847eecf099544
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: keep the waiting-room "waiting alone" prompt within 80 cols

    The controller-waiting-alone prompt ("Waiting for another player... auto- starts when full. Q cancel (then pick single-player to play solo).") was a single ~103-char line that ran off the right edge of an 80-column terminal, truncating the solo hint to "...pick si." (reported with a screenshot).

    Split it across the panel's two free rows: the "waiting / auto-starts" line
    on top+2 and the "Q to cancel / play solo" hint on top+3, each well within
    80 cols. The other two prompt cases already fit and are unchanged.

    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 21 15:31:28 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/93fc68f6d451c6ca64026f9a
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: list waiting-room players one per row (fits 3-4 long names)

    The player list was a single row of "N.name" entries separated by spaces -- fine for two short aliases, but three or four longer ones (Synchronet allows 25-char aliases) overran 80 columns and truncated, like the prompt did.

    Put one player per row and size the status panel to the player count: it
    grows upward over the splash from 4 rows (1-2 players) to 6 (a full 4), so every name shows in full regardless of length. Validated via pyte at 1-4 players incl. a 25-char alias -- nothing reaches column 80.

    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 Mon Jun 22 00:57:11 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/a5e95a1b2b7a601ad7afc7f6
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: accept a short or SAUCE-padded waiting.bin splash

    load_splash() required the file to be exactly 4000 bytes (80x25), so an editor that saved a shorter canvas (e.g. PabloDraw's 80x23 = 3680 bytes) or appended a SAUCE record was rejected and the door fell back to the baked-in art. Now it zero-fills the cell buffer and loads up to 4000 bytes from any non-empty file: a short image fills the top rows (rest black), a longer one has the extra bytes (SAUCE) ignored.

    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 Mon Jun 22 01:56:17 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/ccea2142336bc4513f0f5048
    Modified Files:
    src/doors/syncdoom/syncdoom.c
    Log Message:
    syncdoom: write per-user prefs fresh to fix lost settings

    The per-user prefs file (data/user/####/doom/syncdoom.ini) silently
    stopped saving and loading its [input] settings (mouse, instant_turn,
    kpturn, ...) and piled up duplicate keys. Cause: read-modify-write plus
    "remove a key when it equals the default" eventually emptied the [input] section, and an xpdev bug then misfiled every later [input] key at the end
    of the file under [video], where it was unreadable (gitlab #1168).

    Write the file fresh each time instead -- store only the current
    non-default prefs, sections built in order -- so the empty-section path is never hit and an already-corrupted file self-heals on the next save. These
    are generated prefs in data/, so there's nothing hand-edited to preserve
    by reading the old file first.

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

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