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.ã > ã > 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. ãIt'sã > already possible to do that, I know, but it requires that users ãconfigureã > their terminal prior to connecting to the BBS. Not many would do that.ã > ã > 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.ãã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.ãã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.ããNightfoxãã---ã þ Synchronet þ Digital Distortion BBS - digitaldistortionbbs.comã
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.ãã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.ããAnyway, at this point the user base is so small that this idea probablyãdoesn't matter. But when I saw those oversized ANSIs, I imagined how cool itãcould be to see games like Chicken Delivery or Star Trek on a larger canvasã(with more graphical detail possible). ãã--Joshãã////--------------------------------------------------ãBiC -=- http://breakintochat.com -=- bbs wiki and blogãã---ã þ Synchronetã
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.ãã---ã þ Synchronet þ R&M Software Support BBSã
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.ããI think it's actually a great idea. That's how some really cool features cameãabout. For example Canvas was first implemented by Apple for WebKit, thenãGecko added it, then Opera, then eventually it became a standard.ããSo Apple creating Canvas wasn't a bad idea. And someone making use of Canvasãto dynamically manipulate an image while still showing the stock image toãbrowsers that don't support Canvas is also not a bad idea. And that isãexactly what is being proposed here. Try to use a larger screen if it isãsupported, but use 80x24 (or whatever) as a fallback if it's not supported.ãã---ã þ Synchronet þ R&M Software Support BBSã
> 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.
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.
Sysop: | Karloch |
---|---|
Location: | Madrid, Spain |
Users: | 54 |
Nodes: | 8 (0 / 8) |
Uptime: | 129:48:09 |
Calls: | 700 |
Files: | 17,895 |
D/L today: |
128 files (60,769K bytes) |
Messages: | 66,010 |