Cyber Knight translation

[Bonknuts]

I looked at the code, when in the first town. You're right, there's no pointer table. Not in the traditional sense.

 The text block is parse from the very first string of the block, until it reaches 0x00 (I assume End of String), then decrements the internal counter (which is the string offset mechanism). This is an old (and sloppy) method of text string handling. But on that note, it's easier for you. As in, you don't need to worry about any pointer tables. Simply just replace the strings. Though you'll have to reposition all the proceeding strings, but that's cake.

 You'll just have to locate the block of text. Which, 1) you can do visually if you have a hex editor with custom table/font, 2) could probably do this as you play through the game (find out which bank is loaded at MPR #2 and 3 in the debugger).

[megatron-uk]

Really? It's as straightforward as that? 

I'll have to work backwards from that string I know and find the start - like you say, that won't be difficult (even with the two-char set font table). It looks like there is some extra space to play with (in the case some strings need to be made longer) as there are a block of some 40-odd 0-bytes at the end of that big block of text. This seems to be the case with several other big blocks of text, very useful!

It shouldn't be too difficult to extract those strings now. What would be interesting is to find out what those pointer-table looking structures are though.

[megatron-uk]

Actually, it doesn't seem quite as simple. Certain text blocks appear to use 0x00 as delimiters, but others are missing 0x00 and instead use 0x08.... and (at least) the intro cinematic uses a pairing of 0x04 followed by 0x3C (guessing one is end of string, one is start).

I'll need to work out which block uses which delimiter method and dump it using the appropriate method. Not so bad really though.

I wonder if they all use the same 'scan N strings until you get to X' in order to display the correct text though?

[Bonknuts]

Yes, the routine/code specifically looks for 0x00 or 0x08. I figured you knew what all the control codes do. Is 0x08 a redirection? That's common in game. Strings split and re-continue at other places. It's usually used as a sort of 'compression' for redundant text. BubbleGum Crash game did this.

 If you run out of string space, you can write hook code that uses your own control codes to point to text that's in expanded rom area (again, did this with BGC on PCE).

[megatron-uk]

Yes, the routine/code specifically looks for 0x00 or 0x08. I figured you knew what all the control codes do. Is 0x08 a redirection?

No, I don't think 0x08 is used like that, at least, I've not seen any examples of it used in that context. That said, I've not gone far into the game to see much text, so it may be feasible.

The control codes I've worked out so far are:

00 - Delimiter type 1
02 - Newline
03 - Newline
04 - Delimiter start type 2
3C - Delimiter end type 2
08 - Delimiter type 3
0D - Pad with N leading spaces

I'm going to spend some time playing with the various 2-byte control codes at the start of some of these blocks - they're a dialogue window property pairing.

[Bonknuts]

0x08 is wait for button to be pressed, for text to continue.
0x00 is string terminator (end of string).

 But there's a TST #$01, <$60 instruction, right after fetching the byte from the string. Not sure what it does, but it when the condition is met - it uses a different sets of compares. Looks like the game modifies this. Probably from a control code. I put $01 in there and the game put a bunch of blocks on screen.
 

 It's possible the game uses more than one type of text format/routine. I'd concentrate on the town text first, since that'll be the bulk of the game text.

Edited

[Bonknuts]

All normal control codes appear to be 0x00-0x1f. A few seem to be in the upper range (above 0x7f), but seem to be directly text related (probably japanese accent marks).

 I didn't see anything for 0x3c.

 Read char:
 if >0x20, do...
 else if ==0x5c, do..
 else if <0xDE, do..
else if >=0xE0, do...


 If <0xDE true, then
 if <0xA0, do...
else do...

[megatron-uk]

Yep, 0xDE/0xDF are the accent marks that appear over several characters - I've got them mapped in my table, so rather than printing two characters out when I dump the text, it will print the proper accented character.

[megatron-uk]

0x08 is wait for button to be pressed, for text to continue.
0x00 is string terminator (end of string).

Ah, interesting. That would explain why certain strings (such as cinematics) don't have it, as they automatically close after a short period of time.

[Bonknuts]

That's all for the in town text routine. Not sure about the other routines.

[megatron-uk]

That aside, have you thought about upgrading any of the graphics? They're probably in 2bit/3bit format. If you expand the rom, you could hook the character/sprite upload routine to upload upgraded 4bit versions of the graphics. A LOT of early hucard games used simple 1/2/3bit graphic formats, because there is no decompression resource penalty (planar graphics) and can be uploaded to vram on the fly without decompressing to a buffer first.

I've been loading up the translated version for the SNES to compare things, and you know what? In terms of graphics it's not significantly better.

[ul][li]The ship screens are much more detailed and less blocky on the PCE.[/li][li]The character portraits are more colourful on the SNES, but that gives them a more cartoonish appearance (debatable whether that is better or worse).[/li][li]The mecha detail screens where you choose your weapons etc - the mecha designs on the PCE are much chunkier and detailed. SNES designs are better coloured, but the design are not as good and have a 'plastic' look to them.[/li][li]Overworld map screen - it's pretty close between the two systems, neither of which are particulary great.[/li][li]Town screen - brighter colours but not quite as much detail on the SNES.[/li][li]Dialogue boxes - SNES has transparent windows, but text is much blockier than the PCE.[/li][li]Battlefield screen - this is where the SNES clearly shines, the small non-animated mech/enemy sprites are more colourful and more detailed than on the PCE, which, imo, look horrible. Animations and the larger 'firing' sprites are actually fairly evenly matched, SNES edges it slightly, but the PCE is not significantly worse. One area the PCE sucks at is the ground/grass/sky texture. It's horrible and makes the whole screen look really messy.[/li][/ul]
Out of all of them, the one area the PCE could definitely do with improvement is the battle screen. The
small sprites could do with being replaced and the ground/grass texture could actually do with having less detail, it's very 'noisy'.

[megatron-uk]

The mecha selection screen.

[megatron-uk]

Battle screen.

[megatron-uk]

Oh, and one area where I think the PCE stands head and shoulders above the SNES is the music score. The hard edged synth style music on the PCE really suits the game, whereas the SNES, although having more realistic sounds, just doesn't seem a right fit.

And the opening cinematic. The SNES tries to pull it off with some scaling routines, but it comes off looking corny compared to the anime-style panels showing the SS-Swordfish and the pursing vessels on the PCE.

The sprites in the viewscreen before the jump drive look much better than the very blocky scaling used on the SNES intro.

Still, the battle map on the SNES (although smaller) is much nicer.

[megatron-uk]

I've started work on writing an extractor for the script. It's not anywhere near finished yet, but it can pull sections out and writes a document with the actual characters as found in the font table.

It does basic substitution and uses the correct character based on whether its in pre-font-shift or post-font-shift mode.

In the example I've given an arbitrary address range to translate. It would be useful to firm up the actual ranges used for the various dialogue sections at some point.

EDIT: There's a typo in the extractScript.py file as attached, the SWITCH_MODE byte should be defined simply as "5C", not as hex "\x5C". Change that and the font substitution will work correctly.