Add GUILabel (colour code + currency icon support)

[Hop311]

No description provided.

[schombert]

I don't know if you ever plan on supporting unicode text, but if you are thinking about it static constexpr char COLOUR_CHAR = '\xA7'; // § will give you a headache, since that character will end up as more than one byte if it goes through a win1252 to utf8 routine first (since you would probably end up using utf8 as your internal representation and then converting existing text from game files to that on load, rather than having two code paths for all text)

[Spartan322]

I don't know if you ever plan on supporting unicode text, but if you are thinking about it static constexpr char COLOUR_CHAR = '\xA7'; // § will give you a headache, since that character will end up as more than one byte if it goes through a win1252 to utf8 routine first (since you would probably end up using utf8 as your internal representation and then converting existing text from game files to that on load, rather than having two code paths for all text)

He needs to use string_view, not char, we already support utf8 and the conversion happens all the way back in the dataloader.

[schombert]

He needs to use string_view, not char, we already support utf8 and the conversion happens all the way back in the dataloader.

Ah, so then it is only working by accident. '\xA7' from your ascii code page becomes the two-byte sequence C2 A7 in utf8, and so this char happens, by accident, to match the last byte in that sequence and you haven't happened across any other text that contains a different multi-byte sequence ending in A7

[schombert]

I imagine that embedding strings like _balance_label.text = "§%s%s¤" are going to be pretty fragile then since your source code doesn't specify an encoding, and the C++ compiler is free IIRC to use either an ASCII code page or utf8 or really whatever makes it happy.

[schombert]

same also holds for static constexpr char CURRENCY_CHAR = '\xA4'

[Spartan322]

Well Godot strings are inherently utf8, they'll try to read it as ISO 8859-1 if you just shove the single byte values beyond ASCII in without the utf functions, however Godot strings themselves store everything as utf8 and all strings made in GDScript are utf8. And in my experience so far no compiler has caused any issues storing utf8 in string_view. (the closest I think of is the GA's Ubuntu distribution of GCC would hang when trying to store a specific utf8 encoded multi-byte character in our testing platform to the dataloader, but wouldn't have any issue storing it in the normal path of the program, it works fine when used, but the test somehow borks GCC when non-ascii characters were there)

[Hop311]

@schombert thanks for the advice, I was using Windows-1252 character codes from previous Vic2 localisation analysis code, changed it all now to use godot::Strings, created from unicode code points in cases where the string literal may be unreliable.

[Spartan322]

Works on Linux