Quick progress report :
1) I could compile Game.sc by commenting out the Class_255_0 statement referencing global24 only to free it if allocated... except I'm not seeing any other reference to that variable except in Main.sc. Therefore, not feeling TOO bad about removing it, for now.
2) Once doing that, I could compile Class_255_0, but it requires the RESOURCE.xxx file to be repacked with it. It doesn't work with the compiled file exported as a patch. Tricky to figure out, but knowing it did help me make progress. I should have code taking in account the configuration variables for language that ScummVM passes over.
3) I could hack ScummVM into recognizing my patched game as its own thing requiring all the options specific to Japanese, by adding an entry to the detection table, so it would react to my patch files first
Translating SCI Games
-
DarkSoul4242
- Noob
- Posts: 11
- Joined: Thu May 17, 2018 8:04 pm
- Gender: Male
- Location: Japan, Tokyo
-
DarkSoul4242
- Noob
- Posts: 11
- Joined: Thu May 17, 2018 8:04 pm
- Gender: Male
- Location: Japan, Tokyo
Re: Translating SCI Games
Yet another quick report :
1) Space Quest III turns out to be an early version of SCI0 that doesn't have the kernel function calls for splitting language strings, or global variable hooks for ScummVM to implement a language selector ; Trying to force it as a later version has no success. This likely means it is not possible to do a dual display like QFG1 or PQ2 can handle.
2) By overriding the display language in ScummVM when a) the game is SQ3 b) a language string in Japanese is found, I have managed to display complex Japanese messages and simplified Japanese menus
3) Some direct calls to the Display method will require forcing the hardcoded font 300 to font 900 to ensure complex text can be displayed ; not a problem, and further underlines my conclusion that I'll have to make a complete conversion that replaces the text instead of extending it
4) It seems there is a limit on how long a string can be before it corrupts things, as changing the text with a patch is messing around with room changes or such (Crashes when getting to the robot head room, or when riding a trash basket)
5) The text patch format is not too complex so I should be able to whip some easy script to compile an English,Japanese CSV or Excel spreadsheet into final text patches.
The good news is, I can probably manage this on my own. I just got my account approved on SCI Programming so I'll be also relaying my findings from here over there.
1) Space Quest III turns out to be an early version of SCI0 that doesn't have the kernel function calls for splitting language strings, or global variable hooks for ScummVM to implement a language selector ; Trying to force it as a later version has no success. This likely means it is not possible to do a dual display like QFG1 or PQ2 can handle.
2) By overriding the display language in ScummVM when a) the game is SQ3 b) a language string in Japanese is found, I have managed to display complex Japanese messages and simplified Japanese menus
3) Some direct calls to the Display method will require forcing the hardcoded font 300 to font 900 to ensure complex text can be displayed ; not a problem, and further underlines my conclusion that I'll have to make a complete conversion that replaces the text instead of extending it
4) It seems there is a limit on how long a string can be before it corrupts things, as changing the text with a patch is messing around with room changes or such (Crashes when getting to the robot head room, or when riding a trash basket)
5) The text patch format is not too complex so I should be able to whip some easy script to compile an English,Japanese CSV or Excel spreadsheet into final text patches.
The good news is, I can probably manage this on my own. I just got my account approved on SCI Programming so I'll be also relaying my findings from here over there.