Sonic and Sega Retro Message Board: shobiz - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

shobiz's Photo
Group:
Tech Member: Tech Members
Active Posts:
895 (0.24 per day)
Most Active In:
Engineering & Reverse Engineering (377 posts)
Joined:
27-March 05
Profile Views:
3222
Last Active:
User is offline Private
Currently:
Offline

My Information

Age:
23 years old
Birthday:
October 22, 1991
Gender:
Male Male
Location:
Karachi, Pakistan
Interests:
Mathematics, sciences, programming, reading, (association) football

Contact Information

E-mail:
Click here to e-mail me
MSN:
MSN  [email protected]
Website:
Website  http://

Previous Fields

National Flag:
pk
Wiki edits:
4,411

Latest Visitors

  1. Recent Status Updates
  2. About Me
  3. Topics
  4. Posts

Posts I've Made

  1. In Topic: Basic Questions & Answers thread

    15 August 2010 - 06:14 AM

    QUOTE (Ravenfreak @ Aug 14 2010, 10:57 AM)
    I have a question regarding the super/hyper flag in S3K. It says on the wiki, to set the hyper flag, set the address with the value 7. I thought flags are only set with either a 0 or 1, since in binary format 0/1 means off/on. Also, I set the flag with the value #-1, and it worked. I didn't really know where to post this, but would this be correct?

    Actually it said set bit #7, like MJ said. I've changed the wording to be clearer. Additionally, flags only need to be either 0 or 1 if they occupy just a single bit. The Super/Hyper flag occupies a whole byte and so can take any value between 0 and $FF.

  2. In Topic: Sonic 2 Split Disassembly

    04 August 2010 - 02:21 PM

    QUOTE (FraGag @ Aug 3 2010, 07:57 AM)
    I'm sure SOTI would be pleased to learn that it's caused by my wizardry in the RAM declarations. :P

    Wait, so if you declare RAM variables using equates instead of phase it works fine? How odd. I've changed them to nameless temporary symbols for the time being.

  3. In Topic: Ristar disassembly

    04 August 2010 - 02:18 PM

    The code isn't confusing at all if you know how the Sprite Attribute Table works, and if you don't there's always genvdp.txt. Anyway, the mappings data starts off with an offset table which is identical to the one in Sonic 1. The format of each frame's mapping data is NN ?? (YY SS AAAA XX XX'). NN is the number of sprites in the frame - 1, so the bytes in brackets are repeated NN + 1 times. I have no idea what ?? is but it's moved to byte 4 of the object's status table. YY is the Y offset, SS is the sprite size, AAAA is the art tile, XX is the X offset and XX' is the X offset in case the object is X-flipped (it doesn't need to be stored separately, it can be calculated, but I'm assuming it was done for speed reasons). For comparison, Sonic 1 is NN (YY SS AAAA XX), except NN is the number of sprites in the frame instead of the number of sprites -1.

    Also, RenderSprite is an inaccurate name since a mapping frame can consist of multiple sprites. RenderMappingFrame or RenderFrame or even RenderObject would be better.

  4. In Topic: Basic Questions & Answers thread

    04 August 2010 - 10:10 AM

    QUOTE (Sonica @ Aug 4 2010, 05:46 PM)
    Because if the actual acceleration = 0.046875 (according to the physics guide), how does it relate to 50 or 80 at all?

    The Mega Drive's processor doesn't support floating point operations as far as I'm aware, so the Sonic games use 16.8 fixed point to represent non-integral values. What this means in simple terms is that Sonic's speed and acceleration aren't in pixels/second or pixels/second², respectively, but in 1/256 pixels per second or 1/256 pixels per second², respectively, instead. So when you see the line

    Syntax Highlighted Code: ASM
    		move.w	#$C,($FFFFF762).w ; Sonic's acceleration

    $C in hex is the same thing as 12 in decimal, so this sets Sonic's acceleration to 12/256 = 0.046875 pixels per second² (which is where the number in the physics guide comes from).

  5. In Topic: Sonic 2 Split Disassembly

    02 August 2010 - 10:17 AM

    QUOTE (Selbi @ Aug 2 2010, 07:01 PM)
    I've no idea about the AS assembler, but why are those temporary labels starting with a $$? I always thought they start with @.

    They start with $$ in AS; it's ASM68k which uses @ for temporary labels.

Friends