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.

Messages - Kafke

Pages: [1] 2
That's probably fine. They just don't want like.... nazi romhacks, porn, etc. Racism/sexism/homophobia/etc. are all probably off limits. But just some cursing is probably fine. At least, that's how I end up reading those kinds of rules. But I ain't a mod here so it might be best to ask? I imagine if it's already in some sort of base game, it's probably fine. And lots of games rated T or M definitely have cursing.

Personal Projects / Re: Princess Crown (Saturn) English Translation
« on: October 25, 2019, 02:22:25 am »
I'm very excited for this. Glad to see it's moving along. I thought it might've died after such long radio silence. I'm so eager to play it @.@

Keep up the good work :)

Personal Projects / Re: Princess Crown (Saturn) English Translation
« on: February 16, 2019, 07:50:26 pm »
It really depends on how much time we have available to work on it. I think it's safe to say there's a minimum of two months of work left. That's assuming both SamIAm and I were working on this full time which we aren't. Probably looking more like the latter half of 2019.

It's certainly up to you if you prefer to wait or not.

See the first post in this thread for a progress report.

"A delayed game is eventually good, but a rushed game is forever bad."

Most of my debugging and testing is done via Yabause. I do test on real hardware every so often using a real TV though not a CRT(I don't own one anymore). The original japanese font was 12x12 and just as thin. This is basically a variable-width(up to 12 pixels in height) font.

I'm hyped. That's more than fine. A ways off but I've got stuff to play until then so it's all good. Thanks for the ETA :)

Personal Projects / Re: Princess Crown (Saturn) English Translation
« on: January 20, 2019, 01:27:22 am »
Could we get an ETA? I'm trying to decide whether I should just start playing it in Japanese and use the online translation guides, or stick it out and wait for the translation patch. If it's gonna be months or years I'd rather just play it in Japanese with a guide tbh.

What all is left to be done? First release ain't gotta be perfect :)

Personal Projects / Re: Princess Crown (Saturn) English Translation
« on: January 20, 2019, 01:05:07 am »
Looks like you're getting a problem with the allegro library. Not sure what the fix is.

