I decided to try look into special move inputs. I was hoping it was going to be simple as figuring out the how the memory reads the inputs. and just read the bytes search for it like that. But it’s not looking that easy and they changed the value of the inputs too.
I just hope they’re not in the 1st_read which means it’s shared with the whole cast.
Great stuff Jedpossum, hopefully u’ll keep on experimenting as this stuff is really interesting.
I’m going to take a quick break on Dreamcast and might do a hitbox script or two nothing as drastic as the training mode scripts.
Break over, SoR3 camera was pissing me off too much.
Working on sprites the first 3 pointers in the file.
Replaced the first two sections of Spiral’s(aka one of the biggest sprites in the game) data with Jill’s sprite(Randomly chosen). As I try to change more the more unstable it got unless changed it to a completely different file. As for specials they’re not on the dat file. Might to check the S_PL##H files later.
LMFAO that looks ill
Graphic 2 pointer aka Parts of sprite.
You take the cell value from the animation data times it by 4 add the sum to the second pointer in the dat file. Add that value to the second pointer and you’ll get to the parts table.
Example.
One of Spiral’s standing cells is 0x0033 times it by 4 and get 0x00CC add that to the second graphic pointer(0x0FA140) to get address 0xFA20C which you go to get value 0x132E(Remember big endian). Add 0x132E to the pointer again to get 0x0FB46E the address to the parts table.
(sure it’s the memory but it still works the same with additional math)
Now the parts format.
The very first two bytes is how many parts are in the cell. In that picture it’s 0x0008(Remember big endian) so 8 parts.
As for the format it’s fairly simple each part is just 8 bytes.
0001 0203 0405 0607
XXXX YYYY COLR GRAP
XXXX = X signed value
YYYY = Y signed value
COLR = Palette assigned to it
GRAP = Graphic used on said part.
Okay didn’t work on it today doesn’t mean I didn’t get work down previously. Getting to actual graphic data is the pretty much standard.
Dunno If I should post how as it’s the same as above except different pointer and with the GRAP value
(val*4 + pointer) = tableadr
(tableadr + pointer) = Address to the table
I haven’t figured out the pixel art format but it looks to be using compression.
I only changed that one byte and it nearly filed a block(which is high lighted in the memory on the right).
Really good to see that there’s progress getting hitboxes for MvC2 and CvS2. It’s about time.
I know this post is 8 months old, but has anyone managed to extract any sound files from the MvC2 PLXX_VOI.BIN files? None of the minidsf files seem to want to play in Audio Overload, foobar2000, or Winamp when the plugins are installed. SE_COMN.BIN doesn’t want to dump anything that works, either.
However, several files from CvS Pro SND_PLXX.BIN files seem to extract just fine; only 4 of Cammy’s (SND_PL0C.BIN) minidsf files won’t play with the rest being perfectly OK.
One thing A3/CvS hitbox format it applies to at least to one more game as well.
Any way more format news.
Sprite Art
00 01 02 03 04 05 06 07 08
01 01 43 00 05 56 35 05 54
See that tiny block on the foot that’s all the little bit of data above edited.
Haven’t figured out the whole format, First bytes are the size. The next two seems to be a way to show what the chunk won’t edit in the block.
The next byte seems to be some type allignment.
Which leaves the pixel data which is simple each half byte represents a pixel that loads from the palette. 0 is blank.
00 01 02 03 04 05 06 07 08
XS YS BT CC ?? PP PP PP PP
Dunno, if this is right.
XS = X size
YS = Y size
FB = Overlap Block
C = Color
?? = Unknown
P* = Pixel
*Every P is a pixel
CFJ? Doesn’t surprise me one bit considering it uses the exact same engine as CvS2.
Also, the player packs for the characters that were in CvS2 that returned in CFJ are in the exact same spots, as well, including Blanka who didn’t quite make it in.
Not really, engine part is true but the character files are just coincidence. Cause 0x0F being Jedah is the same slot as it was in Vsav does that mean they used based it off of vsav as well. Ryu is almost always 00.
Finally made a custom tile still not closer to figuring out the format.
Edit: Added palette to help show where in the memory the edit is.
Sprites are actually 8x8 instead of CPS sprites of 16x16.
If you think pixel art is hard try doing it in a hex editor with an unknown compression.
Example Uncompressed Block (Size 8x8 Not the C pictured above)
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
?? ?? 01 01 00 22 22 22 22 22 22 22 22 00 22 22
22 22 22 22 22 22 00 22 22 22 22 22 22 22 22 00
22 22 22 22 22 22 22 22
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
?? ?? XB YB CM PP PP PP PP PP PP PP PP CM PP PP
PP PP PP PP PP PP CM PP PP PP PP PP PP PP PP CM
PP PP PP PP PP PP PP PP
XB how many 8x8 blocks on the x axis
YB how many 8x8 blocks on the y axis
CM Compression 00 is uncompressed
Each P is a single Pixel
As for the compression it seems to be reading the from the previous pixels.
After a short break, I’ll explain more of the graphics. I’m guessing the word at the beginning is there to help identify the graphic similar to how palettes are done on UMK3 and FHD.
First of all art is done as Player 2, It’ll help having a standard. If you have evidience it’s 1P, I doubt it as the collision box coordinates seems to agree with me that it’s 2P. Plus on CPS2 art sprite art was 2P as well.
Graphic size
The of X,Y. In X the 8x8 blocks are loaded in a order in left to right till it fills the row. Y is different top to bottom but blocks get pushed to the bottom. One little quirk with if you use one odd number the other value has to be a 1 or it’ll be display as the next even number(3 becomes 4).
Compression
I have to open and close with it. I don’t know any more with it yet.
Pixels
Each uncompressed 8x8 block there is 4 4x4 chucks
Here is an example 4x4 chunk.
12 34 56 78 9A BC DE F0
How it'll appear as a 4x4 chunk.
57DF
68E0
139B
24AC
Sprite Compression
BC <PIXELS> MIRROR
BC Chooses what the copy can be just 2 pixels or a 2x2 block.
After the pixels is how the mirroring of said chosen piece is done. This can vary in length.
What made this so damn hard was that the game would keep reading data to fill up the block so it made it hard to see what was going on.
THIS IS FUCKING SICK
Thanks to jedpossum I managed to solve the compression scheme that the graphics use. Basically you take the 4x4 tiles and rearrange them as such for every four
2 4
1 3
And then if that particular piece is large enough, you take 8x8 tiles and rearrange them. And then if it’s large enough take 16x16 tiles… repeat until sprite is unscrambled.
>
>
I’ll look at creating a frameviewer now, but in the interim please enjoy some sprite rips.
http://mugenguild.com/forum/topics/marvel-vs-capcom-2-sprites-157823.0.html
I had heard from a dev on the project that Strider’s sprites were weird. Surprising to have one more piece of confirmation on that. 
The coloration on the Ruby ghosts (0561- and 0664-) is weird/wrong. This does correspond to the DC sprite rips I’ve seen before, though.
There is a lot of wrong colors like the lunches in lunch rush. Ruby’s crew members, Sprial’s Metamorphosis.
He knows about it already though.
Also, not the first time these games shared artwork. Petshop’s placeholders were Iceman’s projectiles from cota.
