(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		06-10-24 04:42 PM
Acmlm's Board - I3 Archive - - Posts by GlitchCog
Pages: 1 2
User Post
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 01-19-07 09:26 PM, in Super Mario Kart offset notes Link
Thanks, Stifu.

So what does it mean for Epic Racers that you decided to release this data early? Is it just taking a lot longer than you were thinking, or are you going to be doing a lot more with sound than you planned or something?
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 01-30-07 03:35 PM, in RLE compression for SMK Link
The purpose of the 6n in SMK's RLE compression format is to count up through the tiles. For example, "6423" would lay down tiles: 23 24 25 26 27

There's probably one for going down the tile order too.
Edit: On second thought, there probably isn't a count down order flag, because switching the order of the tiles wouldn't make a downward sloped curve curve upwards, it'd just turn it into a jagged mess.

Also, E4 seems to repeat n tiles where n is the next value. Then the tile is stored in the value after that. For example, E40A16 would lay down: 16 16 16 16 16 16 16 16 16 16

(edited by GlitchCog on 01-30-07 10:25 AM)
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 01-31-07 08:06 AM, in RLE compression for SMK Link
Oops, yeah, I forgot to count the zero in that.

I started working on an online SMK map viewer, mostly just to help me understand how the RLE compression works, although eventually I'd like for it to be genuinely useful, and maybe turn it into an editor if I can. Here's what I've got so far:

http://matt.yanos.com/smktrk (Give it a second to load)

That's based only on 0n, 2n, 3n, 6n, and E4. I haven't figured out Cn yet, but I've only looked at one instance of it which appeared very confusing.
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 01-31-07 02:06 PM, in RLE compression for SMK Link
It's 19. It's the same zero that I missed. It's misleading to use 32 as an example, because you might think the three flag has something to do with the number of tiles it lays down, but the "2" plus the 16 is what gives 19 because the 2's zero is counted.

2 => 0, 1, 2 = 3
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 01-31-07 10:14 PM, in RLE compression for SMK Link
Awesome. Thanks, Stifu. I was stuck trying to relate the 8n and Cn bits to the map of available tiles, obviously without much success.
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 02-03-07 11:44 PM, in RLE compression for SMK Link
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.
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 02-06-07 02:41 PM, in RLE compression for SMK Link
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.
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 02-06-07 06:50 PM, in RLE compression for SMK Link
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":
for ( $b=1; $b<=hexdec(substr($compressed_map,$n+1,1))+1; $b++) {

$decompressed_track = $decompressed_track . substr($decompressed_track,(2*hexdec(dechex(hexdec(substr($compressed_track,$n+4,2))+$temp) . substr($track_map,$n+2,2)))+(($b-1)*2),2);

}
$n = $n + 6;
break;
GlitchCog

Goomba


 





Since: 01-31-06

Last post: 6333 days
Last view: 6333 days
Posted on 02-06-07 10:44 PM, in RLE compression for SMK Link
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.
Pages: 1 2
Acmlm's Board - I3 Archive - - Posts by GlitchCog


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.032 seconds; used 376.78 kB (max 457.41 kB)