Register | Login | |||||
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
| |
0 users currently in ROM Hacking. |
Acmlm's Board - I3 Archive - ROM Hacking - RLE compression for SMK | New poll | | |
Pages: 1 2 3 | Add to favorites | Next newer thread | Next older thread |
User | Post | ||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Originally posted by Alice Personally, I'd say 16+(n+1), but that's just me. Originally posted by Alice It works, awesome ! Thanks. (edited by Stifu on 02-01-07 03:56 AM) |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
I found out TrackDes does things the way I thought: in a quite dirty way.
First, when you modify a track, it actually leaves the original track data as is, and copies your new track at the bottom of the ROM (once expanded), and changes the concerned track pointer accordingly. Bouche made it this way to avoid compressed size problems... The thing is, if you open a track and save it 10 times, it'll make 10 copies of it at the bottom of the ROM. It doesn't overwrite anything, but keeps adding things over and over again, until it reaches the ROM size limit. Some people reported that at some point, they couldn't change tracks anymore, TrackDes telling them their ROM is readonly or something... I'm pretty sure they quite simply reached the ROM size limit. I'll try to do things in a much cleaner way, I have a few ideas... |
|||
GlitchCog Goomba Since: 01-31-06 Last post: 6287 days Last view: 6287 days |
| ||
That is pretty sloppy.
You could definately design tracks that would end up smaller than the originals. Especially the complex ones. If you turned a Donut Plains sized track into a Ghost Valley-like track where the off road area was all the same tile, it could be a lot smaller than all the bushes and lake tiles mixed together. And then there's a bunch of compression scemes that are only used a few times. If you designed your tracks specifically with the available compression in mind, you could probably come up with a really complicated track that doesn't take up space. Did you figure out the 8n compression fully? The X part works for me. Like how when it's more than a full row's worth of tiles, it just skips to the next row, and I wind up in the right column, but I'm lost as to how the Y component works. |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Yeah, I thought about making sure the newly compressed tracks fit right into the ROM, by messing with pointers, moving big tracks where there is a lot of space, and small ones in small spaces... You get the idea. Or even redefining the space attributed to each track, when possible (basically, when tracks are packed together), changing pointers accordingly... That'd probably be the cleanest way, although the most bothersome one. And I think it'd be difficult to implement in an automated editor, too...
My other idea was to expand the ROM like Bouche did (not to 2 MB though, 1 MB is enough), copying the new track data at the bottom of the ROM, but defining clear areas for each of the 24 tracks... so that each track has its own space, so no garbage would add up each time you edit one, unlike in TrackDes. And yeah, we figured out the 8n compression fully. The 2 parameters following the 8n command actually form an absolute hex address. Example: 80 50 01 means "copy 81 bytes starting from location 0150 of the decompressed track". We're almost finished figuring out all the compression commands, I'll post our updated notes (reformulated and clearer) once we're done... Command 0xAn is basically the last command giving us problems... It's another block copy command, but it's quite weird (and rarely used)... (edited by Stifu on 02-03-07 06:19 PM) |
|||
midwife Newcomer Since: 02-04-07 From: Dijon / FRANCE Last post: 6285 days Last view: 6276 days |
| ||
Hi ! I'm Stifu's friend, helping him on SMK track codec ! let's go ! (edited by midwife on 02-04-07 06:38 AM) |
|||
Dirtbag Koopa Since: 09-20-06 From: UK Last post: 6279 days Last view: 6275 days |
| ||
Originally posted by midwife Welcome Midwife! Looks like the SMK scene is starting to pick up Stifu: Well done on finding the offsets for the demo macros. When I get some spare time I'm going to relase an update to my Mushroom Cup demo of Super Baldy Kart with the demo edited. |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Originally posted by Dirtbag Yeah, huge thanks to Midwife who helped me getting started with track decompression and all... He's a much better coder than me, too. I've known him for years now, and he always makes the music for all of my game projects... Hopefully Epic Racers will be no exception. Originally posted by Dirtbag There's something I haven't figured out yet... See, replacing all the demo data with "00" of the first demo out of four (the Mario and Yoshi one) will leave drivers completely still, as you would expect... However, it's not the case of the other three demos. In the other demos, if you remove the data, drivers don't go forward anymore, but they still hop and turn their head from time to time, so there must be some data I haven't found yet... Let me know what you manage to do. This shouldn't require pure hex hacking, it should be possible to copy data from a ZMV file, but I don't know the details... |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6276 days Last view: 6276 days |
| ||
My Pokémon G/S editor handles saving maps in a simple but effective way: Zero out the map data in ROM, find a block of zeros large enough to hold the map, and save it there. This way if your new map is the same size or smaller than the old one, it gets put in the same place. Basically what TrackDes does except wiping out the old data first. (Those maps aren't compressed though.)
Bouche once mentioned the idea of figuring out the maximum possible size a compressed map could be (assuming it's compressed with the editor, not something dumb like repeating "1 byte uncompressed" commands over and over), and allocating each map that much space at the end of the ROM (basically assuming they will reach that size). This would allow you to save them in the same place each time, always using a specific amount of space. |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Originally posted by HyperHacker That's what I thought of, basically... Except in the way I formulated the idea above, I thought I could allow more space than ever needed if I expand the ROM to 1 MB, so I wouldn't have to bother figuring out exactly what's the possible max size. However, I may want to put other data at the bottom of each track, like their graphics... And maybe object and AI data, if it's also compressed. I had another idea: somehow managing to pack all the track data together in the ROM, moving stuff around... All tracks being part of the same big pack would make space management easier... The difficulty to do this for me would be to change all the concerned pointers... Also, it may be confusing to users, as some things wouldn't be at the same place anymore (although I could explain what has been moved in a txt file)... Thanks for having answered my PM, by the way... Command 5 (0xAn) is definitely a "copy command" though, so it's not what you suggested it might be... I'll spend more time on all that later. |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6276 days Last view: 6276 days |
| ||
Are you finding this by tracing the code? I could take a peek at it if I can get Geiger's debugger to work. | |||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Originally posted by HyperHacker Nah, I don't know anything about that... I simply check how TrackDes behaves. What we use to figure out stuff: -The track decompressed with Lunar Compress, but still RLE (and stuff) compressed. or the track recompressed with TrackDes (reinserting it into the ROM and decompressing it with Lunar Compress) -The track totally decompressed (.mkt files generated by TrackDes) -The track decompressed with our own decompressor, to compare... (edited by Stifu on 02-10-07 04:49 AM) |
|||
GlitchCog Goomba Since: 01-31-06 Last post: 6287 days Last view: 6287 days |
| ||
Ah, I was wondering where the An compression was used since I couldn't find it in any of the existing tracks.
Is there any difference in the 8n compression on Ghost Valley tracks? I seem to need to subtract 1 from the 8n absolute hex address to get it to come out right, but it's only for Ghost Valley tracks. http://matt.yanos.com/smktrk/?file=tracks/tr_map_gv1.bin&tiles=tiles/gv/&temp=-1 (Works perfectly) vs. http://matt.yanos.com/smktrk/?file=tracks/tr_map_gv1.bin&tiles=tiles/gv/&temp=0 (Blocks using 8n messed up) It's probably a glitch in my code, but I just want to make sure you didn't find anything different about the Ghost Valleys too. Thanks. |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Nope, no exception for Ghost Valley, or any other track...
In case that helps, here's our C code for 8n, I added a few quick comments to make it clearer... unsigned int i = 0, j = 0, count, command; // "count" = "n" in our notes Let me know if that helps... (edited by Stifu on 02-06-07 09:27 AM) |
|||
GlitchCog Goomba Since: 01-31-06 Last post: 6287 days Last view: 6287 days |
| ||
Thanks for your help. I figured out what was wrong. Ghost Valley 1 & 3 start with E5 compression. I was just treating it like an E4, so I was coming up two rows short and didn't notice since they were just two full rows of "00" missing from the tops of the tracks. And that's why I had to subtract 1 from the row value of the hex for them.
I guess E5 is just an additional 256 blocks. That's what I've got it set up to do for now, anyhow. It looks like my 8n code does the same thing as yours, except that mine's all jumbled together and difficult to follow because I'm a terrible, terrible programmer. case "8":
|
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Originally posted by GlitchCog Exactly. I'll just post our updated notes although they aren't complete yet...
(edited by Stifu on 02-10-07 04:48 AM) |
|||
GlitchCog Goomba Since: 01-31-06 Last post: 6287 days Last view: 6287 days |
| ||
Awesome. I was just looking through the tracks that are already there to figure it out, so I wouldn't have gotten some that weren't used until I could step back and look at the overall patterns. Thanks. | |||
midwife Newcomer Since: 02-04-07 From: Dijon / FRANCE Last post: 6285 days Last view: 6276 days |
| ||
quite ( a lot ) of time to test each command ... Stifu made a great Job ! gratz ! | |||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Alright, I made a bit of progress...
0xAn: 3 bytes, 0xAn P1 P2. Lays n(+1) bytes. Those bytes are calculated this way: (FF - byte found at P2P1 of the decompressed track) I hope the explanation is clear enough. You just have to substract from FF what's already been decompressed at an earlier location. If the bytes from the decompressed track are like 00 00 07 22 33, then the 0xAn command will produce FF FF F8 DD CC... How would you call that command, HH ? Anyway... 0xF4: 4 bytes, 0xF4 P1 P2 P3. Works like 0xAn, with P1 replacing n. 0xF5: 4 bytes, same as 0xF4, but with P1+256 0xF6: 4 bytes, same as 0xF4, but with P1+512 0xF7: 4 bytes, same as 0xF4, but with P1+768 The only commands we still need to figure out are FC, FD and FE... Edit: Decompression 100% complete ! 0xFC: 3 bytes, FC NN P1. Lays NN(+1) bytes. Byte calculation: FF - byte at (CurrentLocation - P1) of decompressed track 0xFD: 3 bytes, same as 0xFC, but with NN+256 0xFE: 3 bytes, same as 0xFC, but with NN+512 (edited by Stifu on 02-10-07 05:07 PM) (edited by Stifu on 02-10-07 06:30 PM) |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6276 days Last view: 6276 days |
| ||
I'd call it something like LZ77, Inverse Bits. Subtracting the value from 0xFF should invert its bits.
BTW, my PM should have explained what FC-FE did. |
|||
Stifu Since: 11-18-05 From: Your mom's bed Last post: 6277 days Last view: 6275 days |
| ||
Hmmm ? You mean the "Reverse-Bit Copy" thing, or something else ? I didn't quite understand that, even re-reading your PM, I can't see something along the lines of what FC-FE do... but I admit some parts kinda confused me.
Whatever, you've still been helpful. Now to work on the graphic interface of the editor... (edited by Stifu on 02-11-07 03:47 AM) |
Pages: 1 2 3 | Add to favorites | Next newer thread | Next older thread |
Acmlm's Board - I3 Archive - ROM Hacking - RLE compression for SMK | | |