MultiByte Language support pack for Irrlicht

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki

Postby Dorth » Sun Sep 28, 2008 6:30 am

Again, this should really be moved into Irrlicht core...
Dorth
 
Posts: 931
Joined: Sat May 26, 2007 11:03 pm

Postby Virion » Sun Sep 28, 2008 8:36 am

Dorth wrote:Again, this should really be moved into Irrlicht core...

i'll second this.
User avatar
Virion
Competition winner
 
Posts: 2141
Joined: Mon Dec 18, 2006 5:04 am

Postby MadHyde » Mon Sep 29, 2008 6:24 pm

I agree.

However, I worry whether to exert a bad influence on users who use only the Latin-1 code by this change.
Please propose a better implementation.
User avatar
MadHyde
 
Posts: 34
Joined: Thu Sep 28, 2006 9:46 pm
Location: Japan

Postby fmx » Tue Sep 30, 2008 8:54 pm

not sure why it isn't already part of the core, perhaps because of the licence/requirements of including the freetype lib with the Irrlicht distro?

I'm not too much of a font-guru myself, but I'll post my thoughts anyway :?

maybe just create a set of custom font grid "bitmaps" with all the required characters for these languages, then create a simple sort of parser which converts the ascii value to a reference number to render out the characters as image-quads?

I currently use a similar method to render plain Latin texts in my non-irrlicht project, and I was planning to use the same method to add Japanese support

I do realise, however, it might become quite tricky when dealing with lots of text onscreen, changing font size, etc.
ofcourse, there's also the slight issue of these bitmap images bloating the end filesize of the Irrlicht dist, and the need to include them with all irrlicht-compiled programs...

or maybe a new "font-type" plugin system for these additional language characters, with all the neccessary image data precompiled (hardcoded) into additional DLL files, then included if they're needed?
I guess it wouldn't need to be Irrlicht-specific then...

tell me if I'm talking nonsense... :oops:
User avatar
fmx
 
Posts: 559
Joined: Wed Dec 06, 2006 9:28 am
Location: UK

Postby MadHyde » Thu Oct 02, 2008 6:35 pm

Thanks fmx.
fmx wrote:maybe just create a set of custom font grid "bitmaps" with all the required characters for these languages, then create a simple sort of parser which converts the ascii value to a reference number to render out the characters as image-quads?

Multibyte languages can be used for original Irrlicht by the Bitmap font, only displays them, isn't it? :wink:

In multibyte language support, there are three problems, input, display, and font.
Most difficult problem is the input, then I want the idea how to implement this.

