open https://gitlab.synchro.net/main/sbbs/-/issues/1214

Before I install syncarcade on my own BBS I decided to try it out on vert, however I'm seeing odd graphics appear in the top left hand corner of the screen.

I'm using SyncTerm 1.8 - GDI and access vert.synchro.net

Here is a video of the issue:

https://www.magnum.uk.net/dropzone/arcade1.mp4

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

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9914

Thanks for the report, and for the video -- that made this quick to pin down.

The cause is on our side, not SyncTERM's. The door asks the terminal to draw sixel images at the text cursor, via DEC private mode 80 (DECSDM). CTerm reversed that mode's set/reset sense in revision 1.328 (2026-06-28), and SyncTERM 1.8 ships CTerm 1.327 -- one revision earlier. So the sequence the door sends means the opposite of what it intends on 1.8: the terminal ignores the cursor and anchors every image at the top-left corner of the screen.

That is exactly what your video shows. The game picture itself lands top-left instead of centered, and -- more visibly -- the small partial updates the door sends between full frames (it repaints only the cells that changed, to save bandwidth) all pile into that same corner instead of landing over the part of the screen they belong to. Hence the block of scrambled graphics that keeps changing up there while the game plays on below it.

The doors now read the CTerm revision out of the terminal's device-attributes reply and send whichever of the two sequences that particular build reads as "draw at the cursor", so old and new SyncTERM are both handled. The same assumption was baked into SyncDOOM, SyncDuke, SyncMOO1, SyncSCUMM and SyncRPG, so all of them got the fix too.

Could you retest on cvs.synchro.net? The fixed Linux build of the door is running there now. vert.synchro.net serves the Windows build from the same directory, and that one has not been rebuilt yet, so vert will still show the problem.

Please stay on SyncTERM 1.8 for the retest -- 1.8 is the case being fixed, so it is the useful one to confirm. What you should see: no scrambled graphics in the top-left, and the game picture centered in the window rather than pushed against the left edge.

The change is not committed or released yet. It is deployed on cvs.synchro.net precisely so it can be confirmed against a real 1.8 client first.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*

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

close https://gitlab.synchro.net/main/sbbs/-/issues/1214

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

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9915

cvs works great :smile:

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

reopen https://gitlab.synchro.net/main/sbbs/-/issues/1214

Before I install syncarcade on my own BBS I decided to try it out on vert, however I'm seeing odd graphics appear in the top left hand corner of the screen.

I'm using SyncTerm 1.8 - GDI and access vert.synchro.net

Here is a video of the issue:

https://www.magnum.uk.net/dropzone/arcade1.mp4

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

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9942

Hi DM, getting some odd graphics at the bottom of the screen:

https://www.magnum.uk.net/dropzone/arcade2.mp4

(using cvs)

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

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9946

Thanks -- and that is a second, separate bug, which the first fix is what
made visible. Sorry for the repeat trip.

The door repaints only the cells that changed between frames, and it sized those patches in whole text cells. That is what the cursor address in front
of a patch needs, but not what the decoder behind it needs: a sixel is read
six pixel rows at a time, and SyncTERM's 8x16 character cell makes those patches 16, 32 or 80 rows tall. None of those is a whole number of six-row bands, so every patch ended in a partial one.

CTerm did not clear its band mask between bands until 2026-06-28. Below
that, the columns of a partial last band that the band does not paint keep
the PREVIOUS band's pixels instead of being left alone. So each patch left
a stale sliver at its foot, and a sprite moving across the screen smeared
that into the dotted trail your video shows. It is SourceForge ticket #258
on the SyncTERM side.

That also explains why SyncTERM 1.10a is clean and 1.8 is not: the CTerm
fix landed after 1.8 was released. And it is why this only appeared now -- until last night's fix the patches were all landing in the top-left corner,
so there was nothing in the right place to leave a trail behind.

Every other terminal was already getting whole-band patches; SyncTERM was
the one exception, on the reasoning that whole cells were enough. The door
now sizes every patch in whole bands regardless of the terminal. It costs
about 3% more data, which run-length encoding absorbs almost entirely.

Could you retest on cvs.synchro.net once more, again on SyncTERM 1.8? The
new build is running there. What you should see this time is no trail
behind the cannon as it moves, and nothing accumulating below the row of
spare lives at the bottom.

vert.synchro.net still serves the Windows build and has not been rebuilt,
so it will keep showing both problems for now.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*

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

https://gitlab.synchro.net/main/sbbs/-/issues/1214#note_9959

The problem is now resolved - thanks.

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