[DarkSamus993]

Since everyone here is already talking about enemy data does anyone know where the location of Zero's sprite in MMX? X's sprite is already known and I was going to look through the object viewer in MegaEd X to try and find it, but maybe someone here already knows the location. Thanks.

Code: [Select]

Palettes:
0x2C0C0 = Zero
0x2C0E0 = Zero charging 1 (UNUSED)
0x2C100 = Zero charging 2 (UNUSED)
0x2C120 = Zero charge shot

Decompression ptr:
0x3788C = [00 21 F6 E4 A3] = $A3:E4F6, $2100 bytes

Uncompressed gfx:
0x178400 = X & Zero charge shot

Decompressed with Lunar Compress:

[pianohombre]

Thanks a billion DarkSamus!

I've never used Lunar Compress before. I'll have to check it out looks like a great program. Is it able to load the palette for the snes game or do you have to enter that info?

[DarkSamus993]

It just handles the decompression/compression. I copied the $80 bytes of palette data to the decompressed data and used tile molester to load the graphics/palettes correctly.

Lunar Compress commands:

Code: [Select]

Decompress Zero's gfx:
Usage: decomp.exe FileToDecompress FileToSaveAs OffsetToStart(h) Format1 Format2
Example: decomp MMX.sfc Zero.bin 11E4F6 102 8448

Recompress Zero's gfx:
Usage: recomp.exe FileToRecompress FileToSaveAs/InsertTo OffsetToSave(h) Format1 Format2
Example: recomp Zero.bin MMX.sfc 11E4F6 102 8448
The decompression pointer & length will have to be updated manually if you change that.

Tile Molester viewing settings:
GFX: 4bpp planar, composite ; 1-dimensional
PAL: 15bpp BGR ; 2-dimensional

If you did what I did and copy the palette data to the decompressed file, you can import the palette from there when viewing in TM.

[pianohombre]

Thanks again DarkSamus. Hey one more question. I was going to try and make some minor changes to a sprite and this will be my first time doing any sprite editing outside of Tile Layer Pro, do you know if the routine to handle sprites is usually close by to the actual sprite location? I was just going to try and follow breakpoints like I did for my previous patch, but I've edited a rom using hex and assembly before so i'm not completely new to the process. I mainly wanted to find where they store the size of the sprite and then was going to edit that.

[justin3009]

That's the Sprite Assembly you'd be looking for. If you want to cut a sprite size down that's fine but expanding may be a problem unless there's extra room in the current bank.

[DarkSamus993]

Thanks again DarkSamus. Hey one more question. I was going to try and make some minor changes to a sprite and this will be my first time doing any sprite editing outside of Tile Layer Pro, do you know if the routine to handle sprites is usually close by to the actual sprite location? I was just going to try and follow breakpoints like I did for my previous patch, but I've edited a rom using hex and assembly before so i'm not completely new to the process. I mainly wanted to find where they store the size of the sprite and then was going to edit that.

The first thing to note is that Zero is expected to only have up to $400 bytes of graphical data (32 8x8 tiles) loaded in VRAM at any time. It's easy enough to load more tiles, but then you'll be overwriting other tiles if you don't rearrange how data is loaded into VRAM.

Code: [Select]

$7F:2DA0 = Zero gfx (decomp)

Dashing:
$84/9023 BD 00 00    LDA $0000,x[$85:A9B4]   A:0010 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9026 C2 21       REP #$21                A:0020 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9028 29 FF 00    AND #$00FF              A:0020 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902B 0A          ASL A                   A:0020 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902C 0A          ASL A                   A:0040 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902D 0A          ASL A                   A:0080 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902E 0A          ASL A                   A:0100 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902F 99 03 05    STA $0503,y[$85:0503]   A:0200 X:A9B4 Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
...
$84/9023 BD 00 00    LDA $0000,x[$85:A9B9]   A:A920 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9026 C2 21       REP #$21                A:A920 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9028 29 FF 00    AND #$00FF              A:A920 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902B 0A          ASL A                   A:0020 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902C 0A          ASL A                   A:0040 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902D 0A          ASL A                   A:0080 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902E 0A          ASL A                   A:0100 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902F 99 03 05    STA $0503,y[$85:050B]   A:0200 X:A9B9 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
...
$80/8350 BD 03 05    LDA $0503,x[$80:0503]   A:6500 X:0000 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
$80/8353 8D 05 43    STA $4305  [$80:4305]   A:0200 X:0000 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
...
DMA[0]: CPU->PPU Mode:1 0x7F2DA0->0x2118 Bytes:200 (inc) V:232 VRAM: 6400 (1,0) word
...
$80/8350 BD 03 05    LDA $0503,x[$80:050B]   A:6500 X:0008 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
$80/8353 8D 05 43    STA $4305  [$80:4305]   A:0200 X:0008 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
...
DMA[0]: CPU->PPU Mode:1 0x7F2FA0->0x2118 Bytes:200 (inc) V:234 VRAM: 6500 (1,0) word

