Sprite Mappings Editor

Wow that looks really cool! Keep up the good work =)

 

Looks very nice. I think that if it'll be a little more user-friendly, it'll be even better.

 

YOU STOLE MY IDEA!!!!!!!!

:P

No, really, I wactually was planning on making a mappings editor, and I have the notes to prove it. Not that I'm complaining or anything, as this app looks far better than I could have come up with. One ting I wish we could have though? An animation editor. Just find the offsets for the animation scripts (we have disassemblies, so they shouldn't be hard to find) to test them andmake something that allows you to build and test animations. Other than that, I have only obvious features, like ability to import art, the ability to draw a sprite and THEN generate art and mappings based on the completed image. As for your questions:

1: We have disassemblies for 1 & 2 we can use. As for S3K, you're gonna have to actually ask someone. Of course, there's always Nemesis' hacking guides on SCHG at info.sonicretro.org .

2: The Super Sonic mappings for S3K are actually seperate from regular sonic's mappings. Might explain why you didn't find them :P The address is $146816

3: Actually, I was under the impression they were unused by the game, and a quick look at my disasm shows that that is quite he case, even when loading sprites in 2P mode. Maybe it just does some quick math that applies to all sprites, I dunno. Regardless, I thoink you should just ignore it, or at the very most provide an editable field for it just in case.

Great job with this so far, and I look forward to its progress.

 

That looks amazingly useful! Keep up the good work!

 

That looks very useful and easy to use. Good for you, you've combined the powers of Tile layer pro and Sonik sprite into one. I might just start doing hacks again

 

Wow, that's impressive.

Why is this man's square not green?

 

Can this tool edit all mappings PLUS the character mappings?

If so, as soon as this is released LOst Library is basically obsolete.

 

In Mappings it's Actually FTTT and not FFTT, The Second FTTT in S2 deals with 2P Mode, The F Remains the Same as the First but the TTT is Divided in Half of the 1P TTT, It's simple really since that's how 2P stores it's Vram, Halved.

 

The 0s after FFs in animation data is just padding, to make the stuff after the data on an even byte (68k code will only work if its on an even byte address).

As for compression - you could use Kens DLLs, or the Kens source code I guess.

 

Xenowhirl for full member now plz. :>

 

Wow, best GUI ever. Continue on it. I like how the other sprites of the animations (the nearest ones) are shown, too. Amazing.

 

It's not that some animations end with FFFFFF, it's that there's some blank animations that begin and end with FF. Check the "?" animations in the following list, for example:

Code (Text):

1. Sonic object animations (Sonic 2 prototype)
2. Documented by ICEknigh7
3.  
4.  
5. 00  Walk            FF0F10111213140D0EFF
6. 01  Run         FF2D2E2F30FF
7.     ?           FFFF
8.     ?           FFFF
9. 02  Spin            FE3D413E413F414041FF
10. 03  Fast spin       FE3D413E413F414041FF
11. 04  Push            FD48494A4BFF
12.     ?           FFFF
13.     ?           FFFF
14. 05  Wait            050101010101010101010101010101010101010101010101010101010101010203030303030
15. 40404
16. 05050504040405050504040405050504040405050506060606060606060606040404050505040404
17. 050505040
18. 40405050504040405050506060606060606060606040404050505040404050505040404050505040
19. 404050505060606060606060606060404040505050404040505050404040505050404040505050606
20. 060606060606060607080808090909FE06
21. 06  Ledge           09CCCDCECDFF
22. 07  Look up         050B0CFE01
23. 08  Look down       054C4DFE01
24. 09  Spindash charge     0042434244424542464247FF
25. 0A  Return to Wait      0102FD00
26. 0B  To Lying pose       030AFD00
27. 0C  Ledge edge      03C8C9CACBFF
28. 0D  Skid            05D2D3D4D5FD00
29. 0E  Float           075459FF
30. 0F  Float & rotate      075455565758FF
31. 10  Spring          2F5BFD00
32. 11  Grabbing pole       015051FF
33. 12  Leftover (S1)       0F434343FE01
34. 13  Leftover (S1)       0F4344FE01
35. 14  Hanging         136B6CFF
36. 15  Bubble breathing    0B5A5A1112FD00
37. 16  Burnt           205EFF
38. 17  Drowning        205DFF
39. 18  Dead            205CFF
40. 19  Hit         404EFF
41. 1A  Hit
42. 1B  Slide           094E4FFF
43. 1C  Disappear after hit 7700FD00
44. 1D  Ledge backwards     13D0D1FF
45. 1E  Ledge edge backwards    03CFC8C9CACBFE04
46. 1F  To Super Sonic      090809FF
47. 20  Lying           0307FD00
48. 21  Getting up      0040004AFEAA

