SHP Forums

Sorry if this is not the right topic.

I have stumbled recently upon the Japanese version of QFG1 for PC98, and had a look into the resource files to see how they included both English and Japanese.
It is actually straightforward enough, and stored as "English\JJapanese" text, with Japanese being encoded in SJIS. (I could confirm this by running SCIComp under Linux with Wine and a ja_JP.SJIS locale made it possible to view the text)

Japanese versions of SCI games have this interesting feature where you can, with Ctrl+L :
- Switch the parser to Japanese or English
- Set the default display language (In QFG1 this impacts some screens which will have Japanese-localized elements displayed like store names)
- Display text only in Japanese or English, or both (if you select subtitle mode)

(The above works perfectly fine in ScummVM, barring a few bugs for some death screens where both languages end up being too much to display)

I was entertaining the thought of translating some SCI games to Japanese in the above style, and from what I understand, I would need to port over some functionality like the above menu, and I simply have no idea how to proceed from there, or if it is even realistically feasible. Is there anyone with advanced SCI scripting knowledge?

From there, I guess translating the text resources would take the most time but could be done with existing tools (though from what I tried, SCIcomp was sort of painful to use for that purpose with Japanese text), and then it should run fine with a ScummVM installation set up with the proper SJIS font.

Welcome to the forums. I split this off into its own tread as it is an interesting topic in itself. There have been a number of fan translations of AGI/SCI games, probably the most famous is Enrico Rolfi's GK2 Italian translation. Translations of SCI games can involve editing a number of different resources. SCI Companion supports SCI0 and SCI1.1, but can open some resources from other versions of the interpreter. Enrico Rolfi's tools can edit some later SCI games. The Sierra Resource Viewer can let you browse, extract and/or export most AGI and SCI resources.

TEXT resources (SCI0) and MSG resources are the main ones that will contain the dialog to translate. you will need to create a font to properly display your translated text, but you may be able to extract it from a game that already has a version translated to your chosen language. Asian languages probably have the added problem of a need for more characters than can be contained in a single font.

In some cases the scripts themselves may need to be altered. Some UI elements Will need to be edited. The menubar can be found in the MenuBar.sc script. For SCI0 and SCI1.1 games Companion can decompile the scripts for editing and recompiled when finished. Other versions you may need to resort to disassembly or hexediting. For help with any scripting problems you can ask on the SCI Programming forums.

Graphic resources are a little more straight forward in how to translate. They can be edited in SCI Companion or with Enrico Rolfi's tools. They might be PIC, VIEW Resources or GUI elements.

The way that SCI games are designed makes for easy patching. Any loose resource files in the game's base or in the patchesDir= path (set in the RESOURCE.CFG) will override the unaltered resources in the main volume file(s).

Also at least by around SCI2 the interpreter has a language flag for the RESOURCE.CFG. This just uses the standard country codes.

Thank you!

Actually, given how displaying Japanese works on the PC98, it requires very specific hardware,
and as you pointed out it does need a specific font but it was never bundled with the game,
it is normally meant to be found within the video ROM on PC98 hardware, since blending of Japanese text was done via a specialized chip after rendering a text box.
Back in the day this was the only way to get fast enough rich rendering of the full SJIS character set.

This is why I planned on piggybacking on what worked for QFG1 PC98, and using ScummVM.
Otherwise, this would require running PC98 emulators, which tend to be a little bit unpractical.

Many thanks again for the pointers!
This should give me a good starting point, just knowing what tools I can use.

What would the minimum number of characters required be?

Very interesting project. I wish you luck!

From what I have seen:
- All EGA SCI games used a font derived from Sazanami Mincho, taking advantage of a 640x400 resolution to display complex messages in a text box (basically, the game prepares a clean area (grey or white) in video memory and asks for rendering of Japanese text in it) -> this can easily go to several thousands of characters (merely phonetic alphabets are a 150 characters, multiplied by two, then you have kanji ideograms, of which 2000 are considered standard for people to know, but computers can handle more)
- Space Quest IV renders text outside of dialog boxes (captions spoken by characters in cut scenes) with a simplified font that only holds the phonetic alphabets + the standard alphabet, and is low resolution (these are regular bitmaps blitted by the system on top of complex backgrounds) ; to be frank these scenes are a bit of a mess to read since you have a lot of pure phonetic transcription to read to understand what is going on.

