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

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

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

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

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

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

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

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

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

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

Ya got DooM running as a door? That's awesome. Could maybe help out with that, since the other day I was relaying the same idea over Avatar-Chat to someone else. I've actually helped code mostly server code and a few other things for zdoom/zdaemon/skulltag in the past. Will there be an option for the real doom.wad or doom2.wad, perhaps Heretic and HeXen as well? They all use the same bsp and nodes and whatnot, just different IWADS and main wads. Will be happy to test it out, long as I update my git or lab whichever it was I got the latest version from a month or so ago now and compile.. BTW it is painful in gentoo linux to install/use this software, or either user error.

=-\DaRKLoRD/-= The future of all mankind. darksix.org - all logins will be reported to /dev/null. (0)=----.,

---
þ Synchronet þ DaRKLoRD BBS

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

330KB per frame is ridiculous, should be about 87 bytes at the most or less, need to send just the posistion for (x,y) of player, and other players coords.
and use a central server to do the packet updates via that way, or others.. then it would be 2KB a second or around there.

---
þ Synchronet þ DaRKLoRD BBS

https://gitlab.synchro.net/main/sbbs/-/commit/6fefefaa65b8c7bb75a4c05a
Modified Files:
src/doors/syncdoom/syncdoom.c
Log Message:
syncdoom: anchor mouse steering to the image + cap sixel size

Two fixes for terminal mouse steering in a window much larger than the
rendered game (notably xterm sixel):

- Steer relative to the IMAGE, not the window. The steer center and
full-deflection span are now taken from the rendered image's cell
rectangle (g_img_col + width) instead of the terminal's center. With a
letterboxed or top-left-anchored image the old window-center put the
"idle" point out in the black margin, so the player spun until the
pointer was dragged off into empty space; now idle sits on the picture's
center and the image edge is full turn. Exact once the terminal's real
cell size is known (SyncTERM always; xterm with allowWindowOps).

- Never upscale the sixel past native 640x400, even when real pixel
geometry was measured. Sixel is near-raw RLE, so a window-filling sixel
on a large console is both too big for the terminal to render and a huge
per-frame payload that stalls the DSR pacing -- the door froze on a blank
screen once allowWindowOps let xterm report a big window. The 640 cap was
previously skipped when geometry was known; sixel is impractical to
upscale regardless. JXL/PPM (real compression) keep the full scale_max.

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

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

