Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Random832]

Well for unix clients you can't send cp437 because the characters simply aren't present in the 8-bit fonts commonly used [you could send utf-8 i guess]

Anyway, I could probably write the code in platform-independent .NET which could run in mono.

[Vucar Fikodastesh]

Anyway, I could probably write the code in platform-independent .NET which could run in mono.

And on a Pocket PC.

I hope.

[Mr.Person]

If the client runs on, say, DOS, could you run DF through DOS (in a sense)?

[Jifodus]

Well for unix clients you can't send cp437 because the characters simply aren't present in the 8-bit fonts commonly used [you could send utf-8 i guess]

Anyway, I could probably write the code in platform-independent .NET which could run in mono.

Anyway, if you do insist on writing your own client, I recommend just extending the ANSI escape sequences considering there's already a reference server using telnet.

Btw, if the protocol requires sending those long strings, that's probably just bad.

I discovered through help with testing, that my simple ANSI version was still horrendously slow and was unresponsive (approx data rate of 1-3kb / sec).  It only became marginally useful after I limited the update rate to about 10 frames a second, even then it was still very laggy.

[Random832]

Well for unix clients you can't send cp437 because the characters simply aren't present in the 8-bit fonts commonly used [you could send utf-8 i guess]

Anyway, I could probably write the code in platform-independent .NET which could run in mono.

Anyway, if you do insist on writing your own client, I recommend just extending the ANSI escape sequences considering there's already a reference server using telnet.

Btw, if the protocol requires sending those long strings, that's probably just bad.

What long strings? Oh, are you misinterpreting my description? Each "01 " is supposed to be one byte - not all of them are printable characters so i used a hex dump. "01 4F 18" in my protocol is the equivalent of "1B 5B 37 39 3B 32 34 48" [i.e. ESC[79;24H"] in ANSI.

For anything you'd actually be sending in ANSI, this protocol's version of that would be shorter - if you're sending a whole frame at a time in ANSI [rather than just updating the parts that change] and setting the attibutes for every character, that's up to eighteen kilobytes per frame, as opposed to six for my protocol's full-frame-update code. If you're sending less, less will be required.

And have you considered a black-and-white version? Removing color info (or limiting it in some way) removes a lot of the data, and should be good enough for spectating.

The problem with "extending the ANSI escape sequences" is that I would then have to implement all of the ansi escape sequences in the first place, which means more work, which means more time before we can even think about adding support for graphics etc.

Incidentally - how smart is your program about scrolling? Does it in any way know if the reason the screen is being redrawn is because everything in the main window is being moved ten spaces downwards because the user is scrolling up? That could be captured very efficiently in an extended protocol

[Jifodus]

I asking was more about the usage of "SETCURS", "SETATTR", etc.  But from what you said, I'll take it as a no.

Actually it run-length encoded the attribute changes and did partial updates.  One of the first changes I made, after I got the server working and sending screens.

I hadn't thought of sending black-and-white, but it again comes to a ton of information loss.

I was actually going to implement scrolling detection, but since I found  no easy way to convey scrolling through ANSI, I never bothered to implement it.

[Random832]

I asking was more about the usage of "SETCURS", "SETATTR", etc.  But from what you said, I'll take it as a no.

Actually it run-length encoded the attribute changes and did partial updates.  One of the first changes I made, after I got the server working and sending screens.

I hadn't thought of sending black-and-white, but it again comes to a ton of information loss.

I was actually going to implement scrolling detection, but since I found  no easy way to convey scrolling through ANSI, I never bothered to implement it.

There are ANSI extension commands for scrolling - VT100 commands for vertical scrolling (only problem is it scrolls the whole width of the window, you'd have to redraw the sidebar) and you could insert/delete for horizontal scrolling (one command per line, but better than redrawing the whole screen). Those are reasonably well-supported by all terminal emulators. Inserting is also the way most programs get around being unable to draw to the lower right corner without scrolling - draw to the position immediately before it and then insert.

[Jifodus]

(only problem is it scrolls the whole width of the window, you'd have to redraw the sidebar)

I believe that's why I didn't find it useful enough, because with the sidebar, I'd still end up sending half of the screen, just to scroll by one.

[MHardeman25]

The way I would have approached it is to stream a video of Dwarf fortress, and just stream back keystrokes from the client. Seems like a no brainier really. I think I might just work on that if I get some spare time.

[Adeon]

tl;dr - Dwarf Fortress? Possible over Telnet or SSH?

Linux version of Dwarf Fortress has TEXT print mode which makes it run in a terminal. So it's easy to run it through SSH.

Dfterm2 was made for this kind of thing on Windows. It enables telnet play and can manage multiple DF games at the same time (if wanted). http://www.bay12forums.com/smf/index.php?topic=50643.0

[Kadath]

The way I would have approached it is to stream a video of Dwarf fortress, and just stream back keystrokes from the client. Seems like a no brainier really. I think I might just work on that if I get some spare time.

Also,

X11 forwarding with SSH seems to work for me, although it's kind of laggy.