Jul -- The Cutting Room Floor: Killer Instinct 1 & 2 Arcade Image Compression/Encryption

kirishima
User
Level: 8

Posts: 11/11
EXP: 1996
For next: 191

Since: 02-11-14

Since last post: 7.2 years
Last activity: 7.2 years

Posted on 02-19-15 08:08:50 PM (last edited by kirishima at 02-19-15 08:13:07 PM)

Link | Quote

Originally posted by Abystus
I've seen Killer Instinct arcade sprites (used set) for all characters used in M.U.G.E.N character builds, so I'm sure someone has a collection of them online somewhere.

http://infinitymugenteam.com/FrameSprites_KillerInstinct.htm

http://infinitymugenteam.com/FrameSprites_KI2.htm

Also, some on spriters resources. The rips aren't that good, though.

theassassin
Member
Level: 13

Posts: 11/28
EXP: 8133
For next: 2134

Since: 01-22-14

Since last post: 6.2 years
Last activity: 6.1 years

Posted on 02-20-15 01:44:21 PM

Link | Quote

Thanks kirishima I hadn't come accross those infinity sets before, and thanks Abystus for the music tools, might have a play around with that sometime

Would be awesome if someone could crack the KI arcade image compression properly, I'd particularly love to see what unused KI1 sprites might be in there.

TTRlovesMittens
Random nobody
Level: 4

Posts: 1/3
EXP: 257
For next: 22

Since: 08-04-15

Since last post: 6.7 years
Last activity: 6.6 years

Posted on 08-05-15 11:54:02 AM

Link | Quote

VERY VERY LONG DETAILED POST. tl;dr I figured out how sprites are stored in the memory, and probably how they're storied in the CHD, just gotta search the CHD

Hey guys! First post here with something that could get actual sprite dumping, and with some more elbow grease, full ripping done! However, it's a very long and fairly detailed post. I am also posting on my iPhone because my internet situation is shaky right now, so the formatting is going to be lackluster. For example, I can't do embedded images that easily right now. For now, I've uploaded all my example images to imgur, and they're organized and titled in a way that should be simple to follow along with this post.

Images: http://imgur.com/a/VZAfw

The first image is what I like to call the "table of workspaces." This table, located around 887f8320 is the index of spaces in the memory that the game directly stores sprites on a per-set basis. For example, Jago's pointer in this table leads close by to 887f8360, while Fulgore is stored at 887f8B60. All characters will occupy the same space regardless which palette or player side they occupy. So, if two Jagos are playing, the game will load "Jago" once and apply his palettes to the same set. This is standard. So, basically you get the pointers at the 320 table depending on which character, then you get a second table with a list of addresses in 4 byte chunks that lead elsewhere in the memory. Each one of these is a "workspace" where the game will dump sprite data. These tables are always in the same place regardless of the stage, characters chosen, etc. How this table works is next.

The second image is set up with two callings of Jago. In the red boxes are bytes that I like to think of as the "Action" number. Each action number calls a new set of sprites. The first box pointing the Player 1 is the Player 1 Action, and Player Two is below. In this screenshot I froze the debugger to change this value. I changed P1 to Action 3F and P2 to action 02. The results of this change can be seen in the post picture, where I let Mame run to the next vblank. The sprites have now changed to a new set! If you let this go on, the game will play the ANIMATION of the move that was going on before, in this case neutral, but use the sprite set specificed in the bytes I just edited. This can lead to some wonky animations, but that isn't the point!

How does this information help us? Well, this way: if you know the specific Action number of a move you want, you can actually find where the game will dump that action's sprites. For example, I changed Jago P2's action in the next image to his state where he dies to a disembowl ultimate (for example, his own sword ultimate). I chose it because that state stops and suspends animation when it finishes. How I got it to play without ending the game or darkening the screen? There's another two byte values that I haven't discussed. They will auto trigger any animation, in proper form, on demand. However, this is something I'll document later, but will be useful to future sprite ripping tools. Probably I guess. Anyway, this Action number is AD. What I did is I then when back to the sprite table in the beginning, followed the 320 pointer to the 360 Jago workspace table. Now, you multiply the AD value IN HEX by 4. This gives you the table offset that will lead you to the entry you need. So, ADh x 04h = 2B4h. 360h + 2B4h = 614. This leads to the second image, where I go to the 614 value and, as expected, you get a cozy address pointer leading to the area where the sprites for action AD are being dumped!

