The last few days I've seen a couple oversized ANSI artworks posted on Facebook: one 160 chars wide, and the other 200 chars wide.It's
That got me thinking. A bigger canvas lets you create more detailed graphics, which sure would be nice to use in BBS interfaces or games.
already possible to do that, I know, but it requires that usersconfigure
their terminal prior to connecting to the BBS. Not many would do that.to
So could there be (or is there) a way for a JS app on the BBS to signal
SyncTerm to resize itself to larger dimensions? Like when you play a PC game, and it changes the screen resolution by itself, and then resetsonce
you quit.
Unfortunately, the best option is probably to stick with the 80x25 canvas size for ANSI graphics if you intend to display the art over a terminal connection and you don't want your users to have to reconfigure their terminal size before connecting.
That's an interesting idea, but the downside is that it would be a proprietary thing supported by SyncTerm and Synchronet, and other terminal software might never adopt that standard. At the very least, it shouldn't break other terminal programs, but such large ANSIs would look ugly on
those terminal programs, as you describe. Also, there are some people who like to configure old DOS terminal programs in an emulator to be used over telnet for the nostalgia factor, and those terminals of course are no
longer being updated.
canvas size for ANSI graphics if you intend to display the art over a terminal connection and you don't want your users to have to reconfigure their terminal size before connecting.
I use Telnet Client on my Windows ,Work ok ansi ok
But no Transfers
If the hooks to make this work existed within SyncTerm and Synchronet, then it would be up to the sysop/app developer to handle it gracefully, much the same way that good web design should degrade gracefully for people using older browsers.
You could have your app check for the end user's terminal capabilities. If they were using a SyncTerm that supported the resizing feature, then go ahead and serve an enlarged, enhanced experience. If not, stick to the standard 80x25.
You could have your app check for the end user's terminal capabilities. If they were using a SyncTerm that supported the resizing feature, then go ahead and serve an enlarged, enhanced experience. If not, stick to the standard 80x25.
My main point, though, was that dynamic terminal resizing is currently not part of any BBS client standard (that I know of). Going with your web development analogy, adding something like that to Synchronet & SyncTerm would be akin to Microsoft making their own changes to Internet Explorer that nobody else supports. That isn't necessarily a good idea.
> You could have your app check for the end user's terminal capabilities. If
> they were using a SyncTerm that supported the resizing feature, then go
> ahead and serve an enlarged, enhanced experience. If not, stick to the
> standard 80x25.
I don't think it even needs to check ahead of time. Just send the "resize" command followed by the "detect screen size" sequences. (I guess you need to wait for the cursor position response to come back to know whether the size changed though.)
If Deuce adds a command for this to SyncTerm, I'd likely implement it in fTelnet as well.
So could there be (or is there) a way for a JS app on the BBS to signal to SyncTerm to resize itself to larger dimensions? Like when you play a PC game, and it changes the screen resolution by itself, and then resets once you quit.
My main point, though, was that dynamic terminal resizing is currently not part of any BBS client standard (that I know of).
I don't think it even needs to check ahead of time. Just send the "resize" command followed by the "detect screen size" sequences. (I guess you need to wait for the cursor position response to come back to know whether the size changed though.)
If Deuce adds a command for this to SyncTerm, I'd likely implement it in fTelnet as well.
Next up, 32 bit color!
Re: Re: Dynamic screen resizing
By: Mindless Automaton to Ree on Fri Dec 05 2014 03:25 pm
> Next up, 32 bit color!
24-bit is much more likely... that link seems to describe 24-bit colour, but call it 32-bit.
And until I come up with something I like to unscrew the inscrutable problem of
how to make 24-bit colour to the 8/16 colour palette we have now, I'm unlikely
to implement it.
Re: Re: Dynamic screen resizing
By: Mindless Automaton to Ree on Fri Dec 05 2014 03:25 pm
> Next up, 32 bit color!
24-bit is much more likely... that link seems to describe 24-bit colour, but call it 32-bit.
And until I come up with something I like to unscrew the inscrutable problem of
how to make 24-bit colour to the 8/16 colour palette we have now, I'm unlikely
to implement it.
And until I come up with something I like to unscrew the inscrutable problem of how to make 24-bit colour to the 8/16 colour palette we have now, I'm unlikely to implement it.
How about 8-bit?
http://fansi.org/256Colors.aspx
Sysop: | Clippy |
---|---|
Location: | Houston, TX |
Users: | 4 |
Nodes: | 4 (0 / 4) |
Uptime: | 214:59:28 |
Calls: | 1 |
Files: | 11 |
Messages: | 38,209 |