gemot encubed  

Go Back   gemot encubed > Gemot > Production & Help > Help with Buriko General Interpreter limitations.

Production & Help For discussions regarding production aspects, especially localisation, of visual novels and related games.

Thread: Help with Buriko General Interpreter limitations. Reply to Thread
Your Username: Click here to log in
Random Question
Post Icons
You may choose an icon for your message from the following list:

Additional Options
Miscellaneous Options

Topic Review (Newest First)
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.
2012-02-11 09:32
EcchiLord 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-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.
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 05:18
EcchiLord 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?
2012-02-05 12:41
Niokun 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.
2012-02-04 18:26
EcchiLord 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.
2012-02-04 17:16
Originally Posted by EcchiLord View Post
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.
2012-02-02 13:36
EcchiLord 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.