So, the next image I changed things to make it simpler to A) find the damn sprites and B) to better show details of the format. This consists of the same character, Jago (he's my debugging gimp), in the neutral Action (Action 00). Following the paragraphs before this. Both Jagos will pull from the same data table. You will then be pointed to the 360 table of all of Jago's Actions. 00 times 4 is still 00, so there is no offset for neutral Action, this leads us to the pointer 880D8000. This is where the game is dumping this action's sprites. If you go to this address in the memory, you get my next image. This is where the good stuff happens.

In the first Red box of this image is the specifier that shows, in 00XX00YY format, what max sprite amount is being DISPLAYED (XX) and what Action is being specified (YY). The game always loads all the sprites needed, so editing the display number lower means that all sprites after that value won't display, and editing it to load more does nothing. There's some kind of independent check. Editing YY does nothing. I think.

The next set of values, the Aqua box, is the offsets where each new sprite begins. The first value, 00, is some weird thing. It leads to another thing somewhere, and editing the XX in the previous 4 byte word to 00 (this value) cancels out the sprite. So 00 leads somewhere I don't understand. The next 4 bytes though is an actual sprite location. This continues until the Action is out of sprites.

The Yellow box is the BEGINNING OF A SPRITE. If you take the 880D8000 and add 5C to it, it points to this box as the first sprite of the set. This box denotes WHERE it'll start placing it on the screen in AAAABBBB format. Messing with these values changes where the sprite is on an (X,Y) plane, and you only really need to edit them like 00AA00BB, editing them as full 2 byte sets will move it crazy distances.

The Magenta box is the DIMENSIONS of the sprite. In this example, the sprite detailed is 007F pixels tall, and 004F pixels wide. Editing this can be buggy. Editing the height downwards clips the sprite, editing it higher crashes the game, and editing the width does nothing discernible until you corrupt other values. This is straight forward.

The Orange box is where things get WEIRD. If you edited the width, editing the first byte of this box will make the line continue on. It will continue to dump values until it's reached the value you've specified. If you make the sprite with FFFF and then edit this first byte to FF, the game will dump the pixels of the sprite in a single line but NOT crash. The next byte is a X offset that shows how far away from the "edge" of the sprite this line is. Future values that function this same way are also marked by red dots. The next byte is weird, editing it reveals pixels, but it's different than how it usually works. This byte controls 2? Pixels instead of just one like the others. I have a feeling this tweaks the transparency at the end of the line, or ALL lines. The last byte is some kind of control. If you edit it, it'll crash the game. I call these "Control" bytes. I've labeled the first few lines of this sprite this way: if a control byte happens without an X offset byte, I mark it with an orange dot. If it occurs WITH an offset byte, I box them and red dot the offset byte. The last box I mark, with the 0B control, should have a red dot on the second byte. That's also an offset.

The rest are uncompressed, coding pixels at 1 byte per pixel at in a 00-FF or 255 color palette. The game stores them line by line like this, offsetting in the X direction when it needs to. This is exactly why we couldn't find it using tile viewers. It does NOT store then like we usually store sprites. It stores them line by line, dropping the line whenever full transparent pixels are there. Isn't that dumb? I think it's really dumb. Don't believe me? Avoiding corrupting the control bytes or the offset bytes, I corrupted all the pixels to return a CC value for each byte that codes a pixel. This means the fills that pixel with color number 205/255. This is where the benefit of having two differently paletted Jagos comes in. CC codes for a dark gray on palette 01 Jago (black one), but a lighter gray on the 03 palette Jago (white one). All pixels up to that point are accounted for visually, so the control bytes can't be coding for pixels like the normal ones, and the offset is easily seen, if you mess it up you'll have a like of pixels jutting out.

So, this leaves my investigations at a few questions I can't answer:

The "control bytes" in the sprite data seem random to me. Why do they seem to show up irregularly? When I think that I figured it out, it just doesn't happen. The occur at the end of lines, but sometimes not. They occur with offset marks, but sometimes not. They're bizarre and make no sense

Line breaks, how does the game know when to break the line and move up? The game prints out the sprite from left to right, bottom to top. How does it know when to move up?

If someone can investigate these two questions, a sprite dumping hook can be coded to do the following routine:

Load an animation by forcing a new animation using the animation force byte.
Find the action related to this animation by reading the action byte.
Go to the sprite workspace table related to the character being animated, add the offset related to the action, and find the workspace where this action is.
Go to the workspace, read the max frame, sprite location table, and begin dumping sprite by reading the data according to its specifications and palette info specified by the user/game
Load the next animation, repeat until all animations/actions have been dumped.

I hope this gets people working on dumping the sprites, the ones that are out there aren't that great, however I feel that the sprites in the CHD are probably stored this way too, if the background BMPs are uncompressed as well. It's just the game stores sprite funny with this line by line system instead of square tiles, which means tile viewers are useless. If we look hard enough and figure out the format, we can either look for sprite data and rip it using these specifications, or force the game to load random areas of sprites hoping to load something they forgot to delete and rip them/get them to display in game!

theassassin
Member
Level: 13

Posts: 15/28
EXP: 8133
For next: 2134

Since: 01-22-14

Since last post: 6.2 years
Last activity: 6.1 years

Posted on 08-08-15 05:37:07 PM

Link | Quote

I'm not going to pretend I even understood 1% of that, but full sprite rips of KI 1 arcade would be cool. Would be amazing to see some deleted animations or even traces of deleted characters to be even more optomistic! Thanks for your hard work

TTRlovesMittens
Random nobody
Level: 4

Posts: 2/3
EXP: 257
For next: 22

Since: 08-04-15

Since last post: 6.7 years
Last activity: 6.6 years

Posted on 08-13-15 08:01:34 AM (last edited by TTRlovesMittens at 08-15-15 08:42:48 AM)

Link | Quote

I'm posting this just so I don't forget, and if it helps anyone then that's great!

The endianness of the line flips when it stops loading the table and starts loading the sprite itself. Something like that. I noticed that, when I accounted for endianness in the control block, suddenly everything made much more sense. Knowing that the secondary control block always occurred two bytes away from the line break block made me realize the data was the opposite endianness of the table that proceeds it, so factoring that in the line break block directly codes for how many pixels are in that line.

What does this mean? Once I figure out the first block value of each lines 4 byte header, I can detail the way the game describes each line of sprite. Using this data, either I or someone else can code a tool where, if you point it at a certain value in a decompressed KI2 CHD, and specify a palette "file" that I roughly know the format of, we could probably get sprite rips of KI2. This isn't a promise, but a possibility.

My next goal is to look at KI1, and see if the game stores sprites the same way. If it does, then it could mean we adapt such a tool to work with both games. If not, then I'll just tinker around in KI1 and figure out how it ticks.

Edit: Okay so I made one more discovery that topped everything off. The entire sprite format for KI2 is done, and I'm pretty sure KI1 uses the same format. I'm going to double check tomorrow, but I'm like 90% sure once I finish trying to code this tool for displaying (and eventually ripping) sprite data, it will be applicable to both KI1 and 2. I am hopefully that this can sniff out both used and unused sprites, but it'll be really unwieldy for normal end users. That and this is my first time coding so it'll be buggy af but hey at least the tool will be out with source right? I've been letting Abystus in on my progress and he's helping me code, so hopefully this will be a great tool for both people wanting to sniff out sprites and those who want to rip HIGH QUALITY sprites (they'll be extremely close to what the game displays natively, almost to the point of 1:1 if I can implement paletting correctly.)