Personal Projects / Re: Princess Crown (Saturn) English Translation
« on: January 15, 2019, 11:43:00 pm »
Is there a build of this somewhere? The progress page ( seems to suggest it's at a playable state (all dialogue, battle text, and items/descriptions translated and inserted). I'd love to play it even in an unfinished state.

I'm expecting to get a grand total of 0 help, but I figure I should just go ahead and ask anyway. I'm pretty much completely tearing apart Nintendo Puzzle Collection for the gamecube (specifically the Panel de Pon portion), and so far so good. I can edit and manipulate most of the files as I please. However, there's lots of embedded content in a particular file with the extension "plf" (file in question is panepon.plf) which I found out was actually just an elf file but renamed (or perhaps with slight differences). I've managed to open it with a disassembler, which happened to have function names mapping to particular portions of code. Likewise with some digging I have found the entire list of files that were used as the source code, along with all of the function names. So here's my question: is there a quick and easy way of taking this debug info in the file (source code file names and function names) and then constructing a disassembly using those things? That is: sort ASM by function and file? I noticed there's some files embedded in there as well (some bin files which I know how to edit, some song files, etc.). Is there any way to easily extract all of these? Perhaps have some sort of tool to be able to quickly disassemble into the separate files/functions, and then a way to compile them back together?

I was thinking it'd be amazing to have a rough disassembly to use to be able to modify the game and get working to label what all of the code does (allowing for complete changes/modes/additions to the game). But I'm a bit out of my league rn, as I struggle to even navigate the file on my own w/o my disassembler.

Any help would be greatly appreciated! ❤️

Newcomer's Board / Re: Programming a level Editor for Gamecube Games.
« on: December 05, 2018, 12:12:59 pm »
I have that too. With that i can look witch data that is. I somehow have to Convert them with a tool to get them in the right data to edit the files for example Char files in .jpg so i can edit it or Stage files in a stage Editor.

You aren't going to find that for gamecube games. Unless you're hacking like.... luigi's mansion or super mario sunshine. Or perhaps melee. GC romhacking just isn't that popular, and as a result you gotta make your own tools.

Newcomer's Board / Re: Programming a level Editor for Gamecube Games.
« on: December 04, 2018, 12:30:19 pm »
What I do is use GCRebuilder to manage the iso and build my tools for the files inside.

ROM Hacking Discussion / Re: Screenshots
« on: December 02, 2018, 01:14:33 am »
Some screenshots from my Panel de Pon GB restoration hack. The game was officially released as pokemon puzzle challenge, but it turns out almost all of the panel de pon gb content is in the rom.

Alright well some progress has been made and I've done some digging.

Other emulators. Multiboot games as they tend to be called can approach the world a bit differently. I am slightly surprised VBA did not work with it as we tend to find problems come not from inaccuracies but being overly harsh (improper headers and whatnot) and VBA tended not to do be that, though I don't know what VBA-m might have done. Did no$gba work with it? If it does then time for some tracing ( , I know it is for the apparently non working VBA but the logic carries over to basically anything you want to debug on).

So it turns out that it is indeed a 'multiboot' rom, rather than a standalone gba rom. This is why vba didn't work out of the box. Once I renamed it to a .mb file, vba ran it fine. Likewise, that explains the issues with my flashcart. Once I threw it into a basic multi-rom loader, *that* gba rom ran fine on my supercard. It was just that it was a multiboot rom that was giving it issues.

So now I'm wondering how to go about wrapping it properly, without having a menu or w/e with only one game on it. The goal is to get it to be a standalone playable game in english. I'm not too interested in other convoluted hacks.

Wasn't there a version of Panel de Pon released for the GBA as part of Dr Mario and Panel de Pon (which was of course Dr Mario and Puzzle League outside of Japan)?  Perhaps it would be better to focus your efforts there first?

I was aware of the Dr Mario & Panel De Pon game for gba. And, in fact, wanted to do a restoration thing on it. Since the 'Panel De Pon' released is actually highly rebranded and has a few new options compared to the game I'm currently working on. What surprised me though, is I managed to extract a multiboot rom from it, which happens to be *identical* to the game I'm working on. It's just in english! All my translation efforts are done, fortunately. But I still need to edit the graphics to fix the title screen (it was changed to be puzzle league), and the logos throughout the game (all puzzle league).

Turns out that Dr Mario & Puzzle league has an option to send a multiboot rom over a link cable to another gba. That multiboot rom is the officially localized version, rather than just a direct copy of the puzzle league included on the cartridge.

On that end, I'm a bit lost on how to extract the puzzle league game itself (eliminating dr mario). Perhaps it'd just be a matter of patching the intro-sequence to skip the game select?

Hello :). Last time I posted here was about my Panel De Pon translation within Nintendo Puzzle Collection for gamecube. That's going pretty well (albeit slowly due to life problems), and I just managed to find the gba rom for the add-on game. So within Nintendo Puzzle Collection, there's a feature to have a gba game downloaded over the cord to your gba. I wanted to translate this (and perhaps extract it), so I went digging and found a file, ponagb2m_client.bin, which appears to just be a renamed gba rom. I took it and tried running it in a couple emulators. mGBA runs it perfectly, so that's what I've been using to debug. But interestingly vba doesn't run it. Any help with that mystery would be appreciated.

So the translation effort on this title has been going well. I've got a font table for it, and windhex32 displays the text perfectly. However, the pause menu is nowhere to be found. I'm guessing that it's likely an image being displayed.

Likewise, there's a few other images I need to edit: the title screen, a couple logos, the confirm and cancel buttons, etc.

