Gb-studio: Multilingual support for generating ROMs

[kultuk]

would like to implement an hebrew translation.

[chrismaltby]

If you mean for the games themselves (as opposed to the app) then it currently only has support for ASCII extended which should cover English and most European languages. I'd very much like to add support for additional languages though.

The way this works currently is in this function
https://github.com/chrismaltby/gb-studio/blob/11124d52d92303d74759554a7a29505a0832031c/src/lib/compiler/compileData.js#L61-L72

which loops through all the strings used in the game and converts them into an array of offsets into the font image.

https://github.com/chrismaltby/gb-studio/blob/master/appData/templates/gbhtml/assets/ui/ascii.png

Potentially could have multiple font images (if someone can provide them) and modify this function to use the right offsets, then probably I'd add a language dropdown on the project settings where you currently set the project name and author to determine which font png to use.

I'd really like Japanese support too if someone is willing to do a png file for it (each character needs to be 7px x 7px)

[kultuk]

Well, the initial intent was to translate the app itself, but ingame support was an issue i wanted to post seperatly anyway.
i'll take a look at the code you posted and try to figure out how to implement it to hebrew.

[kultuk]

And shouldn't you use the same png for all fonts and languages so a game could combine them?

[n-g-g-g]

Don't forget the Chinese language, if we really want make this application 'international', the font function need to have a total redesign.
Japanese language only have 50 characters, and normal (level one) Chinese font have 3755 characters,
make this easy to use AND working on a real GB system is a challenge.

[chrismaltby]

Yeah of course Chinese too, all languages are welcome!

Out of interest how did fonts work on Chinese Game Boy (or any 8-bit / 16-bit system) games? I’m going to assume adding a full character set with a 7px square for each is going to be tough!!

I’d heard that Japanese games often used a reduced character set or only one of Hiragana/ Katakana.

Will probably need a lot of assistance from people who understand this better, but absolutely something that I’d like to see implemented.

[kultuk]

should i open a separate issue for translating the app itself?

[chrismaltby]

Yeah please do, sorry for hijacking this one

[kultuk]

just did.
https://github.com/chrismaltby/gb-studio/issues/43

[SexiestCHiba]

@chrismalby ASCII don't support accent like é è â (French) and ¿(Espagnol) for example , it was better if gb-studio support utf-8

[chrismaltby]

The application is using UTF-8 and does support French and Spanish already.

