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