[Quickman]

Nothing original though, unfortunately. But as LOst said to me, in this community nobody can ever really be first at anything.

Here's a small gift from me to you. Credits come afterwards. This could well be incomplete, but I think it's fairly complete.

Ha breakdown for something called the Sprite Status Table. These 64 (40) bytes determines everything about one sprite. You can find these in savestates at $FB78 (Sonic 1), $D878 (Sonic 2 beta and final).

$00(a0) - Action number        (byte) 
$01(a0) - Action flags        (byte) 
$02(a0) - VRAM offset        (word) 
$04(a0) - Mappings offset      	(long) 
$08(a0) - X position        (long) 
$0C(a0) - Y position        (long) 
$10(a0) - X move speed        (word) 
$12(a0) - Y move speed        (word) 
$14(a0) - Vertical distance from middle of sprite to bottom of sprite  (byte) 
$15(a0) - Horizontal distance from middle of sprite to bottom of sprite  (byte) 
$16(a0) - Sprite priority      	(byte) 
$17(a0) - Width in pixels      	(byte) 
$18(a0) - Pattern number      	(byte) 
$19(a0) - Pattern counter      	(byte) 
$1A(a0) - Pattern change number      	(word) 
$1C(a0) - Animation        (byte) 
$1D(a0) - Master animation      	(byte) 
$1E(a0) - Collision size      	(byte) 
$1F(a0) - Collision counter      	(byte) 
$20(a0) - 1st routine        (byte) 
$21(a0) - 2nd routine        (byte) 
$22(a0) - Angle        	(word) 
$24(a0) - Object routine counter      (byte) 
$25(a0) - Sub-routine counter      	(byte) 
$26(a0) - Collision        (word)
$27(a0) - Unknown, assumed user-defined byte    	(byte)
$28(a0) - Unknown, assumed user-defined byte    	(byte)
$29(a0) - Unknown, assumed user-defined byte    	(byte)
$2A(a0) - Unknown, assumed user-defined byte    	(byte)
$2B(a0) - Unknown, assumed user-defined byte    	(byte)
$2C(a0) - Unknown, assumed user-defined byte    	(byte)
$2D(a0) - Unknown, assumed user-defined byte    	(byte)
$2E(a0) - Unknown, assumed user-defined byte    	(byte)
$2F(a0) - Unknown, assumed user-defined byte    	(byte)
$30(a0) - Unknown, assumed user-defined byte    	(byte)
$31(a0) - Unknown, assumed user-defined byte    	(byte)
$32(a0) - Unknown, assumed user-defined byte    	(byte)
$34(a0) - Unknown, assumed user-defined byte    	(byte)
$35(a0) - Unknown, assumed user-defined byte    	(byte)
$36(a0) - Unknown, assumed user-defined byte    	(byte)
$37(a0) - Unknown, assumed user-defined byte    	(byte)
$38(a0) - Unknown, assumed user-defined byte    	(byte)
$39(a0) - Unknown, assumed user-defined byte    	(byte)
$3A(a0) - Unknown, assumed user-defined byte    	(byte)
$3B(a0) - Unknown, assumed user-defined byte    	(byte)
$3C(a0) - Unknown, assumed user-defined byte    	(byte)
$3D(a0) - Unknown, assumed user-defined byte    	(byte)
$3E(a0) - Unknown, assumed user-defined byte    	(byte)
$3F(a0) - Unknown, assumed user-defined byte    	(byte)
$40(a0) - Unknown, assumed user-defined byte    	(byte)

Credits: LOst (f0r initially telling me about the SST and the basic format for objects), Dr Ivo (a lot of the most basic info (not to mention my understanding) came from his documentation on object format), drx (extra info from Yuji Naka patent document which he folded neatly into the existing SST data and which I subsequently stole).

RAM map removed due to severe incompletion.

This post has been edited by Quick Man: 04 June 2004 - 04:59 PM

[ICEknight]

Quick Man, on May 29 2004, 02:12 PM, said:

Nothing original though, unfortunately. But as LOst said to me, in this community nobody can ever really be first at anything.

Well, I don't think anybody has ever released such an in-depth document about this, so who cares if somebody has done it before without releasing it.

Quote

First, here's a breakdown for something called the Sprite Status Table. This is valid only for Sonic 1 and 2 (beta and final). These 64 (40) bytes determines everything about one sprite. You can find these in savestates at $FB78 (Sonic 1), $D878 (Sonic 2 beta and final).

Hmm... I've just looked at the adress FB78 in a Sonic 1 (international) savestate and all I see are 00's. =\

This post has been edited by ICEknight: 29 May 2004 - 03:24 PM

[Sonic Hachelle-Bee]

OMG! Your ram map for Sonic 2 will be very useful for me!!!
With this, I have found the way to change the level that come after WFZ in 2 minutes.
Located at $3AC40, that's simply a 31 FC XX XX FE 10 thing, XX XX is the level and the act you want after WFZ, default is OE 00 (Death Egg).
In S2 long version, after WFZ, there is now DEZ1 and 2 before DEZ3!!!
Thank you a lot Quickman. That's just what I was looking for!

