News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - USC

Pages: [1]
Newcomer's Board / Font suggestions to match Japanese Font Style?
« on: August 30, 2020, 11:12:07 pm »
Hello! I recently got a Mega Drive/Genesis Mini, and being able to play my own work on official hardware has inspired me to go back and polish some of my old patches. First and foremost is my addendum to Rent a Hero.

I'll actually be releasing an interim fix (v0.98) shortly that deals with several text issues people have emailed me about. One of the main things I'd like to do though, is create better town name graphics on the map:

Any suggestions on an English font that would look similar in style to the original Japanese one? Or at least look better than the hand-drawn one I made myself?

Newcomer's Board / Alternate GBC pointer formats?
« on: November 27, 2019, 10:38:10 am »
Hello all! I've been playing around with translating Soul Getter for the GBC:

I've got the texting encoding and control characters figured out, found the dialogue blocks, and coded a script extractor. But I haven't been able to find the pointer tables with my usual methods. I was hoping someone could check my work and see what I'm missing.

The first two lines of dialogue in the game start at 0x121AFE and 0x121B11 (there are other lines before it in the ROM file, but these are the first you see in the game). That would make the pointer values FE 5A and 11 5B, correct? There's only two places in the ROM with 11 5B next to each other (0x10EC70 and 0x1098E), and neither have FE 5A anywhere near it.
Further more, the next line of dialogue 0x121B23's pointer value (23 5B) doesn't seem to exist at all in the ROM.

I then checked to see if it was more of a block-based pointer (so it links to the first line of dialogue and then just reads forward). I moved the second sentence's starting point earlier, but the game still read from 0x121B11. I suppose the pointer

Any thoughts? I'm probably missing something really obvious.

Personal Projects / [GBC] Tabaluga Translation - Released
« on: December 07, 2018, 06:50:17 pm »
Hallo zusammen! If you're not familiar with Tabaluga, it is a popular series about a young dragon who has to protect his kingdom of Greenland from a snowman that wants to cover it in ice. In addition to a cartoon series, movie, musical, and audio CDs, a Deutschland-exclusive Game Boy Color game was released in 1999.

I've played through the entire game, so in theory it's now fully translated into English. However, I am notoriously bad at proofreading and noting typos and alternate orders for dialogue, and I would like to minimize the number of correction emails I receive.

If anyone's interested in testing the translation patch before I submit it to be enshrined at, feel free to send me a message. Thanks!

Newcomer's Board / Text overwriting previous line in menus (WS)
« on: September 16, 2018, 09:14:25 am »
Hello! I'm currently working on Digimon: Tag Tamers for WonderSwan.

I've got an issue with new text overwriting the previous line in several sections of the menu. Here's a quick example from the Maps:

In all cases, it *does* write out the full line (which is good), but anything past 10 characters is replaced by letters from the line below it (unless there's nothing below it in the menu).
I'm not quite sure how that works - maybe it allocates the number of characters for each line as it loads them, and then draws everything at once based on what's in memory at the end?

Any thoughts on how I could figure this out and fix it? I assume I'd need to set a read breakpoint at the second map name's pointer (16317C, 4 bytes) and see where it takes me, but if anyone's seen this pattern before and has advice, it'd be appreciated.

Latest Updates (May 2020) in the bottom post
Prologue Video

Hey everyone! This is a project I've been working on and off for a *very* long time. It's basically tracked my improvement as a programmer - from knowing nothing, to now knowing slightly more than nothing. Now that I've strategically applied duct tape to an old editor I built entirely out of duct tape, I can once again work on this translation without corrupting the entire file!

This post is mostly to force me to finish the game this time, but I'm hoping for some useful feedback too if anyone can spare some.

What's been done so far?
-Storyline and Post-Game cutscenes
(Script provided to me long ago for this part, mostly)
-Digimon names
-Items and descriptions
-Attacks and descriptions
-Battle and System text
-Dungeon and Village NPCs
-Graphic Compression/Decompression algorithm
-DigiCode hints
-WonderWave instructions
-Digimon Bios

What's left to do?
-DigiCode hints*
House A & B dialogue, the last of the NPCs
Shop dialogue
-Compressed Graphics: 95%
(Just the title screen)
-Digimon Bios: 100%
-WonderWave and link cable specific text

*Translated but not yet put into the game

How can I help?
Aww, thanks for asking!

1. Recommend a good beginners tutorial on debuggers and breakpoints!
--There's a few issues with formatting that I need to fix, and I don't know where to look in the file. I've heard Mednafen has a good WonderSwan debugger, so I'm hoping I can learn how to use it to solve the problems. If you're curious...

This picture highlights the two biggest issues.

I need to move Digimon names further to the left to fit on-screen (since the longest one is now 16 characters as opposed to 10 in the JPN version). Also, it looks like the data storage is hard-coded to start at certain points, so it overwrites the longer English works. E.g. The start of the HP data is overwriting the last part of "Vacc.", and "Mega" is overwriting the last part of "Magnadramon". Different status screens have different text cut-off points, so I assume there's a definition somewhere in the ROM that I could hex edit to shift the write points over.

Programming / Building an Auto-Patcher
« on: June 14, 2018, 12:17:05 pm »
Hello everyone. I'm in the process of editing a PC game that would have benefited from another round of proof-reading (E.g. Line overflows and typos in the main story-line, tutorial graphics that contradict the text, clear copy & paste mishaps, etc). This consists of using janky, Japanese-only tools to unpack files, convert the extracted files into editable formats using more black-box tools, make the changes and then do everything in reverse. Not difficult, but also not the most user-friendly workflow.

Ideally, I'd like to release my work as an executable auto-patcher, so that even casual Windows users can easily install and use it. However, I've never built one before, and I fear my initial idea of writing a wrapper that applies a byte-to-byte patch to 1.5GB package files is not the best solution.

Any conceptual advice on how to go about this would be appreciated. Thanks!

Gaming Discussion / SNES Mini... and Star Fox 2
« on: June 26, 2017, 01:13:15 pm »

Wonder if this Star Fox 2 will be any different than the translated beta version? :)

