Closed MarkCallow closed 10 months ago
This may not be as simple as adding _UNICODE
or enabling wide-string support in MSVC, as it can have wider implications across the entire software stack. Unfortunately, unicode support in Windows is quite a mess.
We certainly should look into it sooner or later.
This may not be as simple as adding _UNICODE
It isn't. The ktxtools target compilation fails when _UNICODE
is defined. I'm working on fixing the legacy tools. We can judge from there how wide the implications will be.
It isn't. The ktxtools target compilation fails when _UNICODE is defined. I'm working on fixing the legacy tools. We can judge from there how wide the implications will be.
Sure, what I meant it that it also may not be as simple as fixing the compilation issues. I had my fair share of pain in the past with various Windows unicode support related quirks. We'd have to do an initial investigation and see how it may affect the tests. Now that we have good coverage it should make it easier to get confidence with any solution. We may also want to add unicode file tests, but that could also be another painful trip to get them running across all platforms :)
If you try to open a file with a name that includes characters needing more than 8-bits to represent then the open fails with an error message like:
The actual file name is this case was
スカイボックス.ktx2
.In fairness the legacy tools are broken. Building with
_UNICODE
defined causes a compile error. I was alerted to this by #764 and am working on a fix. For the legacy tools we will need to define _UNICODE when building the Windows packages.