[INPUT]
"problem"
Multibyte character cannot be input, because Irrlicht disregards WM_IME messages.
"implementation candidacy"
* The WM_IME message processing is added to the core by using imm32 lib. (Need to modify the core like IrrlichtML. imm32 will die gradually in future)
* Hijack irr::IrrlichtDevice::run(). (No need to modify the core like IrrIM Test. Imperfection)
* Use Third party window system. WPF, SDL, CEGUI... and the input is left them. (No need to modify the core)
* Use TSF(Text Services Framework) COM API. (No need to modify the core? The mainstream in near future. But, I don't know how to code... :cry: )

Which is best among these candidates? or don't you have other ideas?

[DISPLAY]
"problem"
Multibyte character is garbled in IGUIEditBox and IGUIFileOpenDialog.
"implementation"
It is necessary to convert multibyte char to wide char. (Not need to modify the core?)

[FONT]
"problem"
Bitmap font is inconvenient.
"implementation"
Use IrrTT class. (No need to modify the core)
User avatar
MadHyde
 
Posts: 34
Joined: Thu Sep 28, 2006 9:46 pm
Location: Japan

Postby fmx » Fri Oct 03, 2008 3:05 pm

Like I said, I'm not a font-guru :P
you're right, using Bitmaps only renders the fonts, it doesn't deal with Input and issues related to Irrlicht's GUI

for INPUT it would probably be best to use either IrrIM test, or TSF.
I don't know much about TSF either but I'll have a look into it and see if its appropriate or how it could be implemented.

I think its about time I contributed back to Irrlicht... been a while since my last endevours (went horribly wrong :wink: )

Can I just ask everyone, what non-Latin languages do you think should be specifically targeted to allow support for in Irrlicht?
I'm personally just trying to get more Japanese support, but I guess Korean and Chinese might also be desirable?
User avatar
fmx
 
Posts: 559
Joined: Wed Dec 06, 2006 9:28 am
Location: UK

Postby MadHyde » Sat Oct 04, 2008 11:59 am

fmx wrote:for INPUT it would probably be best to use either IrrIM test, or TSF.
I don't know much about TSF either but I'll have a look into it and see if its appropriate or how it could be implemented.

OK, I will also research TSF in fuller detail:D

fmx wrote:Can I just ask everyone, what non-Latin languages do you think should be specifically targeted to allow support for in Irrlicht?
I'm personally just trying to get more Japanese support, but I guess Korean and Chinese might also be desirable?

Japanese,Korean,Chinese, and Virion's country Malaysia?
User avatar
MadHyde
 
Posts: 34
Joined: Thu Sep 28, 2006 9:46 pm
Location: Japan

Postby kevincool » Thu Nov 20, 2008 9:38 am

I don't know why the author didn't add the multi-language function .there are a lot of Chinese programmer give up irrlicht because the multi-luanguage problem.Me,too!
kevincool
 
Posts: 1
Joined: Thu Nov 20, 2008 9:35 am

Postby hybrid » Thu Nov 20, 2008 9:52 am

Well, for now you can use this patch, can't you? Anyway, bye :P
hybrid
Admin
 
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany

Postby MadHyde » Fri Dec 19, 2008 5:35 pm

Version 1.5 has been released.
http://etwas.wolfish.org/files/Irrlicht ... 2Linux.zip

- Added EditBox's MultiLine and WordWrap switch support.
- Changed sample apps.
- Broke off the DirectX 8 support in precompiled DLL. (I'm using VS2008 and DirectX SDK - August 2008)

also, I submitted garbled CGUIFileOpenDialog fix patch from this code.
User avatar
MadHyde
 
Posts: 34
Joined: Thu Sep 28, 2006 9:46 pm
Location: Japan

Postby NewerCookie » Wed Feb 04, 2009 6:35 pm

Oh, Thanks, MadHyde!
I just display multibyte on the strength of you
I hope you understand my poor english.
If i used wrong sentence, notify me.
NewerCookie
 
Posts: 20
Joined: Sat Jan 10, 2009 12:53 pm

Postby venomj » Sat Jul 25, 2009 8:15 am

MadHyde wrote:Version 1.5 has been released.
http://etwas.wolfish.org/files/Irrlicht ... 2Linux.zip

- Added EditBox's MultiLine and WordWrap switch support.
- Changed sample apps.
- Broke off the DirectX 8 support in precompiled DLL. (I'm using VS2008 and DirectX SDK - August 2008)

also, I submitted garbled CGUIFileOpenDialog fix patch from this code.

nice work. i read the code but i couldn't figure out how you draw the candidate list window? Why don't you get the candidate list and render them directly?
venomj
 
Posts: 4
Joined: Sat Jul 25, 2009 8:11 am

Postby venomj » Tue Jul 28, 2009 5:27 am

I modified the code to support rendering the IME candidate string list directly in the GUI. Check the pic below, the candidate string list was rendered on top of the red line.
Image
Only avaliable on Windows.
I tried Chinese, but I think all the eastern languagies (mainly Chinese, Japanese and Korean) are supported.
venomj
 
Posts: 4
Joined: Sat Jul 25, 2009 8:11 am

Postby MadHyde » Wed Aug 05, 2009 3:47 am

venomj wrote:nice work. i read the code but i couldn't figure out how you draw the candidate list window? Why don't you get the candidate list and render them directly?

I set only window position. Candidate list window is under the contorol of OS. I'm not doing anything. because that is easy and comfortable.

venomj wrote:I modified the code to support rendering the IME candidate string list directly in the GUI. Check the pic below, the candidate string list was rendered on top of the red line.

Wow, that's great!! :D How did you receive IME Messages? I want you to publish the source :wink:
User avatar
MadHyde
 
Posts: 34
Joined: Thu Sep 28, 2006 9:46 pm
Location: Japan

Postby venomj » Sat Aug 08, 2009 5:29 am

Candidate list window is under the contorol of OS. I'm not doing anything.

Well, you may have problems displaying the candidate list window in full screen mode.
I process the WM_IME_NOTIFY message in CIrrDeviceWin32 to get the candidate list strings. Then I send an event to the edit to display the strings.
I add a minor improvement to display the composition string before the candidate list. Check pic below.
Image
Tell me your email address, I can send you my code.
venomj
 
Posts: 4
Joined: Sat Jul 25, 2009 8:11 am

PreviousNext

Return to Project Announcements

Who is online

Users browsing this forum: No registered users and 1 guest