Seems like they removed some animations and they got FFFF's as leftovers, for some reason.

If you add more frames and don't change the pointers to the following animations, these will keep pointing to the same place, which might now have another animation in its place.
No idea where the pointers are, though.

 

Because I wasn't here.

Still, I don't think I'll tech him just yet... But full member is a given.

Nice job! I'm hoping I can make better use of this than LL.

But, by split disassemblies, do you mean in hex, or do you support actual ASM mappings? I'd prefer the latter, if at all possible.

 

That's not quite right either.. from my notes:

Code (Text):

1. Mappings are stored in Object RAM to determine how any sprite should be drawn. It points
2. to a starting tile by ID, and contains information on how many tiles from that point on
3. in VRAM should be drawn, and in what shape, direction, and palette row they should be
4. drawn
5.  
6. They begin with a byte describing how many mappings are used to build a particular sprite.
7. Each mapping for said sprite is defined as listed:
8.  
9. Byte 0- (Signed Char) Y offset from the sprite's position at which to draw this mapping
10.  
11. Byte 1- Bitfield: 0000 00 00
12.         Field 0- Not Used
13.         Field 1- Horizontal Size (in tiles) - 1
14.         Field 2- Vertical Size (in tiles) - 1
15.        
16.         Horizontal and Vertical sizes are defined in the number of tiles taken to build the sprite.
17.         Sprites are filled vertically first, then horizontally, meaning that the second tile to be
18.         drawn will go BELOW the first (if the height is greater than 1 tile). A value of 0 will
19.         give a size of 1, making the largest possible height/width 4 tiles (32 pixels)
20.  
21. Byte 2- Bitfield: 0 00 0 0 000 (Palette/Direction)
22.         Field 0- Display on Low/High Plane
23.         Field 1- Palette Row
24.         Field 2- Y Flip
25.         Field 3- X Flip
26.         Field 4- Tile ID High Bits
27.  
28.         Plane values: 0 - Low
29.                   1 - High
30.  
31.         Palette row values: 0 - row 1
32.                             1 - row 2
33.                             2 - row 3
34.                             3 - row 0
35.  
36. Byte 3- (unsigned char) Tile ID Low Bits
37.  
38.         Tile ID is an offset (in tiles) from the starting point in VRAM, given elsewhere. Take the
39.         lower 3 bits of Byte 2, multiply them by 256, and add them to Byte 3 to get this value
40.  
41. Byte 4- (Signed Char) X offset from the sprite's position at which to draw this mapping

That's the Sonic 1 format. In Sonic 2, bytes 2 and 3 are duplicated with the tile ID cut in half to account for the fact that tiles are double-height in the 320x448 mode, and byte 4 is extended to a word (as is the byte representing the number of entries), probably just to keep the data size even. In Sonic 3, the only difference from Sonic 1 is that the number of entries and the X offset are extended to word.

There's nothing wrong with the art loader, they just knew exactly how much space they would need to store the player frames they had, and allowed themselves only that much. In Sonic 1, the art player art is copied to RAM first, and then DMA'd to VRAM from there during VBLANK by hard code. Sonic 2 and above use a list where they queue whatever DMA transfers they want to happen during VBLANK by listing the source address, destination address, and data size, and they usually use it to send art directly from ROM to VRAM

 

You heard the man, we best scrap these "disassemblies" if we want to make finding the animation script offsets easier. :P *shot*