Still not perfect but good enough

Further investigations and comparisons finally lead to success. Now Japanese DIG looks very close to original. There are still slight differences in how the subtitles are positioned on the screen, but I consider it as a good enough (ScummVM is on the right):



Our code differs too much from the original Blast Text rendering routines, so to make a pixel perfect rendeting I would need to rewrite all of that code. Still I consider it to be good enough and if someone else in the future would want to tickle it a bit more, he is welcome.

Besides Japanese Kanji fixes, new code also fixes line breaks in Korean and Chinese versions of SCUMM 6+ games. I did not test it, but with old code there were cases when longer strings were not split in a proper way. As a side effect there are slight changes to versions which use Latin characters, so there could be potential regressions. File a bugreport if you will notice any chopped subtitles in FT, DIG or COMI. Read More...

Kanji got more fixes

Finally I managed to make all Kanji in Japanese DIG rendered. 

It appeared that somebody (ahem) just is not able to count, even with help of a calculator. 
japanese.fnt was not read completely and thus it got read past the array bounds.



Still there are certain problems with rendering. As seen on the right screenshot, proper line breaks for Kanji just do not work, also text positioning is not perfect. I am still in process of comparison with original, and the code there is quite hairy. Stay tuned. Read More...

Kanji struggle

For the last several days I was trying to add support for Japanese DIG. It was reported in this bug report.

For some reason there is a bug with Kanji processing in our code. You may see it in these two screenshots (on the left is original and ScummVM is on the right):



As you may see, Kanji 出 (de) is rendered as garbage. Basically it looks like all Kanji is rendered bad. Investigations and test runs showed that computation of offset in font file (SJIStoFMTchunk() function) is correct, but the function produces value behind the font file end. Probalbly there is some preprocessing on font load. Need to clarify that too. Read More...