I'm a new assimp user, looks good!
One thing which I noticed immediately (using it with Windows 8/WinRT) is that the file names are char*, whereas, on the WinRT / Win#@ API all code is using wchar_t*
I'm going to hack it and solve it on my own, yet, if it was part of the library it would be nice!
From: Thomas Schulze <thomas@dr...> - 2013-02-18 18:40:56
Am 18.02.2013, 13:40 Uhr, schrieb Lloyd Dupont <ld@...>:
> I'm a new assimp user, looks good!
Thanks for the nice words!
> One thing which I noticed immediately (using it with Windows 8/WinRT) is
> that the file names are char*, whereas, on the WinRT / Win#@ API all
> code is using wchar_t*
> I'm going to hack it and solve it on my own, yet, if it was part of the
> library it would be nice!
Nope. The WinAPI does use wchar_t* only if your Visual Studio project
settings are set to "Unicode". But nobody actually does that, everyone
else besides the Visual Studio default settings uses UTF8 for
internationalization and therefore still passes strings by char*. I
haven't tried WinRT, yet, but the WinAPI functions I know of all exist in
two versions: FooBarA( char*) and FooBarW( wchar_t*). I guess this also
holds true for WinRT. You can explicitely select one of the options by
name, or use the FooBar() makro which in turn routes to one of them
depending on your project settings.
Of course I do not expect you to change your global project settings to
use with Assimp and port all of the existing code. Instead I suggest to
either use the MultiByteToWideChar() group of functions, or implement an
Assimp custom IO interface that takes char* but silenty reinterpret_cast<>
to wchar_t* and then employs the Widechar options of the WinAPI.