gemot encubed

gemot encubed (
-   Production & Help (
-   -   Help with Buriko General Interpreter limitations. (

EcchiLord 2012-02-01 09:09

Help with Buriko General Interpreter limitations.
1 Attachment(s)
Hello Guys,

I'm a member from a brazilian amateur visual novel translation group and i'm currently translating the game Shuffle! to pt-br language. Even though i'm not a programmer, i do know how to deal with command line tools for extract/insert scripts & resources.

The engine is Buriko General Interpreter v1.69, and i can extract the resources with AnimED, as well decompile the scripts with this BGI tools, but i'm experiencing some technical problems in this project.

Most of them are related to the text and the script files, but there's some other issue about the main menu options and ending credits (are they really images anyway?).

The BGI Tools for (de)compiling the script files are made with python 3.2.

Well, here's the problems:

1. Some times, when i'm converting a script file back to BGI bytecode, i get a error called UnicodeEncodeError from the, here's the error below:


Trying to fix this problem i've retranslated again the same script file using a new decompiled .txt archive, and again the same error has happened.
Fortunately (and strangely) it was only one script file that i get this error.

I'm using this settings in the to decode & encode BGI script files:


2. I kinda understand what may be happening in this one, but not completely. From what i could see, the BGI engine only allows 58 characters per line, then activates wordwrap. Now, the brazilian portuguese uses accented characters like ç,á, ê, õ; and when a word that ends with a accented character trespass the 58 limit, it doesn't separate correctly. Here's a image of the "wrong" wordwrap:

In this case, the word "você" should be on the second line, but only the character ê is there.
In my opinion, i guess the engine thinks that an accented character is another word, so that's why this happens, but, i'm not sure if this is true.

3. Also, another thing related to the text, i think the engine only allows three lines of text, so when i have more words, it just don't show up on the screen and the rest of the line gets cut off. I don't know if it's a limitation of the engine (very probably), because there's some lines in the mangagamer translation that they've decreased the font size, hence fits more lines in the game. I guess if i could have total access to the source code of the engine, maybe it's possible to modify like the mangagamer did, but unfortunately the BGI tools only decompile script file with some references where it needs to be replaced the translated text in the original bytecoded script. Is there a way to increase the number of lines even though i don't have access of the script commands?

4. Finally, the last problem (but not so relevant, i guess). Although i have extracted all images from the game, i can't find the options in the main menu (Start game, Load, Config, etc...), as i coudn't find the credits from the game as well. But i do have found some characters images which is the same font used in the main menu.
Now, my guess is that if i'm not finding the images but those characters instead, maybe the options are some internal script commands that use this font to print on the screen the options and the credits? Well, i really don't know that either...

In case of comparison, i've attached both script files, the original unmodified dumped script, and the translated with the UnicodeEncodeError problem.

Please, if someone knows how to fix, at least one of these problems above, i'll be very grateful.

Best regards.

arkady18 2012-02-02 03:41

There are a ton of ways to fix the wordwrap thing, but you need a hacker for the other issues.

Basically, I have two ideas to fix the wordwrap. The first one is to manually make the word "você" going to a new line. You can do this in a several ways. The best one would be to know what's the in-game code to do this. I don't really have experience with BGI, so I don't if and what is the code. A few games I worked on used the code \0A to send the text to a new line. You can try this, but I'm not sure that it'll work. Another way (this will surely work, since your game doesn't use a proportional font) is to add 4 blank spaces to make " voc" go to the next line.
Of course these two methods are bothersome, so it would be better to ask a programmer to make you a tool to do one of these two things automatically.
The other idea I have is to use "fake characters", which is the solution I use to make non-unicode games recognize «»àèéìòùÈÉ and similar characters. You need to edit your font making a character you don't use (for example the character *) look like one of the characters you need (for example ê), and then you have to manually change all the ê into *. Of course, this is a bothersome solution (and you need to change the default font, and you might need a hacker to do so), but it's just to show you that there are several ways to fix the wordwrap thing. I personally suggest you to add enough blank spaces to make the text go to a new line.

I painfully understand the problem of having only 3 lines available... Just think that I have the same problem, but having Japanese as original language, not English (that takes many more space in the text box). You may need a hacker to solve this. Basically, what you have to do is at least one of these things: reduce the default font size, reduce the space between two lines, make the text start a bit more up and a bit more on the left, increase the lenght of the line.

EcchiLord 2012-02-02 05:47

Well, i too have thought of insert blank spaces on the game, but the problem is that, there are some lines that coudn't be fully translated if i use them, because of the three lines limitation problem. That way it won't have room enough for the translated lines that are bigger. I tried your code \0A, but i didn't worked.

In case of changing the font size, i'm afraid i can't do this either since the tools only decompile the text into references, so i don't have access to the in-game commands.

Here's a example of the dumped script:


For the change font thing, i do know how to hack the ipl._bp (file that controls the display font), but when i try to change the font to another, i get the characters with some line-like things surrounding them, as well the spaces between them are more larger, and some of them gets cut off by half (the capitalized ones), but i can still see the characters even though they seem strange.

If you think my explanation is weird, see this image below:

In this test, i've used Times New Roman, but i've tested with other fonts and the same problem happened. What kind of problem could be that?

The three lines limitation, well, even if mangagamer couldn't change that, even though having the development kit in their hands, maybe that it's a natural limitation of the engine (at least i see it that way), but i can be wrong.

For the fake characters i think its possible, since i've done this in the past in some test, but when i try to use other font, i get the characters in that strange way, so i would need to fix that problem first.

In the end, just like you said earlier, the methods above would be bothersome, but if its the only way to fix the wordwrap problem with accented characters, then its ok with me. Of course, if there's a better solution it would be great, but as long as i can fix that, is already good.

About the line limitation, the internal options and the encode error from de compiller, i guess my only hope would be to get help from a hacker, but the only hackers that i heard about it are from tlwiki, but i've never spoked with any of them, so i'm not sure if they're available to help me with this. I've tried to communicate with p4s (a.k.a Proger_XP), but he's not responding the email.

Well, thank you for answering me.

arkady18 2012-02-02 06:57

Sadly, I don't know how to help you. The only problem I've ever had with edits to the default font was that when I reduced the font size the letters were doubled because the engine wanted them to be as long as they were with the original size (don't ask me why) and I solved (thanks to a hacker, of course) doing what I said before. So now I have 4 lines with 61 characters instead of 3 lines with 54 characters. I could ask to my hacker, but sadly he's too busy and when a few days ago I asked him if he could help a friend of mine he said he couldn't because he was (and still is) too busy.
Anyways, if you manage to reduce the font size and the space between two lines you should get a fourth line somehow. Just a question: does the fourth line appear in the backlog?

However, you could try to use another font. For most translation projects I suggest to use Sazanami Gothic or Sazanami Mincho. Probably the problem with the font is that you use a font that is proportionally spaced. Sazanami fonts are not proportionally spaced. You can as well use this font we used for our Italian translation of Mahoyo trial:
It's an edited version of the font Ume Mincho S3

EcchiLord 2012-02-02 08:15

Yes, the fouth line that gets cutted off does appear on the backlog. Does that mean something?

About the reduction in the size of the font, it's also possible, but apparently only if i could have access to the in-game commands (mangagamer did this, and gets 4 lines in some parts of the game when the text were too big). I'm gonna search to see if i can find out about this problem.

I've downloaded your font Ume Mincho S3, modified de ipl._bp to read it and works very well, there's no more problems with the strange characters, but instead, now the accented ones have turned into japanese characters (kanji as well), but i undestand that cause i didn't modified yet to the edited ones.

Do you know what are the corresponding characters to the accented ones that have been modified in this font, so i can test on the script?

arkady18 2012-02-02 08:43


Yes, the fouth line that gets cutted off does appear on the backlog. Does that mean something?

(mangagamer did this, and gets 4 lines in some parts of the game when the text were too big)
mean that

i think the engine only allows three lines of text
is wrong. It was just to confirm.
I don't know how you can have access to the in-game commands. The problem is that those commands are probably cut out by the tool you use to decrypt the files. And probably they're crypted in the original files...

You should try to search very well in files like ipl._bp to see if you find where Manga Gamer setted the default font size. It's not like the game knows by itself which is the default font size: it was Manga Gamer to tell it which size it had to use. It should be written somewhere. In the worst case scenario, the default font size may be setted in the exe of the game, but I don't believe it's like this, since the name of the default font is in the file ipl._bp. Unfortunately, I've never really tried to translate a BGI game, so I don't know where you should search. It should be one of the files included in system.arc archive.


but instead, now the accented ones have turned into japanese characters (kanji as well), but i undestand that cause i didn't modified yet to the edited ones.

Do you know what are the corresponding characters to the accented ones that have been modified in this font, so i can test on the script?
I'm not sure I understood what you're saying. It was me the one who edited that font and the only edits I did were things like decreasing the width of “”«» and fixing the size of capital accented letters like È, since the original ones were too "short".
I don't know what you mean by "the corresponding characters to the accented onesthat have been modified in this font", since in the font I sent you there are all the accented letters you should need:

EcchiLord 2012-02-02 09:41

Then i think i've missundestood you, my apologies.

But i've already changed my script file with the characters on the font you sent me, and this is what i get:

I don't know if could be a encoding problem, but just in case, the script is on cp1252.

If i change back to the original font, the characters are displayed normal.

summarizing, the problem with the proportional characters is gone, but now the accented characters are displayed like japanese, even though i'm using the ones in the Ume_Mincho_S3 font.

About the font size, is not always tha the size are decreased, only in some lines that happens, so it really must be a internal command that is crypted and the tool ignore it.

arkady18 2012-02-02 10:08

I really don't know what could cause the problem to the accented letters. Try Sazanami Mincho. Here you can find the original version, without any edits.

EcchiLord 2012-02-02 13:36

Ok, i'm going to check it out this Sazanami Mincho, and try to modify by myself some characters, and see if works for me.

Oh, and i got some progress on dissassembling ipl._bp file, here's the file dissassembled with bgi_asdis tool:


I know it's a lot of code, but maybe it can be useful to find out about the font size problem.

rye 2012-02-04 17:16


Originally Posted by EcchiLord (Post 69887)
1. Some times, when i'm converting a script file back to BGI bytecode, i get a error called UnicodeEncodeError from the, here's the error below:


You get this error because there is a character which doesn't exist in the target encode. ej. trying to put chinese letters in ansi.

to fix this, change the encode in the setting of the tool.... but this is strange. the character ê exists in cp1252.

EcchiLord 2012-02-04 18:26

Yes, that's exactly what i thought when i saw the error, all the characters that i've used in the script does exist in cp1252, so i can't really understand either what's happening.

Well, i think about a possibility:

Since the output of decompiled scritpts are UTF-8 (which supports more characters), maybe, for some odd reason, and by human mistake (or not), some kind of character from other encode could be there, but not showing up on the script file?

I don't know if even make sense my theory, but i'm not expert on deal with this kind of problem, so forgive me if i'm saying something that's unreasonable.

Niokun 2012-02-05 12:41

I think your problem is solved now. But just so everyone can see how it was done, the function must be inserted inside the script file (decompiled using and is written like this:

line("Game_xxxx_xx.bss", yy);

Game_xxxx_xx is the scenario script file (the extension-less one inside data01000.arc)
yy is the "function number". Can be any number, even repeated in the same script file, since the script in run in a synchronous form.
n1 changes the type of font. Only 0, 1 and 2 are considered valid values.
n2 changes the font lenght. Size is in pixels, and the number must only be between 8 and 22.
n3 changes the font height. Size in pixels. I haven't found any size that pauses the game (but it can get cut in the dialogue, if the size is too large)
n4 makes the font look like "Bold", like in Microsoft Word. Only accepts "0" (normal font) and "1" (bold font)

Just a reminder, xxxx_xx, yy, n1, n2, n3 and n4 values can only be in integer decimal numbers.

As of time of posting, I sucessfully tested all these parameters on Shuffle! game, but I believe it is the same on other games that uses BGI engine like Da Capo and Kira Kira. I'll edit this later to confirm this.

EDIT: Apparently, only the Shuffle! game using bgi has this function working properly. All Navel's games actually works on Lucifen Engine, which is totally different from bgi. However, MangaGamer done a conversion to bgi using tools only the Navel staff has acess, so this is the only game that uses BGI that can have the font size changed...that is, unless you can hack the .exe of other BGI games and insert support for this kind of function.

Also, I'm checking this problem about the BGI bytecode. Like Rye said, these kind of characters are included on cp1252 library, but it still refuses to run...when I get some progress I'll reply to this thread again about a solution.

EDIT: Using bgi_dump and bgi_insert, you can, indeed, insert cp1252 characters just by modifying the bgi_setup file. However, the same does not apply on bgi_as and bgi_dis just by editing their files and editing When using the pseudo-assembly code, lots of characters can be an issue if not used right. For example, scripts edited on these tools cannot have more than 3 commas or 3 quote marks, and depending on the position of these characters, not even 2 of them, let alone trying to make cp1252 characters work on cp932 engine. I really recommend using just bgi_dump and bgi_insert when editing bgi scripts, since they're much more flexible and less obnoxious than using those other tools.

EcchiLord 2012-02-06 05:18

Thank you very much Niokun! I've tried to modify the BGI Bytecode using this method and really works. The tool is &, from the bgi_asdis tools.

That way is possible to change the font size like manga gamer does, so that way the three lines limitation problem it's solved ^^

Well, since we've been in contact via MSN, you say something about the in-game images and options, and really, they must be on the sysgrp.arc.

But unlike the CGS and sprites from data02000.arc which is automatically converted to .bmp image files, either CRASS or AnimED can't seem to extract & convert them.
AnimED does extract the content, but in case of CRASS, it doesn't even do that.

Does anyone knows any tool that can convert the image & animation files from the sysgrp.arc?

Niokun 2012-02-06 06:20


But unlike the CGS and sprites from data02000.arc which is automatically converted to .bmp image files, either CRASS or AnimED can't seem to extract & convert them.
AnimED does extract the content, but in case of CRASS, it doesn't even do that.

Does anyone knows any tool that can convert the image & animation files from the sysgrp.arc?
ExtractData v1.20 automatically converts those files to .bmp. And speaking of animation files (like transition effects), they're found in Data02000.arc instead. Sysgrp.arc contain images from menus and options, save thumbnails, and so on.

2012-02-06 08:46

Menu images of Shuffle! (and all other BGI-based VNs that I've encountered so far) are stored in sysgrp.arc ("system graphics", I presume). ExtractData and Crass are able to extract these images as BMP files, whereas AnimED is only able to extract them in their compressed state.

As for the edited images, I'm not aware of any tool that is able to convert bitmap files into "DSC FORMAT 1.00" format, though reversing the Huffman + LZ algorithm shouldn't be that hard. In any way, you don't need to do that, since BGI reads uncompressed image files just fine.

EcchiLord 2012-02-11 09:32

So, i've manage to extract the images from sysgrp.arc and convert them to .bmp files using ExtractData, but the problem is that the size of each file gets from 400kbs to 1.37mb, each 800x600 image file.

The original sysgrp.arc is around 16mbs, but when extracted, the whole content goes to 71.1mbs.
Although the BGI engine reads uncompressed images, their size are much bigger than the original.

I don't really care much about reconvert to DSC FORMAT 1.00, but is just that i wanted to make the translation patch as light as possible. But the game works the way it is, so, if really there's no way to compress back to the BGI image format, then is fine.

2012-02-11 10:49

On the bright side:


sysgrp.arc:                                      16,1 MB
sysgrp.arc, RAR'd:                              15,2 MB
sysgrp.arc, extracted in BMP format:            72,2 MB
sysgrp.arc, extracted in BMP format, then RAR'd: 12,9 MB

In other words, even though translated images will take up more space on a user's computer when extracted, it will result in a smaller patch for you to distribute, since you can utilize a more efficient compression algorithm than Buriko's.

All times are GMT -8. The time now is 15:53.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2023, vBulletin Solutions, Inc.