Translating Cotton 2

nanash1

New Member
I decided to try to start my first translation project because I'm kinda bored right now. I chose to translate Cotton 2 because it seems like a good first project for the following reasons:

  • It's my favorite shmup on the Saturn
  • Being a shmup there is not that much text (though more than in some shmups)
  • The text isn't very complicated (which is good because my Japanese is not very good)
As I said there is not that much text there. The menus are already in English, so I can keep them as they are. What remains are the following items as far as I can tell:

  • Opening text crawl
  • Opening character sheets
  • Animated sequences between the stages
  • Hint texts when you die
  • Maybe the Maniax.txt on the CD (you can't see it in game though)
So over the last few days I looked around in the game's files to decide if a translation is feasible and came to the conclusion that it is. However, there are some challenges that I need to overcome. The opening texts are just three images that are scrolled over the screen. The images are contained in the file CHR_TTL.MF, but they are compressed with some form of LZ algorithm if the header is to be believed. I'll have to figure out what of the many variants of the algorithm is used.

The assets for the animated sequences are located in a series of other MF files. I've only looked at the first one CHR_VS0.MF, but I assume that the others are similar. The file contains a 16x16 Japanese font. There is no English font, so I will need to edit the Japanese one. Since a 16x16 English font will look ugly, I need to change it to a 8x16 half wide font. This shouldn't be too difficult, but it could be a bit tedious. Next the spacing between the characters needs to be changed. Luckily I already figured out how to do that by changing the draw command's assembly code that is contained in VS0.bin.

Currently I'm trying change the timing of the animated sequences, because I'll need to draw more characters for the English text as Japanese is usually written more compactly. If I manage to do that, my next step would be to convert the font into something I can edit comfortably. Since the font tiles are interleaved with image headers, I can't get them to display properly in the tile editors I tried so far (tilemolester and crystaltile2). Maybe someone here knows how to do this better than me and can give me a hint. Otherwise I'd probably try to convert the tiles into pngs so that I can edit them in Photoshop.
 

klarth

New Member
Hey, good luck on this one! I was considering working on it at some point too since its also my favorite shooter on the system.

Since you located the text drawing routine for the animated text, you could also modify it to use a 16x16 variable width font, if that happens to look better. All you need is a buffer and an algorithm to control spacing, then copy the result to vdp2 or vdp1.

Have you taken a look at the arcade version for the stv? Not sure if there might be anything to gain there. Possibly lack of compression which might help? Or might just be identical.

For viewing the font you probably need to write a tool to extract it if it isnt linear in the files. Ms Tea made a tool in Rust for lunar that takes pngs and converts them to the 16x16 font format lunar uses. It might be a starting point for reinsertion of a new font.

 
Last edited:

nanash1

New Member
Since you located the text drawing routine for the animated text, you could also modify it to use a 16x16 variable width font, if that happens to look better. All you need is a buffer and an algorithm to control spacing, then copy the result to vdp2.
In theory coming up with an algorithm for a variable width font shouldn't be too hard, but I've no idea how to do it in practice. Wouldn't I have to recompile the entire binary file that contains the drawing routine?

For viewing the font you probably need to write a tool to extract it if it isnt linear in the files. Ms Tea made a tool in Rust for lunar that takes pngs and converts them to the 16x16 font format lunar uses. It might be a starting point for reinsertion of a new font.
For now I wrote a program that strips the headers. I tried to convert the result to png, but the colors are messed up. Seems like I didn't really get how colors work in the VDP1. Time to read the manual some more...
 

klarth

New Member
For the vfw you would probably need to rewrite a portion of the drawing routine, jsr Or jmp to a new area of code due to the extra instructions required, and then return. You could write in asm or C and paste the binary into an unused area. For the C binary make sure to link in needed libraries. I use the gcc command line tools in saturnorbit

Easiest way to add code is to either overwrite something thats always in memory thats no longer needed or increase the size of something that gets loaded in and is always there. Then theres no extra cd load to memory code required.

An existing kanji table since you wont need all of it anyway works well. In your case that might not be an option. It sounds like the kanji gets swapped in and out per scene? (Of course you could copy the new draw routine into all font tables) You could also add to the end of the initial executable and increase the load size in the game header. Im assuming thats always in memory since its a simpler game. You would need to check and see how much unused space follows that executable in an emulator. That would be the code size limitation there
 

paul_met

Member
If the image data is not compressed, there is no need to write any specific software to display it correctly. All this can be done with standard tools like Tilemolester or CrystalTile2. Don't waste your time writing utilities for a specific game. It is better to spend time studying existing utilities. Believe me.
--------
You can view the location of the palette in the texture description in the VDP1 debugger of Yabause. If the palette is represented as 4 BPP(16 color LUT), then it is located in VDP1 memory. Otherwise, it is in VDP2 CRAM.
 

nanash1

New Member
If the image data is not compressed, there is no need to write any specific software to display it correctly. All this can be done with standard tools like Tilemolester or CrystalTile2. Don't waste your time writing utilities for a specific game. It is better to spend time studying existing utilities. Believe me.
--------
You can view the location of the palette in the texture description in the VDP1 debugger of Yabause. If the palette is represented as 4 BPP(16 color LUT), then it is located in VDP1 memory. Otherwise, it is in VDP2 CRAM.
My problem with these tile editors is that their function is somewhat limited and I've never used them. I know how to use Photoshop, so I think it's faster for me to just convert them to png. I already have a working program that does that. At the moment I can't wrap my head around how the color banks mode works exactly. I know that the game uses the color bank mode thanks to Yabasanshiro. It also tells me an address that I suppose is the bank address in the VDP2 CRAM. If I look at that address, however, there are only zeros to be found. The documentation tells me that I need to add the 4 bits of pixel color to the color bank address, but this way I could only address 8 bit colors so there must be something I'm missing.
 

paul_met

Member
You can use these tile editors to view any graphics correctly. Tilemolester supports any palette. You can load it from an address, or from a separate file.
If your palette is in CRAM, then you should divide its address by 8 (for normal screen mode) or divide it by 4 (for Hi-res mode) - for 16 bit and 8bit color mode respectively.
 

Attachments

Last edited:

nanash1

New Member
Thank for the help, but I still don't understand how the color banks work. Basically I used YabaSanshiro to export a bmp of one of the font tiles. Then I checked the RGB values of the colors and reconstructed the 16 bit color values. This allowed me to find the color palette in the CRAM. The color banks are actually written repeatedly throughout the entire CRAM in 0x1000 offsets. The palette that I need always starts at offset 0xA0, so I assume it's bank 5. How I should have gotten that from the information "color bank: 00018280" that YabaSanshiro displays I still don't understand.

Edit: It has gotten pretty late again, but I can show the first result. For this test I didn't bother to adjust the spacing. Also I forgot to create an empty tile as space between words. But in principal it seems to be working.
 

Attachments

Last edited:

rorirub

New Member
It would be nice to see this game with the English translated text in it. Someone already translated all of it:
 

fafling

New Member
@nanash1 First, Yabause and YabaSanshiro have a bug in the VDP1 debug screen which shifts the color bank by 3 bit to the left. So the hex value 18280 should actually display 3050. Shameless plug : this bug is corrected in Kronos.

The color bank is a 16 bit parameter of the drawing command that VDP1 uses to complete the 4 bpp texture pixels to obtain 16 bit framebuffer pixels. VDP1 uses the 12 upper bits of the color bank for that.

To understand the structure of the framebuffer pixels, and the color bank bits that they contain, you have to check the sprite type displayed in General info in VDP2 debug screen. Here it's type 5. The sprite types are described in VDP2 manual p. 201. Type 5 uses the 11 lower bits of the framebuffer pixels for color RAM index.

So for the font tile framebuffer pixels, the 4 lower bits (DC0 to DC3) come from the texture, and the rest is from the color bank. It means that the 7 upper bits of the color RAM index (DC4 to DC10) are bit 4 to bit 10 of the color bank. Adding those bits to the texture pixels is just like adding the hex value A0 that you have found.

Note that VDP2 can offset the color RAM indexes of the sprites with the color RAM offset, also displayed in General info in VDP2 debug screen. Here it's 0, so it changes nothing.
 

nanash1

New Member
Here is a small update on my progress:

As shown in the picture I posted before, I've got a font ready. It still needs some touching up, but I like how it looks. It fits the style of the menu font and with the adjusted spacing, I don't think a variable font spacing is necessary. I can also easily change the characters that are displayed, so showing my own text already works. However, there is also a problem. When I try to insert more text than the scene is programmed for, the text will glitch as soon as the dialog starts. At the moment I'm trying to figure out how exactly the scripting in the game works. I don't really understand how it functions at the moment, but at least I've got some leads.

It looks like the scripting has nothing to do with the MF files. They just contain pictures and instructions on the sequence in which to load them. Some of the pictures are just placeholders though. For example the line feed character. So they must be interpreted as instruction by the text box routine in some way. But, as I said, this probably has nothing to do with the scripting as such. The scripting seems to be handled in VS0.bin. There is group of functions that have an initializer called "EventManager", going by a string that's still in the compiled file. These functions seem to be responsible for the timings of the scene. At the core there is a long list of 44 byte wide entries. I know that the first 4 bytes are function pointers. The game goes through this list and executes the pointers according to some rules derived from the rest of the 44 bytes. There are also functions that edit the list when certain events occur. For example when the text box is disabled before the dialog starts. Getting to the bottom of it all won't be easy, but for now I think it's doable.

I hope that once I figured it all out. I'll find a way to pause at the beginning of scene and display more text before the screen starts to scroll downwards.
 
  • Like
Reactions: vbt
Top