This is why I'm mainly interested in taking the rendering mechanism for the first type of text (complex) from an existing game, and porting it to another. The second type seems a lot of work for reduced ability to express complex sentences.

It should also be noted that working with ScummVM might save me the trouble of dumbing down the color palette (QFG1 or PQ2 run on a 640x400 12 color mode; SQ4 with a full 16 color)

DarkSoul4242 wrote:QFG1 or PQ2 run on a 640x400 12 color mode

Since you seem knowledgeable about these games, can you please take a look here:
http://wiki.scummvm.org/index.php/Quest ... 01_Version

I took those images and wrote the description but I'm not 100% sure of its accuracy.
The thing is, QFG1 for the PC-9801 came with 2 set of floppies. One supposedly for 8 color systems and the other for 16 color ones (the 2nd set has "16 color only" written in Japanese on the floppies).
They also both come with 2 graphic drivers: 9801V8M.DRV and 9801V16.DRV.
I ran the game in all 4 combinations and took the pictures in the 1st link.

Since you mentioned a 12 color mode, I wonder whether I was wrong about this game. Do you have more information about this?

Sorry; I wrote the 12 color thing out of memory from stuff I had found on a Yahoo Auctions page from last year, and it's likely you are right and that I am recalling things wrong. I will amend my previous comment.

I only started digging around for these versions in 2016, since my wife wanted to give Sierra games a try. (This is actually why I am currently looking into how to translate other games in the same manner)

Collector wrote: ↑Fri May 18, 2018 2:55 pm Welcome to the forums. I split this off into its own tread as it is an interesting topic in itself. There have been a number of fan translations of AGI/SCI games, probably the most famous is Enrico Rolfi's GK2 Italian translation. Translations of SCI games can involve editing a number of different resources. SCI Companion supports SCI0 and SCI1.1, but can open some resources from other versions of the interpreter. Enrico Rolfi's tools can edit some later SCI games. The Sierra Resource Viewer can let you browse, extract and/or export most AGI and SCI resources.

TEXT resources (SCI0) and MSG resources are the main ones that will contain the dialog to translate. you will need to create a font to properly display your translated text, but you may be able to extract it from a game that already has a version translated to your chosen language. Asian languages probably have the added problem of a need for more characters than can be contained in a single font.

I could manage to get the fonts from QFG1JP (font.000, font.300, font.999) with the Sierra Resource Viewer. Yes, it definitely seems like it will be a good idea to replace the initial font with an extended one.

In some cases the scripts themselves may need to be altered. Some UI elements Will need to be edited. The menubar can be found in the MenuBar.sc script. For SCI0 and SCI1.1 games Companion can decompile the scripts for editing and recompiled when finished. Other versions you may need to resort to disassembly or hexediting. For help with any scripting problems you can ask on the SCI Programming forums.

I think I will do that. I tried looking at the Script section in the Resource Viewer, but only found script.XXX files, and could not pinpoint anything that obviously looked like the menu bar at first glance. I think I will take this part of my efforts there.

Graphic resources are a little more straight forward in how to translate. They can be edited in SCI Companion or with Enrico Rolfi's tools. They might be PIC, VIEW Resources or GUI elements.

The way that SCI games are designed makes for easy patching. Any loose resource files in the game's base or in the patchesDir= path (set in the RESOURCE.CFG) will override the unaltered resources in the main volume file(s).

Also at least by around SCI2 the interpreter has a language flag for the RESOURCE.CFG. This just uses the standard country codes.

Actually, I found out that given I first want to try my hand on EGA SCI games, Enrico Rolfi's tools can't open them (the map file is not accepted).