Standing:
$84/9023 BD 00 00    LDA $0000,x[$85:A9BE]   A:0010 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9026 C2 21       REP #$21                A:0020 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9028 29 FF 00    AND #$00FF              A:0020 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902B 0A          ASL A                   A:0020 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902C 0A          ASL A                   A:0040 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902D 0A          ASL A                   A:0080 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902E 0A          ASL A                   A:0100 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902F 99 03 05    STA $0503,y[$85:0503]   A:0200 X:A9BE Y:0000 D:0EA8 DB:85 S:012A P:envmxdizc
...
$84/9023 BD 00 00    LDA $0000,x[$85:A9C3]   A:A920 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9026 C2 21       REP #$21                A:A920 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envMxdizc
$84/9028 29 FF 00    AND #$00FF              A:A920 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902B 0A          ASL A                   A:0020 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902C 0A          ASL A                   A:0040 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902D 0A          ASL A                   A:0080 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902E 0A          ASL A                   A:0100 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
$84/902F 99 03 05    STA $0503,y[$85:050B]   A:0200 X:A9C3 Y:0008 D:0EA8 DB:85 S:012A P:envmxdizc
...
$80/8350 BD 03 05    LDA $0503,x[$80:0503]   A:6400 X:0000 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
$80/8353 8D 05 43    STA $4305  [$80:4305]   A:0200 X:0000 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
...
DMA[0]: CPU->PPU Mode:1 0x7F31A0->0x2118 Bytes:200 (inc) V:232 VRAM: 6400 (1,0) word
...
$80/8350 BD 03 05    LDA $0503,x[$80:050B]   A:6500 X:0008 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
$80/8353 8D 05 43    STA $4305  [$80:4305]   A:0200 X:0008 Y:0000 D:0000 DB:80 S:02EE P:envmXdIzc
...
DMA[0]: CPU->PPU Mode:1 0x7F33A0->0x2118 Bytes:200 (inc) V:234 VRAM: 6500 (1,0) word


That's the Sprite Assembly you'd be looking for. If you want to cut a sprite size down that's fine but expanding may be a problem unless there's extra room in the current bank.

Fortunately, the game uses long pointers so that shouldn't be much of an issue.

Code: [Select]

========================
= Sprite OAM Ptr Table =
========================
Format: 3-bytes
------------------------
$8D:80F9 = ptr to Zero sprite OAM ptrs
[F9 95 8D]


===================
= Sprite OAM Ptrs =
===================
Format: 3-bytes
-------------------
$8D:9605 = Zero standing
[ED E0 8F]


==============
= Sprite OAM =
==============
Format: 
# of tiles
Tile 01:
     byte-1 = xPos
     byte-2 = yPos
     byte-3 = tile index
     byte-4 = v/h flip, palette, tile size
Tile 02
Tile 03
etc...
--------------
$8F:E0ED = Zero standing
[0E]
[04 ED 50 00]
[04 EE 50 00]
[0C 10 50 00]
[0C 08 59 00]
[0C 00 49 00]
[FA E8 51 00]
[04 00 57 00]
[04 10 58 00]
[04 08 48 00]
[04 F8 56 00]
[FC 10 47 00]
[F4 10 46 00]
[F4 00 44 20]
[F4 F0 42 20]


[ThegreatBen]

Just saw that you updated, thanks for adding my suggestion, Thanks to DarkSamus993 for showing how. and downloaded

[pianohombre]

If you did what I did and copy the palette data to the decompressed file, you can import the palette from there when viewing in TM.

Did you use an unheadered or headered rom for MMX? Also version 1.0 or 1.1 of the rom? I just got a bunch of scrambled up graphics and couldn't get any palette to load. Not sure how you loaded the palette from just the bin file since there's no offset to to type in and TM doesn't save palettes. I was able to view the correct palette in the original rom when using TM but not the bin file.

[DarkSamus993]

Did you use an unheadered or headered rom for MMX? Also version 1.0 or 1.1 of the rom? I just got a bunch of scrambled up graphics and couldn't get any palette to load.

