|
Forum > Translation Efforts
Viper RSR Translation
(1/7) > >>
Gamen:
Hello, I'm new here.
I know there was a project for translating Viper RSR, and that it has died a few times. I'm not sure if it produced anything. I did read that most of the game was translated, but that the WIN file format needed to be reverse-engineered. I don't know what the status of that is. I've seen a bunch of tools in some threads, but I don't know if any of them can be used to update a WIN yet. So.
I've been writing code for handling SGS formats for a while. Every year or so I get the urge to take a look at what I've written, and see if I can add more to it. Usually with the goal of writing some sort of WIN+ANM to GIF converter. Don't know if one exists. At any rate, this time I was distracted and wrote a script to export all the dialog from each .WIN in a .DAT. And then another to update a .DAT with translations. So.
File name: rsr_translation_patch_20110728_h_scenes.zip File size: 134.38 KB
There you go, a patch. It really only translates the various H-scenes, and a few other lines. It's also missing Diablo's lines in that one scene. His language escapes me. Drop it in you RSR directory and run the batch file, which'll backup your existing SGS.DAT before patching. It's for the DVD edition, I don't have any other. I'm guessing most have it too, given the extra scenes I hear it has compared to older versions. Some translation is mine, some from other members of the forum, I don't remember whose is what. It's really more a proof of concept to show that the WIN files can be updated. Excuse what is translated by me, I switched majors to Computer Science from Japanese Language & Literature because I was failing.
I'm also attaching a .csv (renamed to .txt) with all the unique strings, and what I have for translations.
It'd be great if this is all that was holding the project back.
JG:
--- Quote from: Gamen on July 28, 2011, 05:45:55 pm ---I know there was a project for translating Viper RSR, and that it has died a few times. I'm not sure if it produced anything.
--- End quote ---
Not dead, but suffering from a lack of qualified translators. What you've done should be of tremendous help to the project.
--- Quote from: Gamen on July 28, 2011, 05:45:55 pm ---I did read that most of the game was translated, but that the WIN file format needed to be reverse-engineered. I don't know what the status of that is. I've seen a bunch of tools in some threads, but I don't know if any of them can be used to update a WIN yet.
--- End quote ---
Yes, I've managed to work that out already. At least enough to do text translations, including decompile and recompile. There's still some graphics commands I have not worked out but those would go unchanged in a translation. Becuase I have not figured out so many graphics commands I've withheld the release of my toolset. (And unfortunately have not found much time int he last couple of months to improve upon it)
--- Quote from: Gamen on July 28, 2011, 05:45:55 pm ---I've been writing code for handling SGS formats for a while. Every year or so I get the urge to take a look at what I've written, and see if I can add more to it. Usually with the goal of writing some sort of WIN+ANM to GIF converter. Don't know if one exists.
--- End quote ---
If I could figure out all the graphics commands, I could make this happen. I'm able to partially decode the WIN, already known how to decode the ANMs, and know how to construct a GIF. Unfortunately missing key peices of knowing exactly what ANM frame to show when and where to make it work.
Perhaps we could combine forces and get my compiler/decompiler suite finished and released to the masses. If you're interested, read through this thread, and then see if you can use OllyDbg and help me figure out exactly what some of these opcodes actually do (I know what some of them do, but not why they're different than another opcode that may do practiacally the same thing, or know what some arguments do but not others.) This offer to help is open to anyone with sufficient coding background (being able to follow x86 assembly code is a must.)
See attached for my compiler/decompiler's operations table.
Gamen:
Well, you've definitely done much more work in actually deciphering the opcodes. I really only got a little beyond disassembling the interpreter loop so I could parse the instructions and identify jump targets.
Right off, however, I can identify opcode 76 for you. I'm pretty confident it pops up a dialog for the player to enter their name, as in Typing, when printing text the character ＄ is replaced with it. The name is of course stored in the registry as Name.
Edit 1: And I believe the first argument of opcode 3E is the register the index of the selected choice is stored in. Same with its i18n version, opcode 69.
Edit 2: And I believe the first argument of opcode 17 is the index of the layer to be scrolled, like you seem to already have deduced but still marked as unsure. Side note, I've been thinking of them as layers, probably because of Flash.
Gamen:
Well, since I can't post to the thread you reference, I'll add to this one. Might have to start a new one, since this one does specify the topic as being translation, not reverse engineering.
Opcode 64h: The interpreter loop is skipping over instead of parsing the arguments, but here's the format:
[64h] [uint8 shifts] shifts*{[uint16 frames] [uint8 colors] colors*{[uint8 index] [uint8 red] [uint8 green] [uint8 blue]}}
And I'm pretty sure it's a palette shift. It loops between the <shifts> changes to the palette, updating the palette with the <colors> colors and waiting <frames> frames between each shift.
Opcode 44h: This is not a no-arg opcode. It's format it the same as opcode 45h ([44h] [uint8 register]), and has almost the same functionality. Since it sets the animation state to Ah, the interpreter loop terminates and control passes back to the animation loop, where it pretty much idles, waiting for the user to give it some input (specifics to be eloborated on... ctrl, f11, and f12 are bad, d-pad and numpad good). When it gets that input it reads a uint8 from the bytecode and stores the input flags at the register.
Opcode 45h ([45h] [uint8 register]): Does almost the same, except a lot less. Ends autoskip and stores the current inputflags at register <register>.
...And I'd say that's good for now. If you have a particular opcode you want to know more about, as long as it's not for internationalization, I'll see what I can give you for details. Otherwise I'll just continue randomly looking at this thread and my notes for missing details when I have the time. Maybe I'll detail the switch/case ops next (32h, 33h, 48h, and 7Ah)
JG:
I'm quite sure opcode 44 has no arguments. The only thing it does is set system state.
--- Code: ---00414EE6 |> C705 04084300 >|MOV DWORD PTR DS:[430804],0A ; Case 44 of switch 00413321
00414EF0 |. E9 76100000 |JMP SGS.00415F6B ; jump to end of opcode switch
--- End code ---
Thanks for figuring out system state 0x0A waits for input from the d-pad though.
Navigation
[0] Message Index
[#] Next page
|