"Plan" for unicode

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

I still think we should do something network-specific so we're not locked to a particular user input method...
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Then we'll have three formats to convert between, the old color codes, the new user enterable color codes and the internal color codes. An at no point, the type of a string tells you which of these formats is used. If the wasted bandwidth is a concern, we should rather integrate general purpose compression.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:Then we'll have three formats to convert between, the old color codes, the new user enterable color codes and the internal color codes. An at no point, the type of a string tells you which of these formats is used.
A change between two network protocols/formats is easier in the long run than a change between more.
We would be doing a one-time change from ASCII+0xRRGGBB to UTF-8+StdNetworkColors.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

But StdNetworkColors won't be user editable, if I understand your bit wrangling correctly. So if we want user editability, another format is required, and conversion of that to StdNetworkColors in a lot of places. For compatibility, we also need conversions in both directions for the old 0x format. That last conversion is well localized in the network code and has to be done regardless which color codes we use, but if we ONLY use escape codes, that also is the only place we need conversion.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:But StdNetworkColors won't be user editable, if I understand your bit wrangling correctly.
I'm not pushing any particular network protocol for colours, just that there should be one.
z-man wrote:So if we want user editability, another format is required, and conversion of that to StdNetworkColors in a lot of places.
No reason user-edited stuff can't use the 'say' syntax.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

What say syntax?

Why should there be a color network protocol? Why isn't sending the encoded string enough?
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:Why should there be a color network protocol? Why isn't sending the encoded string enough?
Because the "encoded string" format can change, assuming you mean what is currently "0xffffff"
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Unless we make the network color format extra verbose and extensible, it will have to change as well if we want it to do new things (transmit font information, say). I don't think we'll need more than escape codes, with Unicode, we'll have plenty of characters to assign special meaning to :) \c for foreground color, \b for background (if we decide we don't need backspace, \r otherwise), \f for the font, \s for size, \p for position in 3d space...
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:Unless we make the network color format extra verbose and extensible, it will have to change as well if we want it to do new things (transmit font information, say). I don't think we'll need more than escape codes, with Unicode, we'll have plenty of characters to assign special meaning to :) \c for foreground color, \b for background (if we decide we don't need backspace, \r otherwise), \f for the font, \s for size, \p for position in 3d space...
Let's just embed XHTML and CSS!
yes, I'm joking
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

bump. We've got truetype support now. Also several other font types that ftgl supports if we want to use them.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

So, what we need to do is:
- transcode the language files to UTF8
- tell FTGL the input now comes as UTF8
- translate to and from latin1 in the network code (my job)
- design new coloring escape codes, maybe throw font selection and alignment on top of that
- translate those in the network code, too (my job again)

The not-my-jobs are open for grabs. I'd say Wrtl is the man for them, having already done the fonts.
User avatar
joda.bot
Match Winner
Posts: 421
Joined: Sun Jun 20, 2004 11:00 am
Location: Germany
Contact:

Post by joda.bot »

@z-man: if you happen to see a way to remove the byte swapping in armagetronads network packets, that would really be neat... currently all strings in network traffic have swapped low and high bytes, which makes sniffed chat pretty difficult to read....

AFAIK: network traffic is big endian where possible, but it affects a huge part of the network protocol. Can the versioning system handle this ?

CYCLE becomes YCLCE or CCYEL which makes traffic shaping classifiers more diffcult (btw.)... remind me to submit my armagetronad filter l7filters.
User avatar
wrtlprnft
Reverse Outside Corner Grinder
Posts: 1679
Joined: Wed Jan 04, 2006 4:42 am
Location: 0x08048000
Contact:

Post by wrtlprnft »

z-man wrote:So, what we need to do is:
- transcode the language files to UTF8
That takes about 5 seconds in vim, no problem.
- tell FTGL the input now comes as UTF8
Pretty easy, you just have to give it a wchar const * instead of char const * (i hope)
- design new coloring escape codes, maybe throw font selection and alignment on top of that
Well, that's the harder one, and I guess it depends on how fast we can get the format specified, and knowing how long the average discussion here takes and that we rarely get an actual result everyone is happy with, that might be a real problem. But sure, unless luke-jr wants to use CSS, I'll do it.

We should also convert tString and all our functions to use wchar instead of char then, to avoid converting between char and wchar all the time.
Last edited by wrtlprnft on Sun May 14, 2006 3:35 pm, edited 1 time in total.
There's no place like ::1
User avatar
dlh
Formerly That OS X Guy
Posts: 2035
Joined: Fri Jan 02, 2004 12:05 am
Contact:

Post by dlh »

joda.bot wrote:@z-man: if you happen to see a way to remove the byte swapping in armagetronads network packets, that would really be neat... currently all strings in network traffic have swapped low and high bytes, which makes sniffed chat pretty difficult to read....

AFAIK: network traffic is big endian where possible, but it affects a huge part of the network protocol. Can the versioning system handle this ?

CYCLE becomes YCLCE or CCYEL which makes traffic shaping classifiers more diffcult (btw.)... remind me to submit my armagetronad filter l7filters.
I also wonder why strings are serialized in pascal-style and c-style? The length of the string is specified at the beginning, and it is NULL terminated (and then padded to even length with another NULL). I doubt much is gained by shaving off 3/4 bytes, though (lose the pascal-style and pad).
Last edited by dlh on Sun May 14, 2006 3:57 pm, edited 1 time in total.
User avatar
dlh
Formerly That OS X Guy
Posts: 2035
Joined: Fri Jan 02, 2004 12:05 am
Contact:

Post by dlh »

joda.bot wrote:CYCLE becomes YCLCE or CCYEL which makes traffic shaping classifiers more diffcult (btw.)... remind me to submit my armagetronad filter l7filters.
CYCLE -> CYCLE\000
len: 6
data: \000\006YCLC\000E
Post Reply