EDIT: There is also something about level select icons! Wow...I will print this list now, that's very useful for me!

This post has been edited by Sonic Hachelle-Bee: 29 May 2004 - 04:39 PM

[Icy Guy]

Anyone who writes a quick 'n' dirty little program to do easy calculations is sad. Like me.

Here are some additions to the S2 RAM map:

$B008.w = Sonic's X coordinates
$B00C.w = Sonic's Y coordinates

Hey, whaddaya know? That fits nicely into the Sprite Status Table breakdown. For some reason, when I changed Sonic's X coord, Gens started acting up, and I can't get it to work properly now. I'll restart my computer and test it again, as well as post a few more things (when I've found them, obviously).

EDIT: Dumb thing. Still doesn't work right, even when I overwrite it with a copy of itself. No big deal - I'm just thankful these modifications of Gens work. :D More stuff in a bit.

This post has been edited by Icy Guy: 29 May 2004 - 04:47 PM

[Quickman]

Yeah, Sonic's SST is located at $B000.w because he's always the first object loaded. Tails' is $B040 if he's loaded in Sonic'n'Tails mode and $B000 if in Tails Only mode.

ICEknight: Check Nemesis' guides is all I can say.

[Hivebrain]

I see you've put "user defined" for bytes whose purpose you're unaware of. This is a bit misleading. For example, I know there are some bytes involved in object motion, and I don't think they're specific to any one object.

[fuzzbuzz]

Object Subevent in Sonic 1 is 24(a0)
Object Subevent in Sonic 2 is 30(or 36?)(a0)

By subevent, I mean what is happening with the object, like is it moving, did Sonic take it, etc...

EDIT: Yeah, anyway, not all of that Sprite Status table is correct. Sonic 1 and Sonic 2 are pretty different when it comes to the way the sprites are programmed...

This post has been edited by fuzzbuzz: 29 May 2004 - 05:45 PM

[Icy Guy]

More STUFF!!

SST action flags:

84 = facing to the right
85 = facing to the left

Try putting 70: you can make Sonic invisible! Doing the same with Tails makes most of him disappear; I.e. his tails still remain.

Other SST stuff:

(Subevents)  Dunno if this is controlled by word at 30, byte 31, or byte 36.  They all seem to do SOMETHING related to Sonic's current status.

Byte 31:

78 = Sonic flashing after being hit

Byte 2B (Power-Up Status?):

00 = Normal
01 = Shield effect (1st hit knocks Sonic away, 2nd kills him)
02 = Invincible
03 = Invincible
04 = Normal
05 = Shield effect
06 = Invincible
07 = Invincible

Rinse & repeat.  Note that the appropriate sprites (I.e. sparkles, shield) are not loaded.

Byte 24 (Routine counter):

04 = Sonic flashing (after being hit?)
06 = Sonic's death routine, sans sprite change
0E = Tails flying (if he hits the ground, he glitches)

Weird stuff. Wish I could cook something a little more useful up, though. I've been trying to find the address that controls what song is playing in the current level, but to no avail.

[Orengefox]

When I was using ESE and Nemesis's Sonic 1 Rom Hacking Guide to edit out LZ. I notice that most of the sprite objects with a pointer value address beyond 9F all the way up to FF acted like objects you would place in debug mode. In other words, sprite objects with a pointer value address between A1 - FF that were placed in one of the acts of that zone, they would appear the first time you see them on the screen but when you would take off and come back to same area where the object appear the first time, its permanently gone unless you restart the act of that zone again. Hopefully that information was useful ^^

This post has been edited by Orengefox00: 01 June 2004 - 02:12 PM

[drx]

Hivebrain, on May 29 2004, 11:37 PM, said:

I see you've put "user defined" for bytes whose purpose you're unaware of. This is a bit misleading. For example, I know there are some bytes involved in object motion, and I don't think they're specific to any one object.

Yup, eg. $10(a0) is X move speed and $12(a0) is Y move speed (signed words)

I'll releasing stuff on my site later =P

[JoseTB]

Quick Man, on May 29 2004, 02:12 PM, said:

$1C(a0) - Object subparameter

As far as I know,$1C(a0) change the current animation (not the frame) of sonic.Is used for the movements in s1 and 2 (to change the animation "standing" to "walking",for example) It starts in 03,00 and 01 will give you strange results,02 and 03 are the same (rolling) and it continues from that.

[Quickman]

Updated the first topic.

[drx]

w00, now it's correct. Btw. I think that $28(a0) was also a sub-routine thingy.

[JoseTB]

fuzzbuzz, on May 29 2004, 05:42 PM, said:

Object Subevent in Sonic 2 is 30(or 36?)(a0)

Is 36(a0),that´s rigth.Better update the list again,because is correct,I´m sure.

[fuzzbuzz]

Yep. I'm looking at it right now, It's 36(A0)

This post has been edited by fuzzbuzz: 06 June 2004 - 10:59 PM