My rom has no header and the palette locations did not change between revisions (so 1.0 or 1.1 will both work). The scrambled graphics are because you tried to decompress at the wrong address (which tells me your rom has a header).

Not sure how you loaded the palette from just the bin file since there's no offset to to type in and TM doesn't save palettes. I was able to view the correct palette in the original rom when using TM but not the bin file.

I copied the $80 bytes of palette data (0x2C0C0-2C13F) and pasted it to the start of the decompressed gfx. Then in TM go to palette\import from\this file...

Code: [Select]

offset: 0; format: 15bpp BGR; size: 64


[pianohombre]

Thanks I was able to get the palette and sprite by adding 0x200 bytes for the header when searching for it. Although, I had some trouble because the size of the palette was actually 16 for the rom I was working on not 64, so it loaded the wrong color. Basically, what I'm trying to do is fix 2 bugs. In the MMX- Zero rom hack, that's on this site, X (who replaces Zero because Zero is now the main character) is missing half his blaster and Zero is also missing his hair. This is because Zero is 32x32 and X is 16x16 so I have to try and change the asm accordingly. I'll begin to look into the asm tomorrow. It took me longer than expected to get tile molester working properly. Oh brother (charlie brown sigh)

[justin3009]

It's not the ASM you have to worry about, it's the sprite assembly.  To have Zero display his full body and hair as a playable character you will have to move ALL of X's Sprite Assembly into a new location and accommodate for it.  Not too mention with hair, you'd have to reorganize all the graphical data to suit it.

This is where I did with X2 was just expand the ROM to X3 size and copy/paste Zero's sprite assembly and animation data into X2.  The problem that came with after that is the actual animation bytes are different between X and Zero.  So those would have to be changed too and boy there is quite a few of them.

It's not exactly hard but is 'extremely' tedious.  THAT portion is where you'd need the ASM if you went that route.  Either way, it'll be time consuming as heck.

[pianohombre]

It's not exactly hard but is 'extremely' tedious.  THAT portion is where you'd need the ASM if you went that route.  Either way, it'll be time consuming as heck.

Well the way you said it makes it seem pretty intimidating. Honestly, it's just a small bug fix that I primarily wanted to tackle to better understand how to handle hex and assembly. The previous rom I worked on I got to edit the RAM map, and injected some assembly to deal with it, but I didn't handle any graphics at all. I'll probably hold off on this for awhile and work on the MegaEd level editor. I'd probably just end up copying and pasting most of your Zero routine anyways lol. There's some assembly on Superfamicon.org that looks for locations in the rom to store 16x16 and 32x32 tiles. It loads the final address on the accumulator and someone could just pull it out during a breakpoint.

No one is really begging to play Zero on MMX1 anyways, and just spending so much time fixing a small thing without doing anything major like editing the levels seems like a waste. But I feel like now that I've started the project I should go all the way through.

[pianohombre]

Lunar Compress commands:

Code: [Select]

Decompress Zero's gfx:
Usage: decomp.exe FileToDecompress FileToSaveAs OffsetToStart(h) Format1 Format2
Example: decomp MMX.sfc Zero.bin 11E4F6 102 8448

Recompress Zero's gfx:
Usage: recomp.exe FileToRecompress FileToSaveAs/InsertTo OffsetToSave(h) Format1 Format2
Example: recomp Zero.bin MMX.sfc 11E4F6 102 8448


I know it's a faux pas to revive a thread from the dead (actually it hasn't been 60-90 days yet). Although, I don't understand Lunar Compress the best. In the command-line you type the flags "Format 1" "Format 2". In your case you typed 102 8448 both for recompression and decompression. In LC documentation I saw MMX uses RLE3 compression. Is 102 just another way of writing that? What is the format 2 thing? Reason I ask is because one of the programs I'm working on has a lot of problems saving some levels. The program was meant to handle only MMX1, but was edited to work with 3 other MMX games. I'm just not sure if maybe they used a different compression algorithm for MMX2 and up. If I knew the formats I could test different compression routines and then fix the save functions.

If you'd like to see what I'm talking about it's level 7 in MMX2 with MegaEd X editor (overdrive ostrich). Basically it screws up the layout when saving so it's buggy when playing in an emulator. The RLE compression routine isn't necessarily a true RLE routine (this is documented in the LC readme), but uses bitwise operators to compress the layout. Anyways, if for some reason MMX2 uses different format to compress the layout that would explain all the bugs. Awkwardly enough, or not awkwardly if you're a computer whiz and understand all the low-level stuff the layout isn't messed up when expanding the rom and then saving.