Re: Re: src/doors/syncdoom/sy
By: Darksix to Rob Swindell (on Debian L on Mon Jun 22 2026 03:08 pm

Ya got DooM running as a door? That's awesome. Could maybe help out with that, since the other day I was relaying the same idea over Avatar-Chat to someone else. I've actually helped code mostly server code and a few other things for zdoom/zdaemon/skulltag in the past. Will there be an option for the real doom.wad or doom2.wad, perhaps Heretic and HeXen as well?

Any WADs that are compatible with vanilla doom. Details here: https://gitlab.synchro.net/main/sbbs/-/blob/master/src/doors/syncdoom/README.md

They all
use the same bsp and nodes and whatnot, just different IWADS and main wads. Will be happy to test it out, long as I update my git or lab whichever it was I got the latest version from a month or so ago now and compile.. BTW it is painful in gentoo linux to install/use this software, or either user error.

Without any provided details, hard to help with that.
--
digital man (rob)

Steven Wright quote #11:
I almost had a psychic girlfriend, ..... But she left me before we met.
Norco, CA WX: 65.3øF, 76.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Re: src/doors/syncdoom/sy
By: Darksix to Rob Swindell (on Debian L on Mon Jun 22 2026 03:08 pm

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

330KB per frame is ridiculous, should be about 87 bytes at the most or less, need to send just the posistion for (x,y) of player, and other players coords. and use a central server to do the packet updates via that way, or others.. then it would be 2KB a second or around there.

SyncDOOM is *server* rendered.
--
digital man (rob)

Rush quote #48:
The point of the journey is not to arrive. Anything can happen.
Norco, CA WX: 65.3øF, 76.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/dc723e17eb4206850a50f7a2
Modified Files:
src/doors/syncdoom/syncdoom.c
Log Message:
syncdoom: add sixel to the F4 tier cycle on JXL terminals

When JXL is the startup tier, the door now also probes sixel (the JXL
ladder short-circuits before probe_sixel, and a JXL-capable SyncTERM
answers the sixel CTDA query immediately), and adds it as a second
graphics state so F4 cycles jxl -> sixel -> text tiers. Lets a player
A/B the two graphics tiers live. Skipped when sixel is force-disabled.

Graphics-tier cycle labels now name the tier (jxl/sixel/ppm) instead of
the generic "graphics", so the F4 flash shows which one you're on.

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/d494dace83cfbd93cb2f99d1
Modified Files:
src/doors/syncdoom/syncdoom.c
Log Message:
syncdoom: fix Windows Terminal sixel regression (per-frame palette)

The define-once palette optimization assumed the terminal retains sixel
color registers across separate DCS images. SyncTERM does, but Windows
Terminal and xterm do NOT -- so frames that omitted the palette block referenced undefined registers and rendered with wrong/default colors.

Gate define-once on g_is_syncterm; everywhere else re-send the palette
every frame. It's now the stable 1:1 register<->index set, so a per-frame palette is identical each time (no churn) -- matches Deuce's guidance and restores correct sixel on WT/xterm while keeping SyncTERM's define-once.

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

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

Re: Re: src/doors/syncdoom/sy
By: Digital Man to Darksix on Mon Jun 22 2026 23:13:56

Any WADs that are compatible with vanilla doom. Details here: https://gitl ab.synchro.net/main/sbbs/-/blob/master/src/doors/syncdoom/README.md

Be nice to find the Beavis and Butthead WAD file and do a version of Wolfenstein if possible like the doom game. I tried it on your system and is kinda fun, just a few issues with controls but I see mouse support of some kind was added and havent tried it with that yet.

---
Barry Davis Jr
SysOp
KrAABY Gamer BBS
---
þ Synchronet þ Sent from the KrAABY Gamer BBS

Re: Re: src/doors/syncdoom/sy
By: KrAAB to Digital Man on Tue Jun 23 2026 03:39 am

Be nice to find the Beavis and Butthead WAD file and do a version of Wolfenstein if possible like the doom game.

I've seen old DOS games hosted online in ways that allow a user to play them via a web browser, with some kind of web-enabled version of DOSBox. At one point, I thought about looking into how that's accomplished and hosting some old DOS games on my BBS web site - I'd probably include games such as Wofenstein, Doom, and others. You'd basically have the original version playable in a web browser.

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

Re: Re: src/doors/syncdoom/sy By: Darksix to Rob Swindell (on Debian L on Mon Jun 22 2026 03:08 pm

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

330KB per frame is ridiculous, should be about 87 bytes at the most or less,
need to send just the posistion for (x,y) of player, and other players coords. and use a central server to do the packet updates via that way, or
others.. then it would be 2KB a second or around there.

SyncDOOM is *server* rendered. -- digital man (rob)

After watching and/or finding out about the video posting showing this in action, is really nice looking.
I have not looked into the source actually yet, but probably will sometime soon. I'd figure there would be a
way to decrease the size of the output, even if by just redoing the scale slider for how much view you get.
Seems it is using full updates even when using the smaller screen with background, probably because of the
playerbar stuff and that iirc with the slider down, it still had to draw the bg per frame, but it was looped
from memory.. Probably hard to do with jpeg style things. Have you tried to do zlib compression on both sides yet?
That may take some work, but probably would considerably lower that 1.5+ MB/s if it was sent to client as the text
and then the client/your comp encodes it to the jpeg. Hmm that won't work either for compatibility I suppose though.
MCCP2 might be an option. Would have to be integrated to SyncTerm though.. Just throwing spitballs here right now..

I have the highest plan spectrum can offer residential.. 40Mbit upload, so ~5MB/s a second. So would tap out at 2 players
give or take.. Got to wonder if there is some better way to go about it.. Guess I'll just dig into the src when I have time.

---
þ Synchronet þ DaRKLoRD BBS

Re: Re: src/doors/syncdoom/sy By: KrAAB to Digital Man on Tue Jun 23 2026 03:39 am

Be nice to find the Beavis and Butthead WAD file and do a version of Wolfenstein if possible like the doom game.

I've seen old DOS games hosted online in ways that allow a user to play them via a web browser, with some kind of web-enabled version of DOSBox. At one
point, I thought about looking into how that's accomplished and hosting some old DOS games on my BBS web site - I'd probably include games such as
Wofenstein, Doom, and others. You'd basically have the original version playable in a web browser.
---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com

You have missed the point.. But i'm pretty sure i can find the beavis and butthead wad..but making it wolfenstein you'd have to do..cause here in the past few years i dont do my own wads, mainly cause Toke died.. pretty sure the B&B included a DEH..not sure though..

---
þ Synchronet þ DaRKLoRD BBS

Re: Re: src/doors/syncdoom/sy
By: Darksix to Nightfox on Thu Jun 25 2026 02:25 pm

Be nice to find the Beavis and Butthead WAD file and do a version of

Wolfenstein if possible like the doom game.

I've seen old DOS games hosted online in ways that allow a user to play
them
via a web browser, with some kind of web-enabled version of DOSBox. At one

You have missed the point.. But i'm pretty sure i can find the beavis and

Oh, I understand the point, and I actually think SyncDoom is pretty cool. I was just commenting that I had also thought of hosting some DOS games on the web side with DOSBox.

---
þ Synchronet þ Digital Distortion: digitaldistortionbbs.com