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.
I think it's safe to say you're not going to find Magecraft or whatever the one member's name was.So, would it be okay for me to release a patch with the custom icons that includes his translation? I'm seeing this as sort of a grey area, I wouldn't want to be seen as taking credit for other's work. If I can't I'll just reinsert the icons into the unpatched Japanese version and release it like that. And to be honest, I can't see myself doing a full translation anytime soon. I figure that if I can translate at least the main menu, I can be satisfied for a while.
The wonderful people at the Whirlpool flamed the hell out of him a decade ago for "stealing" a more experienced member's project (flaming wouldn't be tolerated here).
More relevant to this topic, it would not surprise me if this was stored with event data between the text. Definitely not beginner friendly, and I imagine it's a good reason why nobody's finished translations of the SNES games.
I tried myself to do RPG Maker 1 for SNES. Take a look in the editor at the things an NPC can do: walk in each direction, turn in each direction, yes/no prompts, etc. Each of those has a hex value. And even for the "text" opcode, there's probably more control bytes for text length, windows, etc. Even if you made a custom text dumper/inserter that could expand and relocate the event data, I'd guess that due to the editable nature, you'd still be restricted in how much you could expand the text before crashing by making the data take up too much SRAM.
(I'd thought about doing DTE for RPGM SNES, but then I realized that'd make editing the text input windows a real problem)
The table is a file that tells your hex editor, script dumper and script inserter which hex values correspond to which characters. Sometimes you get lucky and the text data is stored in a recognized format, like ASCII or Shift-JIS, but for most older titles, it's purely ad hoc and requires some sleuthing to figure out.
The general form of a table looks like this:Code: [Select]
That is, your tools will recognize that these hex values are used to represent the corresponding characters in the game's text data. This is just a sample, mind: the exact values will differ from game to game.
A good first step is to find the game's font. Assuming it's not compressed, it should be arranged in the same order as the game's table - this simplifies the math involved in converting character values to ROM addresses. Once you've figured that out, you can use relative searching to find patterns matching the game's text (again, provided the script isn't compressed) and thus work out the beginnings of your table.
Need an English "RPG Maker GB" logo? Or any English-language graphics at all, really. I'm good at that kinda thing.
The obvious way, of course, would be to simply hex search the ROM for that sequence of palette bytes - it might be 7F FF 00 00 00 00 00 00, or it might be FF 7F 00 00 00 00 00 00 if the palette values are stored in little-endian format (probably this, but it pays to try both ways). Otherwise, you'll have to catch the game in the act of updating the palette. Is BG0 ever not White-Black-Black-Black?
GBC-exclusive, or GBC-compatible? There's a difference. Run the game in GB-only mode and see if the game runs, or if you get an error message.
As a first step, try running the game in B/W Game Boy mode (most GB emulators should have a toggle for this somewhere in their settings). If the icon still appears solid black, then the problem has something to do with how the game copies the tiles to VRAM for that particular print routine - it might be copying the same byte twice instead of properly copying both bytes of the tile. This'll take some ASM hacking to fix, but it shouldn't be difficult.