The tileset image used when building games is actually using one of the extended ASCII versions that does include those characters (see this image https://github.com/chrismaltby/gb-studio/blob/master/appData/templates/gbhtml/assets/ui/ascii.png) the specific version I'm using I believe matches up with the UTF-8 / Unicode characters 32 to 255.

[n-g-g-g]

Yeah of course Chinese too, all languages are welcome!

Out of interest how did fonts work on Chinese Game Boy (or any 8-bit / 16-bit system) games? I’m going to assume adding a full character set with a 7px square for each is going to be tough!!

I’d heard that Japanese games often used a reduced character set or only one of Hiragana/ Katakana.

Will probably need a lot of assistance from people who understand this better, but absolutely something that I’d like to see implemented.

As i remember, the first official released console in China mainland is GBA.
But there are a lot unofficial translated GB/FC games. all of them use reduced cheracter set.
Chinese and some Japanese characters need at least 12x12 px square to display, in that size, usually a 1024x1024 font bitmap is enough. I don't konw whether GB console can handle 1024x1024 bitmap.

There are some 3rd party code can convert font 2 bitmap and generate custom character set, so we do not need to build from beginning, like this one:
www.angelcode.com/products/bmfont/
Is open source.
btw, you need windows 7 to run this program.

[jummy0]

More complex languages like Chinese and Korean would be pretty tough to implement. For example, Pokemon Gold and Silver were playable on the original Game Boy in every version but Korean. The Korean version _requires_ the player to use a Game Boy Color, since its larger VRAM was used for text composition.

Compare these screenshots from the Japanese and Korean versions of Pokemon Gold.

The Korean text is 11 pixels tall, using 2 tiles per character. This is because, while Korean has only 24 unique basic letters, they are combined into over 10,000 possible characters. Splitting each character into two vertical parts greatly reduces the number of possible combinations.

Japanese, on the other hand, requires only about 100 characters, since the more complex ones are represented phonetically. For example, 経験値 (_keikenchi_, "experience points") can be represented as けいけんち (_ke-i-ke-n-chi_).

Unlicensed Chinese games (since the system wasn't officially released there) often used a 15x15 font.

[eishiya]

I'd really like Japanese support too if someone is willing to do a png file for it (each character needs to be 7px x 7px)

Ask and you shall receive (...eventually).

The fist 12 rows contain the Hiragana and Katakana Unicode blocks, minus the last three in each block (which aren't generally used in games).
Although I included characters for the voiced and devoiced kana (ぎ, デ, ず, etc), I've never seen these used in 8px fonts on GB and NES. Instead, only the base forms are used, followed by the dakuten (゛) or handakuten (゜) characters as needed, presumably to save tile space and improve legibility. It would be nice if GBS could offer the option to automatically decompose these characters into base+dakuten/handakuten, for those who prefer the look of that. The precomposed characters get are pretty cramped and use the 8th pixel in each tile in many cases, which can lead to readability issues in some character combinations. Decomposing will pose a challenge in properly limiting the length of the user's input though. You could even decompose automatically and not include the precomposed characters at all, freeing up a bunch of space on the tile sheet.
In addition to the non-combining forms of the dakuten and handakuten, I included the combining forms low in the tile, these are intended to be used on the line above rather than inline (as seen in some NES games).

The last two rows contain a small selection of common kanji in no particular order. They are:
人口出土水子山小少川千心何月火木
金日入氷万目音太犬生先学今年大中
And there's a 円 as the last character on the 3rd line from the bottom.
If you want to cut a few of them to make room for numbers or other characters, these are the ones I'd consider most important to keep, as they're used to indicate days of the week and several of them are also elements (handy for RPGs and such):
日火水木金土月
氷 is also an element (ice) and takes 3 kana to write otherwise (こおり), so I'd prioritize it as well.

Strewn about in the otherwise unused space are 。、「」, CJK punctuation.

Edit: Added some punctuation I'd somehow managed to forget, and a couple more kanji. This sheet is pretty packed, so I definitely recommend some kind of decomposing, so that the (han)dakuten characters consist of two tiles. It would free up about 50 spaces, enough for digits and some one case of Latin, plus more punctuation (see replies below for a great example).

[Animacreep]

I'd really like Japanese support too if someone is willing to do a png file for it (each character needs to be 7px x 7px)

I made a Kana (plus 14 Kanji) converter for GB Studio. It doesn't feature 氷, but you can add it to the _ascii.png_ file and set it to a letter on your keyboard, like _@_, for example.

It would be nice if GBS could offer the option to automatically decompose these characters into base+dakuten/handakuten, for those who prefer the look of that.

My converter automatically decomposes those characters. I'm also making a mini-converter for multi-line Kana. That's typing Kana on one line and the (han)dakuten on another line.

[cubicstyle]

I also support Japanese independently.
Here is my Japanese fonts , I asked some Japanese and selected the characters.

It's built into GB Studio.

I'm modifying for next generation,
GBStudio 2.0 will support almost all Japanese characters.

[RichardULZ]

Indeed @cubicstyle great work on the fork to allow other characters natively, i have considered whether we could expose a key map for adding different letters to a character, but you've expanded the map to a full 256 character set. Have you considered trying to get your branch merged into the master?

I'm not sure if we were planning to/are using character operation codes (normally 0-31) but they could offer performance gains for parsing text, but would break 256 character ascii in the japanese fork.

Considering we are able to load a sprite tile set from any bank in rom, there's theoretically no reason we couldn't add multiple banked ascii sets, with a code to switch between them in game, either on the fly or as an event.

I've thought of whether we could add a dedicated Language variable, which would allow you to change/translate dialogue boxes, and secretly compile a switch event to pick the right dialogue if there was more than 1 translation, based on that variable.
It would be a lot easier than duplicating the game/copying all the scenes...

This could work with or without multiple banked ascii sets, and might even be possible right now as a custom Multilingual dialogue box, that shows tabs for language 0-1-2 and compiles as a switch if more than 1 language is written.

[cubicstyle]

Thanks for the comment.
This folk for use within my Japanese comunity.
I didn't think I would request a merge from the master because it's sloppy modified.

I also agree with the idea of ​​add multiple banked ascii sets.
It solves some problems.

Separately from that, since many Japanese characters are used, if including Kanji , 256 characters map is not enough.
My idea of modifying it in GB Studio 2.0 is to have a font set other than ascii.png.
It's count used characters from text data and create character table using only the used characters.