[Iredc]

Hello.
I'm trying to translate a Wonderswan game (Digimon Tamers - Brave Tamer) but I think I've reached a dead-end. Although I found a way to change pointers and have plenty of free space in the ROM, the font of the game is so big, and the textbox so small, that I'm still very limited with the text.
I haven't found much info on this subject, let alone for the Wonderswan, so I'd like to know if there's some workaround for this.

I have thought of several options:
-Reducing the size of the font (specially the width)
-Expanding the screen area which the game identifies as "textbox" so I can add a third line of text (right now, adding a third line causes graphical glitches)
-Turning the current 8x16 font tiles into 8x8 tiles (not sure if it's even possible)
-Inserting additional textboxes (though it seems the number of textboxes is fixed for a given scene)

However, I don't really know where I should begin, or what's the complexity level of this. I might consider abridging the text to fit it in the current screen, but would like to know first if there's a better solution.

[Psyklax]

If the font is currently 8x16, then reducing the width is a no-go - 8 pixels is thin enough. If you have a bit of assembly knowhow, changing it to 8x8 would be a good solution. If you're not familiar with assembly on the WonderSwan, that might be a challenge, though. I can't think of any better solution, other than rewriting your translation to be much more concise.

[Iredc]

I don't know assembly, though I've been messing around with some debuggers. But apart from changing the text color, I didn't find anything related to font sizes. A relative search in the ROM for possible widths didn't bring up anything either.
Well, I suppose I can try to fit the text in the limited space.

[Vanya]

One thing to note is that you are not dealing with a modern font like on a PC where it can be easily resized.

You would have to use the debugger to track down the lines of code that displays text to the screen and change it so that it treats each character as being less tiles than it currently does.

For example if it is currently an 8x16 character it is loading 2 tiles and displaying them on the screen for each character. If you wanted an 8x8 tile you'd need to change the ASM instructions to load only single consecutive tiles for each character and change the graphics as needed. Then you'd have to adjust how far down the second line is displayed in the text box. And finally, you'd have to add new code to have it display a third line of text.

Of course there could be unforeseen complications since I'm not familiar with how your particular game is set up.

[Iredc]

You would have to use the debugger to track down the lines of code that displays text to the screen and change it so that it treats each character as being less tiles than it currently does.

Yeah, this is more or less what I wanted to do. I'm not sure if writing code would be necessary for the third line. The game already shows a third line below the second if you add it in the hex editor. Perhaps reducing the interlinear space would suffice, so it doesn't appear so low in the screen.

I've been using Cheat Engine attached to a Wonderswan emulator (Oswan) and can find the address for the text lines, as well as the instructions which write or access that adress. However, upon disassembling, I haven't found any numeric code which could relate to X-Y coordinates, or tiles per font, or anything similar. I'm sure I'm doing at least a dozen things wrong when using the debugger, so I still need to learn much about this. It's not easy because debugging tutorials aren't aimed at beginners.
I also found this post about a similar issue in a game of the same series: http://www.romhacking.net/forum/index.php?topic=14148.0

[KingMike]

Debuggers aren't usually a beginner topic TBH.

However, I am just guessing the WS/C is a tilemap-based console as most 2D consoles are.
Changing the font size would require knowing how the tilemap works, as well as if the font is a tilemapped font or not.
(if there is a debugging emulator that lets you view VRAM, you would be able to tell if the font is only stored once in the VRAM, then it is likely a tilemapped font. If in VRAM you can view the actual messages printed on the screen, then it is probably not tilemapped.)

[Iredc]

Well, when browsing the memory region I can see the hex data associated with each line of text. It updates every time I click to show the next line.
So I guess it's not a tilemapped font?

[Psyklax]

Well, when browsing the memory region I can see the hex data associated with each line of text. It updates every time I click to show the next line.
So I guess it's not a tilemapped font?

It's still tilemapped. Basically you have two types of video drawing in old computers: you can either draw every pixel independently, or you have a bunch of tiles and them say where you want to put them. The latter needs less memory generally, so it's preferable on old machines. The reason it's changing is because the game has the font stored in the ROM somewhere, but the VRAM is written to with every line instead of the graphics being loaded in from the ROM like on the NES. Most consoles actually work this way, even the Master System does this. For example, if you play Sonic on the SMS (if I remember correctly) the sprite for Sonic occupies the same area of VRAM, and the game just updates that part with the correct sprite. By contrast, unless you use a pretty advanced MMC chip, the NES would have all the animation frames accessible in the ROM, and therefore wouldn't be able to move.

So, in short, it IS tilemapped, it's just that the game writes new tiles into VRAM every time. At least the game doesn't have to switch where it looks in VRAM for the graphics.

[Iredc]

Thanks for the explanation. I thought I'd see in RAM the actual font tile values. So, for example, if the letter "A" uses tiles 01 and 02, and the word on screen begins with "A", I'd see something like 01 02...
Instead, what I see is the the byte associated with A in the table (say, C1).
I suppose it's because I'm browsing an address associated with text, and not graphics?

[Psyklax]

I suppose it's because I'm browsing an address associated with text, and not graphics?

Um... maybe? It's hard for me to help when I don't know what you're looking at.

[Iredc]

Sorry for the delay.
This image shows what I meant: the hex data from the memory belongs to the current text on screen (the next line can be seen as well)

[USC]

Assuming Brave Tamer's dialogue system works the same as Tag Tamer, you might be able to expand the number of text-boxes by adding '0A' after the terminating 'FF' byte for the text. In Tag Tamers, this signifies that the current speaker has more lines of dialogue, and it should keep reading subsequent text instead of checking for the next pointer.

[Iredc]

you might be able to expand the number of text-boxes by adding '0A' after the terminating 'FF' byte for the text.

I tried this but, unfortunately, it doesnt work for this game. The code still reads a fixed number of pointers, so it ignores whatever extra textboxes at the end. I havent seen any other code used in the original ROM for something similar. It's always one textbox = one pointer, even if the speaker is the same.

[Iredc]

Ok, so after messing a lot with the Mednafen debugger, I finally achieved "something". I opened the graphic viewer to check the memory address of the font. Then dumped the proper addresses from memory. In a hex editor, I moved the font hex values one offset above the original one. Then loaded the edited memory in Mednafen.
This the result (before and after):



It looks still wrong because I didn't edit properly all the RAM, but you get the idea.

Is this a good start? I'm not sure how to translate this to a permament change in the ROM, though.