Here's where I get stuck. I'm either an idiot when it comes to graphics hacking, or this game's graphics are harder to hack than I expected. Opening it up in Tile Molester and Tile Layer Pro seems to come up with nothing. Opening it with this tool ( seems to work, and I can see the images, albeit they're unaligned and wrongly colored (and no amount of tweaking appears to fix that). Likewise, the extraction/importing doesn't seem to work properly, and I still can't find the pause menu!

Could I get some help with this?

Edit: I tried the rom through my supercard lite, but it failed to load, which is unfortunate. Any ideas on how to get this game working on accurate emulators and real hardware (without the dependency of the gc transfer)?

Newcomer's Board / Re: Best Guides/Walkthroughs [Recommendations]
« on: December 27, 2015, 06:22:32 pm »
current gen stuff is a no-no jsyk

Why might that be? I realize the XBONE and PS4 aren't particularly RE'd/hacked yet, but the Wii U certainly is there, and the 3DS already has quite a large modding/fan translation scene. Is it just a rule on this forum, or is it just a 'no-no' because they're much more difficult than older consoles?

Newcomer's Board / Re: [Help] Text Editing Homeland for Gamecube.
« on: December 26, 2015, 07:02:00 pm »
I don't know if you're aware, but there's already progress done on translating the game. You can check out the progress (and contribute) over at

They seem to already have most of the script extracting. So take a look there.

Programming / Re: Algorithm for best optimizing string compression?
« on: December 18, 2015, 04:28:21 pm »
Yea, I know humans have had a lot time to evolve to get this right.

Thanks for all the info. And to expand a bit more, the images DO have a compressed flag. As well as an option to ignore a certain amount of bytes. As the code implies, one byte can be looped many times (up to 50 or so), while multiple bytes (2-9) can only be looped up to 8 times each. I don't see the point in starting with the higher amount, as the lower amounts can often times lead to further compression, even if it is possible to compress the higher ones (see: AB AB AB AB -> 2AB2AB vs 4AB).

"Start as big as your repeating value will allow and count backwards from there until you hit the point where it is not worth it as the compressed data is as long as the uncompressed*. "

Yea, I was definitely going to add a comparison to the uncompressed version. But why high-to-low instead of low-to-high? Due to the nature of the data, most of it is either going to be a single byte looped many times, or 2/4 bytes looped several times. Or do you mean just for run-time's sake? The run-time is fine and largely a non-issue at this point.

"RLE is considered the precursor to the LZ aka sliding window family of compression algorithms so you can adopt something nicer from there as your scanning method if you like, assuming you are not going to run into an unaligned read penalty."

I'm not entirely sure what you mean by 'unaligned read penalty', but I'll definitely check out how LZ does things.

"normally you would not have to compress things in a game but if you have custom names to save..) "

Yea, it's a bit weird. The image format is a proprietary container that can hold a few different types of img/rbg/color data. And there's a byte to say whether it's compressed using the manner I described. After decompressing, the image can be loaded using one of the known formats. Leaving it decompressed pushes the file size to be much larger, and thus potentially cause errors (either due to not fitting on the ISO, or perhaps some other issue I'm not aware of). If it wasn't already compressed to begin with, I wouldn't even bother compressing it.

"*in standard ASCII you will stop at 7F so you have an entire upper bit to play with, even more if you consider that you will probably not see many characters below 20 hex for most things)."

7F is the cap for ignoring bytes/leaving the marked amount uncompressed. Then 80-B0 for single byte repetition, and B0-FF for multi-byte repetition.

It's worth noting, again, this isn't really for text, but for images. But I figured the theory should be the same, since it's all just bytes.

Programming / Algorithm for best optimizing string compression?
« on: December 18, 2015, 07:45:26 am »
I have what I think is a simple question, I'm just not too good on the math-y side of programming in order to figure this one out. I have a string compression function that reduces repeating strings down into a compressed form. Something like: "ABABAB" -> 3AB. The decompression is really simple and results in a perfectly expanded product. However, I'm having a bit of a difficult time getting the compression to... well... compress.

