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.

--Josh

////--------------------------------------------------
BiC -=- http://breakintochat.com -=- bbs wiki and blog

---
þ Synchronet

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

Re: Dynamic screen resizing
By: Nightfox to Kirkman on Wed Dec 03 2014 12:51:18

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.

I use Telnet Client on my Windows ,Work ok ansi ok
But no Transfers






---
þ Synchronet þ SPACESST BBS

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

Re: Dynamic screen resizing
By: spacesst to Nightfox on Wed Dec 03 2014 07:52 pm

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

that's because it doesnt have transfer capability built in
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Re: Re: Dynamic screen resizing
By: Kirkman to Nightfox on Wed Dec 03 2014 22:31:12

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.

For that to work best, it would be best to have different versions of an ANSI - One oversized and another 80x25. Most ANSIs are drawn in only one size though. Perhaps the alternative would simply be not to show an oversized ANSI for someone with a terminal that's not large enough or can't be expanded.

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.

Nightfox

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

Re: Re: Dynamic screen resizing
By: Kirkman to Nightfox on Wed Dec 03 2014 10:31 pm

Kirkman, while my board's going through some changes right now, I just installed a new shell I wrote (probably has some kinks) that is designed to run in a variety of terminal sizes (although some ANSI's get screwed up when you change the terminal size, specifically my login matrix screen).

I used the console.screen_rows and .screen_columns properties to set my frame_sizes relative to each other so that larger (and smaller) sizes than 80 x 25 are supported. In fact it looks pretty bad at a 80 x 24. I've got it running in 203 x 69 resolution right now, and it can go as high as memory allows.

I don't see any issues launching games or stuff designed for smaller terms within the context of my shell - except maybe an excessive amount of screen real estate when the games run off to the sides.

Just finished this new shell (or finished enough to make it live, more features are coming) yesterday - but if you feel like checking it out, it will adapt to the resolution that you use when you connect initially (no live screen resizing for now). I still need to fix some ANSI's so they display properly at larger widths - so ignore that if you visit.

cheers
ll morph G futureland.grudgemirror.com LaRRy LaGoMoRpH\-/
O
=M=
'not your average board check it out' /-\


---
þ Synchronet þ Futureland.Grudgemirror.Com ** LIVE ** Music and

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

On 12/5/2014 9:25 AM, Ree wrote:

> 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.

Next up, 32 bit color!

http://doryen.eptalys.net/data/libtcod/doc/1.5.1/html2/color.html?c=false&cpp=false&cs=false&py=false&lua=false

-Mindless Automaton
---
­ Synchronet ­ Eldritch Clockwork BBS - eldritch.darktech.org

Re: Dynamic screen resizing
By: Kirkman to All on Wed Dec 03 2014 10:48 am

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.

It's possible (there is no such feature currently), but it would cause a lot of
usability issues. For example, if you switch to 132 column mode, and the screen isn't wide enough to support it at your current zoom level, what should happen?

Potential problems like that, and the difficulties that would happen due to how
the scrollback is managed and such make it "too hard to be worth it".

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: Dynamic screen resizing
By: Nightfox to Kirkman on Thu Dec 04 2014 07:57 am

My main point, though, was that dynamic terminal resizing is currently not part of any BBS client standard (that I know of).

ANSI.SYS supported screen mode changes, and VT terminals supported switching to/from 132 column mode, so there are sequencies and terminals in the wild that
support the feature.



---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: Dynamic screen resizing
By: Ree to Kirkman on Fri Dec 05 2014 09:25 am

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.)

And hope that the terminal doesn't do "something else" when you send the sequence.

If Deuce adds a command for this to SyncTerm, I'd likely implement it in fTelnet as well.

I don't plan to, but if the initial problems suggest a solution, I could likely be convinted to look into it further.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

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.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

On 12/9/2014 12:18 AM, Deuce wrote:

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.

Well if you get 24 in there, why not throw in 8 more? ;)

This sounds like a job for.. someone else!

-Mindless Automaton
---
­ Synchronet ­ Eldritch Clockwork BBS - eldritch.darktech.org

On 12/9/2014 12:18 AM, Deuce wrote:

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.

How about 8-bit?

http://fansi.org/256Colors.aspx

-Mindless Automaton
---
­ Synchronet ­ Eldritch Clockwork BBS - eldritch.darktech.org

Re: Re: Dynamic screen resizing
By: Mindless Automaton to Deuce on Tue Apr 07 2015 11:55 pm

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

They're both on The List for the console overhaul I'll be doing after the 1.0 release of SyncTERM.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)