SFML community forums
General => Feature requests => Topic started by: dewyatt on July 09, 2008, 05:21:23 am
-
I think sf::Window::Create should be able to take a std::wstring for the Title.
I understand it's easy to convert the title and then call Create.
But I'm binding some of SFML to a scripting language which requires wchar_t*/wstrings.
Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.
Lastly, I believe sf::String should draw on/above the baseline, not below it.
In other words I think this:
(http://i107.photobucket.com/albums/m300/silentdae/229f96ff.jpg)
Should be like this:
(http://i107.photobucket.com/albums/m300/silentdae/e227bedd.jpg)
Where the yellow line is the Position specified.
-
I think sf::Window::Create should be able to take a std::wstring for the Title.
Yep.
Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.
Improving all the unicode stuff is in the roadmap.
Lastly, I believe sf::String should draw on/above the baseline, not below it.
That wuold probably need some thinking ;)
-
I think sf::Window::Create should be able to take a std::wstring for the Title.
Yep.
Great!
Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.
Improving all the unicode stuff is in the roadmap.
Ah. I feel a little stupid as I forgot about the roadmap.
Lastly, I believe sf::String should draw on/above the baseline, not below it.
That wuold probably need some thinking ;)
hah. I just thought it seems weird the way it draws now.
I don't use sf::String but I was using it as a reference when working on my sfmlTTF library and noticed this oddity.
Changing that would mean users will have to change all of their positions.
But I think it would be more intuitive and standard.
-
I think sf::Window::Create should be able to take a std::wstring for the Title.
Yep.
I was about to ask for that too, great. :)
Lastly, I believe sf::String should draw on/above the baseline, not below it.
In my opinion, it would confuse a lot of users (including me), because sf::String is like sf::Sprite and GetPosition should give the upper left corner.
-
Lastly, I believe sf::String should draw on/above the baseline, not below it.
In my opinion, it would confuse a lot of users (including me), because sf::String is like sf::Sprite and GetPosition should give the upper left corner.
It may confuse users at first, but it really should be done.
Users coming from other libraries may find it confusing that it doesn't stick to this standard.
See http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-3.html
-
I ran into another problem with all this Unicode stuff.
I need to bind sf::Image to Squirrel (in Unicode mode).
But LoadFromFile takes a std::string not a std::wstring.
I see that SFML uses SOIL which does not seem to support Unicode filenames.
Looking through SOILs code, it looks like these two functions would need to be overloaded/changed:
SOIL_load_image
stbi_load
It's a quick change.
But this would mean whenever SFML updates to a new release of SOIL, the SOIL code would have to be patched each time.
I was wondering if SOIL is the best choice for the image library behind SFML.
I don't know how heavily it is used but there are certainly alternatives that directly support Unicode filenames.
FreeImage supports it.
DevIL has it on the TODO list I believe.
-
Well, as you said it's a quick change and if I do it the author will certainly integrate it into SOIL next release.
I'm not going to change the underlying image library, because SOIL is lightweight and do almost all the job (with the help of stb_image) in only 3 source files which can be included directly into SFML source code. All other libraries need to link with libjpeg, libpng, libtga, ligtiff, etc... for which I need to get the libraries for every version of every target compiler for static link.
Anyway, just for my personal information, who's using Unicode filenames ?
-
Well, as you said it's a quick change and if I do it the author will certainly integrate it into SOIL next release.
I'm not going to change the underlying image library, because SOIL is lightweight and do almost all the job (with the help of stb_image) in only 3 source files which can be included directly into SFML source code. All other libraries need to link with libjpeg, libpng, libtga, ligtiff, etc... for which I need to get the libraries for every version of every target compiler for static link.
Anyway, just for my personal information, who's using Unicode filenames ?
I figured you wouldn't want to change the library, just thought I'd suggest it.
I do like that SOIL is lightweight.
I'll just make the necessary changes to SOIL.
As far as who's using Unicode filenames...
People with a non-english OS really expect support for it (and they have every right to).
I probably won't use it personally but my game is extensible and will allow for it.
-
If it's only for the binding purpose you could load the file into memory and then use sf::Image::LoadFromMemory.
-
If it's only for the binding purpose you could load the file into memory and then use sf::Image::LoadFromMemory.
I realize that, but thank you anyways. :)
I didn't want to work around the problem like that.
I've already changed SFML+SOIL to allow Unicode Image::LoadFromFile though, so all is working now.
I love Squirrel. Such fun :D
-
I love Squirrel. Such fun :D
I agree. Squirrel is quite nice.
I started to embed it just a few days ago. :wink:
It lacks documentation though.
-
I love Squirrel. Such fun :D
I agree. Squirrel is quite nice.
I started to embed it just a few days ago. :wink:
It lacks documentation though.
Yeah I really wish it had more documentation/tutorials.
It even says on the front page "The documentation has to be improoved." (improved...).
I'm using SqPlus but I'm considering just using straight Squirrel.
If I do switch, I found Ogre3D bindings (OgreSq) that could serve as documentation a little.
-
If you decide to switch, the source of the Squirrel standard library also turned out to be helpful (+ some japanese site :P).
-
If you decide to switch, the source of the Squirrel standard library also turned out to be helpful (+ some japanese site :P).
Oh nice! I hadn't thought of looking through that!
Oh and do you have a link for this Japanese site?
-
http://muffin.cias.osakafu-u.ac.jp/~matumoto/cgi-bin/xt.cgi?prog/squirrel
It seems to be down at random times. If there is nothing on that site, try again later...
That + Squirrel source code provides pretty much all information I need for the system I intend to create.