Then open them in SCI Companion, which can decompile the SCI0 scripts so you will not need to fool around with disassembly or a hex editor. It is the first tool to use for SCI0 to SCI1.1 games. If Companion supported SCI32 (SCI2 to SCI3) games there would be no need to use Enrico's tools at all.

I first decided trying my hand on SQ3 to get a better grasp on how everything works, with a less complex title.

I could compare how QFG1 JP and SQ3 display text, and went as far as to find "proc255_0" which I guess is the function used to print messages.
From there, I can only surmise that this is a standard SCI function that has different implementations based on the platform, i.e in my case I would need to set the game as running on a PC98 platform.

I could try to run the original SQ3 data as platform PC98, and the "]|[" special character got displayed differently. This probably means this is enough to change the drawText function implementation to handle the %J separator, but ScummVM refuses to load the game once I tweak it via the SCI Companion.

For kicks, I tried modifying the "Memory fragmented." error text and adding a translation text by taking it from QFG1's JP version. First, it seems I will need to either run this via Wine with a tweaked locale, or via Applocale on Windows. Second, it seems ScummVM will not let me run a game that is not registered, or that the SCI Companion produces something that ScummVM can't parse (I reckon there is a problem with uncompressed resources) : I also tried using DOSBox-X which reasonably runs PC98 games, and to play around with the PC98 SCIV binary bundled with PQ2 or QFG1, adding vocab.* and font.* files as external patches, but the game doesn't start and DOSBox-X goes haywire. (Of course it wouldn't be that easy but I had to try)

I could finally find some time to get back to this project, and realized that the parsing of text and separating different language versions is done within SCI.
This means QFG1 et al. implemented their own parser for "<english>%J<SJIS japanese>", and that ScummVM is merely providing very low level helper functions.

I also got a suggestion from a Russian fan project for translating Quest for Glory 1 VGA to use patch files instead of editing or repackaging resources.
Which means, if it's just figuring out how to write text resource files with scriptable tools, it should be easy enough.
The tricky part, now, will be to port the text resource parser logic from QFG1 in the display function.

I looked into the SCI code and could isolate the bits that handle displaying text resources :
- mainly what the decompiler calls Class_255_0.sc, namely proc255_0 -> it has logic for splitting text resources and displaying them according to global variables, and references font 900.
- some Game.sc class properties for the print language and the subtitle language (global variables that are then used by proc255_0).
- some additional functions in Obj.sc (proc999_{0..5}) that are referenced by the Class_255_0.sc code, to probe at several variables at once and look for the need to use Japanese language.

https://github.com/darksoul42/sq3jp

I have gathered my source code and diffs on github to make it easy to isolate the added code.

My problem now is that while the SCI Companion allowed me to decompile Space Quest 3's code, I can't recompile it :
- Class_255_0 requires the new class variables for Game (I am also confused as to what the kernel_120 function is, but at least THAT doesn't seem to raise an error)
- Game.sc requires a variable named global24 which it can't find (even though it should be defined elsewhere)
- Obj.sc claims the syntax is not appropriate for the use of "&rest" (again, this is code that was provided by the decompiler, but given it will fall back to assembly when it doesn't understand something, maybe it's not perfect)

Actually, in places, I can't even recompile the vanilla decompiled code, which leads me to think that either I have done something wrong, or I should directly gear up and learn how to write SCI assembly.
If possible, I would like advice from a knowledgeable person.

I plan on trying next to just modify proc255_0 so that I don't depend on global variables, even if I end up displaying only Japanese text.

Hi DarkSoul4242!
This thread is very interesting...
Might I suggest you clone it over to http://sciprogramming.com/community/index.php?board=2.0 ?
The SCI Programming boards are much more suited for advanced SCI related topics, and it would attract interest from people who might be able to help you advance your work. For example, troflip, the author of SCI Companion might be able to help with the tool and possibly even improve support for PC98 SCI.

Thanks for the tip, I'll try visiting that board!