search

eugeneloza / decoherence

Project moved to https://gitlab.com/EugeneLoza/decoherence
GNU General Public License v3.0
10 stars 7 forks source link

Windows encoding bug is back :) #131

Open eugeneloza opened 7 years ago

eugeneloza commented 7 years ago

see https://github.com/castle-engine/castle-engine/issues/66 I have no idea on how this error occurs or disappears... I wonder if this depends on "exe" file or game data encoding?

eugeneloza commented 7 years ago

Maybe recompillation of game data in https://github.com/eugeneloza/decoherence/commit/001fa8d1ab80bcfa4364d5ece0f9cf2e9a635b43 caused this? This version sees to have been working properly https://github.com/eugeneloza/decoherence/commit/f8923027fefa115019824ea3d07b511d97e11603

eugeneloza commented 7 years ago

Now that's remarkable. I didn't change anything related to the issue (only updated CGE), but the encoding bug is not visible again. Hmmm... what might cause it?

eugeneloza commented 7 years ago

(UPD) No, the bug is still there, and it's the fix I've returned back that fixes it.

eugeneloza commented 6 years ago

See also http://forum.lazarus.freepascal.org/index.php/topic,38383.msg260416.html#msg260416

eugeneloza commented 6 years ago

Test needed: it might have been fixed in new read/write methods as they don't require any sort of converting.

michaliskambi commented 6 years ago

Note that CGE had an important change around the string encoding: see https://castle-engine.io/wp/2018/02/02/playing-animations-backward-build-tool-output-dir-fast-rendering-to-tglimage-and-other-new-features/ . Since then, string (AnsiString) is always (on all platforms) assumed to have just UTF-8 encoding. This is the same behavior as when using LCL (Lazarus components), and it should make things simpler and error-free around the encodings.