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

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]
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]