I am chinese , and I use jme3 to build an project about mine drill. I tried much to solve the gui problem,when i using javafx and swing ,but all make me sad ,so i want to know that do the niftygui support chinese to show on the screen?
I think the nifty gui renderer uses BitmapText for text.
BitmapText can render many Chinese characters.
BitmapText currently has a problem with some Chinese characters (it can only render the first Unicode plane - plane 0 - plane zero). I’m working on something that will fix this BitmapText problem too.
I currently don’t know yet if BitmapText can be fixed or if everybody will need to use my new BitmapText2. If the old BitmapText can be fixed - then I will write a pull request for the jme team. But it will need some more time - you could try to fix it before I do, but the code is very tedious.
You will need a .fnt font that has all the Chinese characters that you need. This can be generated by the AngelCode BMFont.exe bitmap font generator. It will need a true type font as input (e.g. the hanazono font).
The AngelCode bitmap font generator is now open source (he released the sources some months ago). So maybe someone wants to make a better bitmap font generator for the jME SDK. The old one doesn’t seem to work correctly and it has fewer features than AngelCode’s bitmap font generator.
It’s simple that if you only need to display Chinese charactors on GUI, just learn about BitmapFont. Then make a .fnt asset and use it in your project.
However, if you want to allow user to input any Chinese charactors in niftygui, it’s not supportted.
The problem is LWJGL can’t work well with your Chinese IME like Sogou IME or Google IME. I don’t understand why but it just happend.
IME is a software tool to type in Chinese characters? Tell me more about this please - until now I just use Google Translate and then copy-paste a Chinese text into my jME code. I do not know how Chinese people actually type in their Chinese characters.
Maybe we can fix this problem along the road, to make jME more international.
IME is short for input Method Editors, it’s a MS product. Most people in China use Windows OS, so many of us need IME to input Chinese charactors.
Some big company like google, tencent develops their own IME and us just use what we like. This is Sogou IME produced by Tencent.
As I know, there are also some IME softwares on UNIX.
Thanks, that info was good.
Then we need to integrate these IME for Windows, Linux, Mac.
So - just to make sure - if you decide to use one particular IME then you always will use that one and can’t automatically know how to use an other IME? Or is it like this: when you know how to use one IME then you know how to use any / all IME ?
If it is like “when you know one then you know all” then I could make a software IME for jME. I doubt that LWJGL will ever support an IME out of the box. So writing an IME with Lemur might solve the problem. It could be the same tool that lets you select Emojis (yes, I’m also working on that).
thank you for your reply
I think this one is better (at the moment):
It can only run under Windows. So if you are on Windows, then it will work as advertised.
Interesting … 2x “thank” == 1x “Thank you”
IME is a kind of software, not one software, which we use them to input Chinese. There are different methods to type Chinese so we have different IMEs.
When we want to type Chinese characters, we need to learn one or more skills. At first Chinese characters is a pictograph, it has both shape and sound. The shape has its meaning and the sound we can talk to each other.
One kind of IME, just need us to remember every sound of each characters, we call it “pinyin” means the the spell of sound. (Each character like a b c we spell it a little different from English).
Eg. “你” spell “ni”. “好” spells “hao”. These kind of IMEs should recognize “nihao” as “你好” when I typed them on my keyborad.
The problem is, LWJGL handles every keyborad event and accept the word as nihao, but in fact we need to Chinese characters “你好”. I think the input system should have ablity to accpet words from IMEs instead of keyborad.
Besides, AWT and Swing did this really good.
Another kind of IMEs, they recognize the shape of Chinese characters.
As most Chinese characters are group by small pieces, we make every key on keyborad stand for one or more single shape. When we type different keys in a specified order, the IME must know what it is.
Eg. “碧” is group by “王”, “白” and “石”, someone just need to type GRDF then he has “碧”.(Don‘t ask why GRDF…You won’t want to learn the rules, it is not easier than you learn Chinese)
This is really interesting, 谢谢.
It should not be a problem to support this system “pinyin”. Simply have a text field that accepts the string “ni hao” or “nihao” and then make a new string “你好” from that. To improve that, we could make an “intelligent text field” from the normal text field (as soon as another letter combination is entered, we try to match the String and replace it, then in the same text field we can continue to type). The problem is when you have also some similar english words like “night” or “nifty” (contain “ni”) or maybe some english words are exactly the same letters which would be an even bigger problem when mixing those with pinyin words.
The other system “shape system” would be easy too - I just need to know which key stands for what and then lookup in the Unihan.txt or similar data source. The UCD (or more specifially the Unihan database) has some dictionary information that I can parse and put into the new BitmapFont2 system.
By the way … just yesterday I looked over some Unicode documents for Chinese and it seems that they also have some new symbols each year. I also know some things about Korean and Japanese writing systems (have used the “Batang” and “Hanazono” Fonts before - Batang is Hangul and Hanazono is Japanese and Chinese consisting of two files because there are so many characters that they don’t fit into one true type font file).
Also it seems that Chinese character fonts are a little different depending on “style” - e.g. how you draw the characters in Chinese and how you draw the characters in Japanese. My question: Can you still understand characters that are in Japanese style?
I hope that I can provide something useful in the future. I’m currently working on better Unicode support in the new BitmapFont2 system.
I think the problem is how to know a user use IME and accpet input from IME.
Yes, my idea is to make a custom IME inside jmonkeyengine.
Since they all seem to be very similar and the rules might always be the same.
That seems like an achievable task and it would use everything as it is (LWJGL etc.).
I have one problem with that though: jME seems only to read English keyboard layout - for example: I have a German keyboard layout and some keys are different (" Ö Ä Ü " become useless things like " ? ] # " and if I want to press " ? " (question mark) then something other than that is received by jME.
-> I guess the same problem of wrong keyboard layout might become a problem for pinyin too…
I don’t know if and how “nifty gui” deals with keyboard layout.
I’m not yet at the point when I need to implement my own “text field” class.
The custom IME could be made with “nifty gui”, but I would try to make this with “Lemur” first - so that pspeed has no opportunity to take a nap and will be forced to answer questions and update the Lemur code… :chimpanzee_wink:
Problem is that LWJGL handles input near hardware level, not on software level - game developers usually need as fast input response as possible. While IMEs you are talking about are operating on software level.
If it were me - I’d just add possibility to listen to input on software level and switch between hardware/software depending on current needs - player character control goes from near hardware level while typing text into text field turns hardware listeners off and enables software listeners affected by OS and whatever special software you use.
Not sure if it’s possible to achieve this in a such way though.
On the other side @Ogli is talking about making own IME based on data from near hardware level - it will work for sure but requires more time to be invested while potentially giving more flexibility and better visual results.
Yes, you are right. I just think that it’s too difficult to make a IME.
I have read the source code of Nifty-gui and toneg0d-gui, they just accept input from LWJGL, and LWJGL accept input from keyborad, that’s the problem.