My first attempt was a naive approach of just starting with single repeating characters, then 2, then 3, then 4, etc. until the max amount of characters allowed. However, this still tends to result in unoptimized outcomes (given the capped nature of the compression). An example would be:


My current code would see AB AB AB AB and list it as 4AB, then it'd see a C with nothing good after so it'd do 1C, and then it'd see the 1ABC. Resulting in a compressed string of 4AB1C1ABC. However, it's fairly obvious to us humans that the correct compression would be 3AB2ABC.

I was wondering if there was a better way of scanning the input to get a better compression.

Simply decompressing an existing string and recompressing it boosts me from 2KB to 6KB in one example.

And I kinda lied, it's not really strings, but bytes for a particular part of my translation hack. But the principle is the same.

Here's a quick pastebin paste of my current rough code:

Basically I check the single byte compression, since it works a bit differently than the rest. From there I check the varying amount of bytes that will be repeated, and keep counts for each, and simply grab the one that works the best at the end and use that. But as I mentioned, it's a naive approach and commonly leaves bad compression in parts.

Thoughts? Has anyone else had to deal with something like this?

It's not too important, since the game is flexible on file sizes. But I have a feeling there's a hard limit on the total amount of stuff in general, so it's best to keep everything small. There's some other optimizations I can do as well, which I haven't tried yet. But that's unrelated to the question I'm posing here.

Thanks  :)

Newcomer's Board / Re: Is anyone here good with zole,zose,zote, or yy chr?
« on: December 16, 2015, 11:37:45 pm »
Well that's what the programs he listed are for.  There was a user here a while back that made an editor for the Oracle games titled 'ZOLE'.

Ralph himself is already in the game, so I'd imagine a simple swap between him and link, along with drawing a few new sprites probably wouldn't be hard. Technically speaking, it's all pretty easy (given the editor is already made). I mean, there's not THAT many And Ralph already has walking/attacking sprites done.

Definitely a lot of work for the end product, but it looks completely doable.

Newcomer's Board / Re: Is anyone here good with zole,zose,zote, or yy chr?
« on: December 16, 2015, 10:16:02 pm »
I am wondering what zole, zose and zote mean... But I am good with yy-chr, so where is your question? Is this a spam topic? :D

Presumably he's doing an Zelda:OoA overhaul and replacing Link with Ralph. At least, judging by his post history. Sounds like a cool project. I was actually thinking of doing something similar, but I've got enough on my plate.


First link. I find more often than not a 'good' programmer typically can find their way around google and stack overflow for trivial syntax questions.

Non trivial, in most cases it would be.
Impossible, not even close, especially if you only want a roughly human readable script at the end of it.

You would have to understand some of the fan translation's hacking work but where they might have spent a weekend figuring out the font handling before altering it this can skip over all that and just make use of the results, or ignore it entirely. I wouldn't give it to a non hacker to do but anybody that understands text hacking can probably pull this off.

Certainly re-hacking to extract the translated text wouldn't be problematic. I was more of speaking about a 'tool' that does this automatically for you (given a translation patch and the original game). There's no automatic/systematic way to do this. You pretty much have to repeat the hacking effort in order to extract the text.

In Panel De Pon's case, this means: Extract the .BIN file using a custom written tool and then pull the text (which is not UTF-8 or any standard encoding) from each. And given that there's no systematic way to pull text, you'd either have to do it by hand, or write the tool to decode everything in the script file. It'd be near impossible to have a tool automatically do this for you, unless it was written specifically for panel de pon. At which point you don't really need the patch itself either, provided you patched the game beforehand.

The automatic text extracting tool seems near impossible. But extracting the translated text should be fine if you do it by hand. But at that point it'd just be faster/easier to simply ask the team that translated it.

Pages: [1] 2