Author
|
Topic: ROM Tile Layer Font Format Problem (Read 2 times)
|
vx
Guest
|
|
« on: February 18, 2009, 08:38:10 am » |
|
I can't seem to properly view the fonts for Super Ultra Baseball 2. I have tried various codecs in TLP and Tile Molestor and the only one that partially works is 1BPP. VSNES seems to display the font table fine, maybe there is info I could get from there? VSNES http://www.8thmandvd.com/snes/tlp.JPGTLP using 1BPP TLP SNES Staff edit - turned the first picture into a link. too large for inline display. broke the board formatting.
|
|
« Last Edit: February 19, 2009, 06:33:31 pm by Neil »
|
|
|
|
Tauwasser
Guest
|
|
« Reply #1 on: February 18, 2009, 09:14:02 am » |
|
It's a pseudo compression. It seems to be able to handle 0x80 bytes uncompressed at once at most. Go to the end of the 7 and look at the bytes there. Another control code is at the beginning of 回. Basically, it will be a code that tells it to take the next n bytes uncompressed. In front of the medium sized R (preceding 1 2 3 4...), you'll notice that two bytes before it, there will be a code telling it to read 0x80 bytes (that's till the end of 7, though not the whole tile). You can either skim the data by hand off these codes, or just accomodate for them with CTRL + → (right) or CTRL + ↠(left).
cYa,
Tauwasser
|
|
|
|
KingMike
Guest
|
|
« Reply #2 on: February 18, 2009, 09:29:36 am » |
|
(looking at the font screenshot) CHANEY What'd he do to get his name in the game? Take them hunting?
|
|
|
|
vx
Guest
|
|
« Reply #3 on: February 18, 2009, 09:47:44 am » |
|
It's a pseudo compression. It seems to be able to handle 0x80 bytes uncompressed at once at most. Go to the end of the 7 and look at the bytes there. Another control code is at the beginning of 回. Basically, it will be a code that tells it to take the next n bytes uncompressed. In front of the medium sized R (preceding 1 2 3 4...), you'll notice that two bytes before it, there will be a code telling it to read 0x80 bytes (that's till the end of 7, though not the whole tile). You can either skim the data by hand off these codes, or just accomodate for them with CTRL + → (right) or CTRL + ↠(left).
cYa,
Tauwasser
Thanks Tauwasser, for the explanation, the CTRL+right/left helps adjust it so it's not off center. Now my concern is importing, since I am viewing at 1BPP is that the format I need to use? I guess there's no way to view them uncompressed like VSNES shows? (looking at the font screenshot) CHANEY What'd he do to get his name in the game? Take them hunting? Ha I just saw that now that you pointed that out :laugh:
|
|
|
|
Tauwasser
Guest
|
|
« Reply #4 on: February 18, 2009, 10:50:28 am » |
|
Well yes. The game saves space since it makes a conversion from 1bpp to 2bpp. It's really easy. If you already have 1bpp tiles. And they only use color 0 and color 3, then just delete every second byte from the data and you have 1bpp. If they have other colors, you first or the two, then delete every second byte. Still, it's probably not that hard getting it to 1bpp to copy over. Also, you could research this storage scheme further and maybe set it up so it takes the whole set in one step, so you'll have all of it aligned at the same time. At least you could manage to have it have the maximum width of 8 tiles always aligned, so you just change 1 byte to the right to see the next row. However, the only concern would be that they did this for a purpose, for example to be able to use they decode for parts of those tiles, and hence why the widths are different.
cYa,
Tauwasser
|
|
|
|
creaothceann
Guest
|
|
« Reply #5 on: February 18, 2009, 11:15:43 am » |
|
VSNES seems to display the font table fine, maybe there is info I could get from there?
You're viewing VRAM data, which is always uncompressed. vSNES doesn't handle any compressed formats. If they have other colors, you first OR the two, then delete every second byte. No shifting required?
|
|
|
|
Tauwasser
Guest
|
|
« Reply #6 on: February 18, 2009, 11:47:45 am » |
|
No, no shifting required. Basically, you're losing a color that way. If you use color 1 and color2 and not just ohne of them, then you'll get a result that will be all colored tho. I was assuming color0 and a color besides 3. If you have color1 and color2 in use, then just keep on using one of them and drop the other. Sorry that I wasn't specific. Also, this will only handle your problem with the 2bpp -> 1bpp conversion. You'll still have to shift you original data to be then able to overwrite it properly. You should check out a hex editor, and decipher the codes used for the data, then you'll know. OK, maybe you'll get the shifting thing with this; it's basically an analysis of your picture: 76543210 00100000 --- Code 0x20 => 0x40 = 64 Bytes 00000000 --- Code 0x00 00000000 \\ 00000000 | 00000000 | 00■■■000 | 00■00■00 | R 00■■■000 | 00■00■00 | 00■00■00 / 00000000 \\ 00000000 | 00000000 | 0000■000 | 000■■000 | 1 0000■000 | 0000■000 | 0000■000 / 00000000 \\ 00000000 | 00000000 | 000■■000 | 00■00■00 | 2 0000■000 | 000■0000 | 00■■■■00 / 00000000 \\ 00000000 | 00000000 | 000■■000 | 00■00■00 | 3 0000■000 | 00■00■00 | 000■■000 / 00000000 \\ 00000000 | 00000000 | 0000■000 | 000■■000 | 4 00■0■000 | 00■■■■00 | 0000■000 / 00000000 \\ 00000000 | 00000000 | 000■■■00 | 000■0000 | 5 000■■000 | 00000■00 | 000■■■00 / 00000000 \\ 00000000 | 00000000 | 000■■000 | 00■00000 | 6 00■■■000 | 00■00■00 | 000■■000 / 00000000 \\ 00000000 | 00000000 | 00■■■000 | 0000■000 | 7 000■0000 | 000■0000 | 000■0000 / 00100110 --- Code 0x26 => 0x18 = 24 Bytes 00000000 --- Code 0x00 00000000 \\ 00000000 | 00000000 | 000■■000 | 00■00■00 | 8 000■■000 | 00■00■00 | 000■■000 / 00000000 \\ 00000000 | 00000000 | 000■■000 | 00■00■00 | 9 000■■■00 | 00000■00 | 000■■000 / 00000000 \\ 00000000 | 00000000 | 00■00■00 | 0■■0■0■0 | 10 00■0■0■0 | 00■0■0■0 | 00■00■00 / 01000000 --- Code 0x40 00000000 \\ 0■■■■■■■| 0■00000■| 0■0■■■0■| 0■0■0■0■| 回 0■0■■■0■| 0■00000■| 0■■■■■■■/ 00000000 \\ 0■■00■■0 | 0■■00■■0 | 0■■00■■0 | 0■■■■■■0 | 0■■■■■■0 | W 0■■■■■■0 | 0■■00■■0 / 00000000 \\ 0■■00■■0 | 0■■00■■0 | 00■■■■00 | 000■■000 | X 00■■■■00 | 0■■00■■0 | 0■■00■■0 / 00000000 \\ 0■■00■■0 | 0■■00■■0 | 0■■00■■0 | 00■■■■00 | 000■■000 | Y 000■■000 | 000■■000 / 00000000 \\ 0■■■■■■0 | 00000■■0 | 0000■■00 | 000■■000 | 00■■0000 | Z 0■■00000 | ■■■■■■■0 / 00000000 \\ 000■0000 | 0■■■■■■■| 000■0■00 | 00■■■■■0 | 0■0■0■0■| ゠0■00■00■| 00■■00■0 / 00000000 \\ 0■0000■0 | 0■00000■| 0■00000■| 0■00000■| 0■00000■| ㄠ0■00■00■| 00■■0000 / 00000000 \\ 00■■■■00 | 00000000 | 00■■■■00 | 0■0000■0 | 000000■0 | ㆠ00000■00 | 000■■000 / 01000000 --- Code 0x40 This makes it seem as if 0x2X codes do something special - I'd venture to say they change the palette- , while 0x40 is just plain "copy next 0x40 Bytes" though with 1bpp -> 2bpp conversion. cYa, Tauwasser
|
|
« Last Edit: February 18, 2009, 12:50:31 pm by Tauwasser »
|
|
|
|
vx
Guest
|
|
« Reply #7 on: February 19, 2009, 04:33:45 am » |
|
I am not sure why they mixed up the widths, prob for size? I will venture into it w/ a hex editor and see if I can figure that out shouldn't be too hard...thanks again for the detailed info Tauwasser. You're viewing VRAM data, which is always uncompressed. vSNES doesn't handle any compressed formats.
Ah Ok that makes sense. I guess there's no possible way to implement a tile editor into VSNES that would edit compressed tiles in their uncompressed formats? Even so I know it's a lot of work so not really pushing you to update it. Thanks again VSNES has become quite useful for me.
|
|
|
|
Karatorian
Guest
|
|
« Reply #8 on: February 19, 2009, 05:33:53 am » |
|
I guess there's no possible way to implement a tile editor into VSNES that would edit compressed tiles in their uncompressed formats? While I wouldn't say it's not possible (almost anythings possible with enough effort), it's most definitely not the way to go about it and I'm sure VSNES's author whould agree. The proper way to handle this is to decipher the compression (looks pretty simple and apparently already figured out from what I read of the above posts) and implement a set of conversion routines (compress and decompress). Far more appropriate palces to do such a conversion are in a standalone utility, an image editor, or a compression library. Should be pretty basic bit bashing, so if you've got any programming experiance at all you should be able to handle it. If not, you might as well learn. (Once you get into ROM hacking, it's almost inevitable anyway.)
|
|
|
|
Tauwasser
Guest
|
|
« Reply #9 on: February 19, 2009, 05:57:46 am » |
|
Well, you can insert the data alright into there. Basically, you will have to have all the tiles in 1bpp format in one binary file of your choice. Then, open up your rom in tlp. Then you have to align it properly as to not overwrite the codes and just copy and paste the redrawn tiles over it. The tough thing is really, that you'll have to skip two or one byte every so often because of the palette conversion thingy. Shouldn't be too tough lacking programming etc. It's not really worth writing a program for it I guess, except you'll encounter this a lot, which is unlikely.
Basically, for all tiles that have the color conversion, move twice CTRL + Right when things become screwy, for "regular" ones, that is 2 colors only in 2bpp mode, just move CTRL + Right once.
cYa,
Tauwasser
|
|
|
|
Karatorian
Guest
|
|
« Reply #10 on: February 19, 2009, 06:46:44 pm » |
|
I suppose if one had no programming skills that'd work. Sounds like a pain though. (On the other tentacle, I've been know to write scripts that I uses exactly once, if I feel it's easier than doing something by hand.)
|
|
|
|
vx
Guest
|
|
« Reply #11 on: February 20, 2009, 03:19:11 am » |
|
I'm not a programmer, the most I can do is compile source code and that doesn't count :happy:
I think I have enough info to figure this out, I'll have a crack at it later.
Thanks guys.
|
|
|
|
|