Newcomer's Board / Recompression Algorithm Advice
« on: September 12, 2016, 10:54:03 pm »
Hello all!

I managed to figure out the graphics compression for Digimon 02: Tag Tamers and wrote a simple decompressor script (super duper proud of myself). Now I need to find a way to cram my new changes back in... and I'm not quite sure how.

Decompression overview

The graphics are 2BBP: 00 00 is a black line, FF FF is a white line, etc. The compressed image starts with some meta data (length/width/location, how many tiles will be drawn, etc).

The data is partitioned off with single opcodes that determine how much of its section is uncompressed. For instance, if the section starts with FF:
*Convert to binary, 1111 1111.
*Read from right to left
*If it's "1", the hex value at that position is uncompressed (read one byte)
*If it's "0", the hex value at that position is a compressed opcode (read two bytes)

An FF section reads in 8 bytes before the next section, a 00 section reads in 16, and anything in-between reads in 8 < x < 16 bytes.

If we hit an opcode, then we're repeating a certain amount of lines/hex codes that were already drawn.
In the opcode, the first byte multipled by 16 is how many bytes you go back to start repeating. The following byte is split in two; the first nybble can be used to go back an additional number of hex codes, and the second nybble tells us how many bytes to repeat... plus 3 (since a two byte hex code that only draws 1 or 2 is a waste of space, haha).

Example: 01 45 would go back (1 * 16) + 4 hex values, then redraw the next (5 + 3) hexcodes from there. If it hits the end of the drawn lines before it finishes, it'll loop back to the starting point and repeat the process (this usually only happens with a 00 opcode).

I've been able to use this information manually edit a few in-game graphics so far, but that way lies madness. I think I have an idea of how to write the recompression routine:

*[Fill array with all uncompressed data]

*Read in byte
*Start from index 0 of uncompressed hexcodes array and work our way to the current read position
  --Find the longest matching sequence that starts with the current byte
     --If greater than/equal to 3, create opcode
     --Otherwise, add in byte as uncompressed
  --When we have enough for a section, create the appropriate separator byte and add to "Output" array
*Read in next byte, and repeat until finished.

Not 100% sure this works, but it seems like it would.
I'm not too concerned with the efficency of the algorithm itself (although I don't mind any feedback there) so much as generating the smallest compressed output to fit back in.
Any suggestions or advice would be much appreciated!

Hey! In the spirit of Spring Cleaning, I thought I'd try to complete one of the several half-finished projects I have, and I figured I'd make a post to keep myself accountable. :)

A Wonder Swan exclusive sequel to Mega Man & Bass that ties in the Game-boy games. The game play takes a little getting use to, but it's a decent game with some neat gimmicks.

At this point, all the system/game text is put in place, Mega Man's script is fully inserted, and Bass's is partially done. Hoping to have Bass's side done within the next couple days so the next round of playtesting can begin.

While I'm here, I figure I'd ask for opinons on how to lay out the title screen, specifically the wordy subtitle. Here's a rough mock-up of the wording:

Any better ideas? XD

Newcomer's Board / "Half" compressed GBC titlescreen?
« on: April 15, 2013, 07:33:23 pm »
Hello all,

Just trying to improve my understanding of compression. I've been toying around with a GBC game and have finally figured out where some of the graphics are. As an example, here's a picture of the tile of a box's upper right corner.

What's interesting to me is that the first 5 'lines' of the tile correspond to the graphic, but the last 3 are a jumbled mess. Furthermore, changing the colors anywhere in the first five lines makes the expected visual change in the game...

But editing anywhere in the last 3 lines screws up that tile and every other one that follows it...

It seems odd to me that only 'half' of a tile would be compressed if the purpose was to save space. I'm sure that's not actually the case, but if anyone could explain it better (or at least send me looking in the right direction) I'd be much obliged. Thanks!


I'm trying to translate an old Digimon WonderSwan game I saw in the abandoned section. Thanks to the previous hacker and the original WonderSwan's similarity to the GameBoy as far as text and tiles go, I've been able to make some good progress.

I've already fixed the functionality of the name entry screen, so when you click a letter it adds that instead of katakana to the player name. However, the appearance leaves something to be desired...

As you can see, the left-half of the 'a' is appearing next to the 'f'. Ideally I would like to remove this. My question is, is it likely this can be done with just a hex editor (IE: Figure out what the tiles hex addresses are, keep trying combinations like '30 31 01 32' until I find that area, and then change the '01' to remove the duplicated tile), or will actual assembly programming be necessary? I've been trying the hex way without luck, and I'd like to know if I'm going about it wrong or just need to keep struggling.

Any help would be appreciated. Thank you.

Pages: [1]