Serait-il possible de rajouter la prise en charge de langues asiatiques ? J’aimerais juste pouvoir rajouter du texte en chinois.
Sur TGF2 j’avais du coller des images de word pour faire mon logiciel (je vous raconte pas la place et le temps que ça prend…).
J’ai essayé de coller du texte en chinois sur GD pour le moment ça me donne aussi des ???. Serait-ce parce que je ne sais pas bien me servir du logiciel ?
Je crois qu’il n’y a que moi ici qui me préoccupe de la possibilité d’écrire des caractères chinois dans mes applications 
Dans ces conditions, je comprends que ça ne soit pas une priorité pour la version prochaine. Tant pis 
C’est une histoire de prise en charge de UTF-8, non ?
Ou unicode, je sais jamais …
Faut aussi vérifier si la police choisie gère bien les caractères asiatiques.
Je viens de rentrer de mon séjour de Chine, là-bas j’avais du mal à accéder au site…
Pour taper du chinois sur Game Develop j’ai essayé plusieurs façons, ça ne marche pas… Et honnêtement ça serait dommage de retourner sur the games factory juste à cause de ça. Sans compter que si je le fais, il faudra que je repasse par la caisse rien que pour leur extension unicode, ça me coûtera 30 euros. Le problème c’est que ça m’est indispensable : si je ne peux pas entrer des caractères chinois je ne pourrais pas développer mon logiciel comme je le voulais… Snirf !
Le problème, c’est que Game Develop est en ISO-8859-1 et pas en UTF-8. 
Il faudrait sans doute que je compile la bibliothèque d’interface utilisateur utilisée par GD ( wxWidgets ) en unicode et non plus en ANSI. Je ne sais pas si ça résoudrai tout, mais peut être une partie des soucis lié aux langues ayant un alphabet non latin.
J’essayerai de passer à ça à l’occasion, mais dans l’immédiat je peux pas promettre grand chose 
Faudrait aussi dire au revoir au std::string et utiliser les sf::String.
Je ne pense pas, en faisant quelques recherches il semble que “std::string is encoding agnostic”. Après, manipuler une std::string qui contient de l’unicode peut être périlleux car un élement de std::string ne correspond pas forcément à une lettre. Dans ce cas, il vaut mieux utiliser std::wstring.
Il y a une page assez complète la dessus ici : stackoverflow.com/questions/4022 … -stdstring
Mais ça reste assez casse tête.
C’est déjà gentil de se pencher sur le sujet…je sais qu’on ne peut pas contenter tout le monde. Dans l’immédiat, je me doute que d’autres personnes proposent des modifications plus utiles à la communauté.
Merci quand même !
Comment ??? Tu n’utilises pas le build Unicode de wxWidgets ?
Tu devrais vraiment, celui-ci étant plus stable et beaucoup plus puissant.
Totalement faux !
dans la bibliothèque standard, toutes les classes de chaîne (oui, il y en a plusieurs) sont basées sur std::basic_string, un template qui prend en paramètre le type qui doit être utilisé pour stocker les caractères.
Ainsi, la version non-unicode utilise std::basic_string
Et la version unicode utilise std::basic_string<wchar_t>
Vous apprendrez également qu’il existe une autre classe de chaîne appelée std::wstring pour l’unicode, mais je n’en vois pas trop l’intérêt puisque (pour le GCC qu’on semble tous utiliser ici, celui de TDM, au moins) std::string est un typedef vers la chaîne unicode. J’ai, dans mes headers quelque chose comme
class string: public basic_string<wchar_t>Donc ce n’est pas un problème.
Pour revenir à la question originale, et bien qu’il faile ABSOLUMENT que 4ian compile GD avec la version unicode de wxWidgets puisque, comme le dit sa documentation officielle :
http://docs.wxwidgets.org/trunk/overview_unicode.html#overview_unicode_supportin
Je pense que le problème ne vienne pas de wxWidgets lui-même (ni de sf::String qui n’est pas ou très peu utilisée dans GD) mais j’hésite entre :
Cause 1
Le problème vient du mécanisme même de copier-coller de windows, auquel cas il n’y a rien à faire (à part se plaindre à Microsoft qui ne lira certainement pas ce que vous écrirez puisque leur feedback n’est là que pour faire bonne figure d’après une source sùre que je ne peux pas nommer).
Cause 2
Le problème vient, non pas de wxWidgets, mais du contrôle de texte natif de Windows qui ne supporte pas lui-même l’unicode. La solution serait d’appliquer le style wxTE_RICH ou wxTE_RICH2 à tous les contrôles d’entrée de texte (http://docs.wxwidgets.org/trunk/classwx_text_ctrl.html) qui causerait l’utilisation par wxWidgets d’un contrôle beaucoup plus riche (on parle du contrôle qui se cache derrière l’interface de traitements de texte comme Office ou Works) et qui, lui, supporte pleinement l’Unicode.
Je suis moi-même partagé, bien que la deuxième option me semble bien plus vraisemblable.
Mais bon, je vous laisse tester ça, hein ?