The Cost Of Global Compatibility
Today I hit yet another roadblock standing in the way of completing the game engine's renderer DLL. This time, I stumble through supporting Unicode characters for the engine...
Little did I know when I began this project that a simple difference in OS configuration would require so much development time to learn about!
To explain, in addition to being an avid game player and budding game designer, I'm a fan of anime, and occasionally will find a Japanese-language game that I'll want to play. Thankfully, the Internet usually is able to provide fan-made English translations of these games which render them intelligible to me, but most of them still require Japanese character support to be active in Windows. While adjusting my OS to achieve this support has not affected my everyday use of Windows, I have noticed that occasionally a program will erroneously conclude that I'm not running the English version of Windows.
Such was the case today, where through debugging some compiler errors in the code samples provided in Zerbst and Duvel's book, I found that Visual Studio had defaulted to using the Unicode character set that makes programs compatible for localizing to non-Latin alphabets! The practical upshot of this was that all of the standard Windows functions that should take char and char* instead take wchar_t and wchar_t*! You may recall that in an earlier post I mentioned my confusion that the authors defined many of their variables with char instead of the wchar_t that my compiler was telling me I required. Well, here's the explanation! Clearly, the authors of the book used chars because they work just fine if you're not dealing with Unicode.
The clearest solution to all of this would be to simply switch my project defaults back to a smaller character set, but honestly I think it will make for an interesting modification challenge to work through the entire project adding Unicode compatibility. After all, in our globalized world where many apps and games require localization outside of the Latin-alphabet languages, it would certainly be better to learn how to construct a system that supports Unicode from the get go, don't you think?
As a final note, I'd like to add that I'm thinking I will change the format of the summaries I've been including in the bottom of each post. Up to this point, I've been providing a recap of what I've gotten done in the timespan that the post covers, plus a note of what I plan to do next. However, since the purpose of this project is for me to learn many new things, often by overcoming unforeseen obstacles, I don't really think a description of what I plan to do next is very useful. After all, the past three posts have all stated that my next planned milestone is to complete the implementation of the renderer DLL, but for each subsequent post I've been sidetracked by a new obstacle, and with it a new learning opportunity that I would be remiss in not writing about for this blog! So, I've decided to remove the "Coming up next" portion of the post and simply let what's next reveal itself as I work.
Progress So Far: Fixed the code samples given in Zerbst and Duvel's book to support the Unicode character set.