"Plan" for unicode
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
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.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
A change between two network protocols/formats is easier in the long run than a change between more.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.
We would be doing a one-time change from ASCII+0xRRGGBB to UTF-8+StdNetworkColors.
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.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
I'm not pushing any particular network protocol for colours, just that there should be one.z-man wrote:But StdNetworkColors won't be user editable, if I understand your bit wrangling correctly.
No reason user-edited stuff can't use the 'say' syntax.z-man wrote:So if we want user editability, another format is required, and conversion of that to StdNetworkColors in a lot of places.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
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...
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
Let's just embed XHTML and CSS!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...
yes, I'm joking
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.
- 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.
@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.
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.
- wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
That takes about 5 seconds in vim, no problem.z-man wrote:So, what we need to do is:
- transcode the language files to UTF8
Pretty easy, you just have to give it a wchar const * instead of char const * (i hope)- tell FTGL the input now comes as UTF8
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.- design new coloring escape codes, maybe throw font selection and alignment on top of that
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
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).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.
Last edited by dlh on Sun May 14, 2006 3:57 pm, edited 1 time in total.