TTRlovesMittens
Random nobody
Level: 4

Posts: 3/3
EXP: 257
For next: 22

Since: 08-04-15

Since last post: 6.7 years
Last activity: 6.6 years

Posted on 08-20-15 01:24:12 AM

Link | Quote

The tool is still really buggy, and there is one functionality that I can't figure out how to implement (the transparency blending at the beginning and end of the line. The benefit though is that this sprites are arcade accurate and if I get the transparency implementation it'll be 100% arcade authentic.

But yeah the tool is coming along, we're also tweaking it to try to process data that might be Vampire and or other unused sprites.

MathUser
Member
Level: 17

Posts: 42/48
EXP: 20856
For next: 3887

Since: 07-17-11

Since last post: 231 days
Last activity: 230 days

Posted on 08-27-15 08:00:19 PM

Link | Quote

It's good that you have made progress on this. I hope you dig into the first one pretty good cause I'm curious about the unused character.

____________________
-------------------------------
#1 in ROM and RAM altering Game Enhancement codes
http://gamehacking.org/

Abystus
Member
Level: 18

Posts: 59/60
EXP: 29536
For next: 361

Since: 04-03-11

Since last post: 6.0 years
Last activity: 5.8 years

Posted on 08-28-15 07:24:09 AM (last edited by Abystus at 08-28-15 07:30:30 AM)

Link | Quote

What we have currently can be seen in this video. So far we know the following about the second game based on what has been found:

- Dominations where similar to Humiliations in which they make the character dance. There is a dance for all characters excluding Gargos.

- All characters excluding Gargos have two Taunt moves. They most likely would play when knocking the opponent down between rounds or perhaps pre-fight, but may have also been accessible via input code during the round.

- There are very early FMV animations for each character to be played either in the opening profile screens, character select, versus screen, or when winning a round. Take notice on how their designs differ from the final versions (especially Orchid).

- Kim Wu has an unused "Blow A Kiss" fatality.

- There are several unused background elements, along with other misc sprites that need to be documented.

Unfortunately, a full scan of the disk did not produce any sprites related to the character known only as "Vampire". Considering there are many animations left over from early betas/alphas of the game, it is assumed that if he did exist at all then his sprites would be present as well. We are still looking, though the odds of finding something are looking slim.

Killer Instinct 1 has a lot of unused content as well spanning from background elements, moves, etc... After I completely document all sprite locations in KI2, I will then do the same for the first game.

Register - Login
Views: 99382158	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	04-24-22 01:13:14 AM

Query execution time:	0.088972 seconds
Script execution time:	0.017158 seconds
Total render time:	0.106130 seconds