don't click here

Basic Questions & Answers thread

Discussion in 'Engineering & Reverse Engineering' started by Tweaker, May 29, 2008.

  1. Thank you. :>
     
  2. Brainulator

    Brainulator

    Regular garden-variety member Member
    One thing is that the points graphics will have to be moved elsewhere. Here's a video, courtesy of Clownacy (relevant parts start at 19:28):



    EDIT: Quote block added; this message and the one this is a reply to were once their own thread.
     
    Last edited: Jun 4, 2022
  3. Brainulator

    Brainulator

    Regular garden-variety member Member
    It would actually be better to do this:
    Code (Text):
    1. lea LevSel_Ptrs(pc),a0
    2. move.w    (a0,d0.w),d0
    It's a bit faster to do that, since the code is still closeby.
     
  4. thanks but i've already given up on sonic 1 and trying my luck in sonic 3 (i also completely ditched the mania md idea lel)
     
  5. saxman

    saxman

    Oldbie Tech Member
    Hmm... what exactly are you hoping to accomplish? Are you just experimenting for fun, or are you actually trying to make a hack? If it's the latter, surely you'll never get there by continuing to switch between disassemblies. All of them will come with some growing pains, but you have to stick with it if you're to get anywhere.
     
  6. experimenting
     
  7. Plorpus

    Plorpus

    Previously Hitlersaurus Christ Member
    818
    152
    43
    I might be asking this in the wrong thread, but does anybody have or know where to find Alberto Robert's model from Sonic 2006? I need it ASAP for a top secret project
     
  8. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    For doing a simple *4 operation, which is faster?

    Code (Text):
    1.  add.w d0,d0
    2.  add.w d0,d0
    or this?
    Code (Text):
    1. lsl.w #2,d0
    Asking because I was looking in the game's main object loop, and it uses two d0 adds instead of the bitshift operation that, in my mind, seems like it would be only a single binary instruction with less math, therefore, at least negligibly faster. Am I off the mark?
     
  9. Dulappy

    Dulappy

    koronesuki Member
    48
    7
    8
    Greece
    sonic
  10. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    Well, yeah. I find that really odd, but thanks for the reference!
     
  11. MarkeyJester

    MarkeyJester

    Time to Grow Up. Resident Jester
    2,121
    246
    43
    Japan
    Modern CPUs use barrel shifter circuitry to perform bit shifting any number of times for the same CPU time.

    The 68k does not, internally the instruction is performing one shift left in a loop, which is why the time decreases as the shift number increases.

    The add instruction is 4 cycles while the shift instruction itself is 6 cycles (with 0 shifting), each shift takes 2 cycles.
     
  12. Cokie

    Cokie

    C. Okie Member
    49
    7
    8
    The sonic games code for scrolling the camera vertically calculate the distance from sonic y and
    the camera y. If sonic is rolling when jumping , it subtracts the difference of
    his rolling and standing height raidus (5px). instead, wouldnt you want to add 5 px to make sonic lower and now 5 pixels
    higher (by subtracting)? Why are they doing this?

    ; ---------------------------------------------------------------------------
    ; Subroutine to scroll the camera vertically
    ; ---------------------------------------------------------------------------

    ; ||||||||||||||| S U B R O U T I N E |||||||||||||||||||||||||||||||||||||||

    ; The upper 16 bits of Camera_Y_pos is the actual Y-pos, the lower ones seem
    ; unused, yet this code goes to a strange extent to manage them.
    ;sub_D77A:
    ScrollVerti:
    moveq #0,d1
    move.w y_pos(a0),d0
    sub.w (a1),d0 ; subtract camera Y pos
    cmpi.w #-$100,(Camera_Min_Y_pos).w ; does the level wrap vertically?
    bne.s .noWrap ; if not, branch
    andi.w #$7FF,d0
    ; loc_D78E:
    .noWrap:
    btst #2,status(a0) ; is the player rolling?
    beq.s .notRolling ; if not, branch
    subq.w #5,d0 ; subtract difference between standing and rolling heights


    Other code adds 5 to sonics y , making him lower as seen below

    @roll:
    bset #status_jump_bit,ost_status(a0)
    move.b #$E,ost_height(a0)
    move.b #7,ost_width(a0)
    move.b #id_Roll,ost_anim(a0) ; use "rolling" animation
    addq.w #5,ost_y_pos(a0)

    My Image shows it sets the radius (w/h) for rolling and lowers sonic 5 pixel after addq.w #5,ost_y_pos(a0)ss

    upload_2022-6-8_17-35-15.png
     
  13. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    Sonic's physical Y position gets pushed down 5 pixels downwards once he enters his ball form to take into account the hitbox size change. The camera code then takes that into account by offsetting that when calculating the camera's Y position. Otherwise, the camera shifts downward as Sonic's position gets shifted when going into ball form, which looks jarring.
     
    Last edited: Jun 9, 2022
  14. Cokie

    Cokie

    C. Okie Member
    49
    7
    8
    I'm misunderstanding something ? I don't see how it fixes the jarring. When sonic goes to ball firm 5 pixels are added to his y moving him down . Then the camera code subtracts 5 pixels just to undo that 5 pixels. The distance from the top of the screen to sonic ( sonic y - sonic y) is additionally subtracted 5 in camera code. So the distance is from sonic y to camera y as if he is standing but he us rolling?
     
    Last edited by a moderator: Jun 12, 2022
  15. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    If the camera did not subtract 5, it would shift down 5 pixels as Sonic's Y position is shifted, which looks weird. It's not obvious when you jump, but it's painfully so when you roll. The camera subtracting 5 offsets the shift and keeps the camera in place. The camera does not actually overwrite Sonic's Y position variable at all. Sonic rolling into a ball, however, is actually physically shifting him down 5 pixels to keep him aligned on the ground when his hitbox size changes.

    Here's what it looks like when the camera doesn't apply that offset:


    All in all, it's just simply the camera moving up a little when Sonic is shifted down, so that it doesn't look odd.
     
    Last edited: Jun 11, 2022
  16. Cokie

    Cokie

    C. Okie Member
    49
    7
    8
    Let me see if i understand it . In case of rolling as you showed in video , the Sonic_Roll code adds 5 px to sonic y shifting him down . then the camera code , code needs to offset this back or otherwise the sonic y would be 5 pixels below ( greater) than the camera y pos bias, causing the camera to move by the difference from sonic y and the camera y pos bias calucated by
    cameraypos = (sonicplayfieldy-cameraplayfieldy) - camerybias + cameraplayfieldy

    Couple related questions

    When on the ground does the camera code strictly use the camera y bias to determine scrolling compared to when jumping it uses top bottom left right borders?

    Is the center for camera y pos bias (0x60 aka 96) not the screens true vertical center (112 PX) because 96 is divisble by tile/block

    After roll code and camera code is running sonic still physically appears standing . has it just not updated drawing and doesn't contradict offsetting sonic y 5 in roll code
     
    Last edited by a moderator: Jun 20, 2022
  17. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    The way the camera works vertically is as follows:

    First it gets Sonic's Y position. Which basically boils down to something like
    Code (Text):
    1. Sonic Y position - (Default hitbox height - Current hitbox height)

    which, like I said, is done to prevent the camera from jittering abruptly on hitbox size changes.

    Then it checks if Sonic is in the air or if he is on the ground:
    • If Sonic is on the ground
      • If the "bias" is not exactly 0x60, meaning that Sonic was looking up or down, scroll towards the shifting "bias" at a max speed of 2 px/frame.
      • Otherwise
        • Get the camera's vertical scroll speed cap in px/frames
          • Set it to 6 if Sonic's ground speed/"inertia" is < 0x800 in either direction.
          • Set it to 16 if Sonic's ground speed/"intertia" is >= 0x800 in either direction.
        • Move the camera towards Sonic.
    • If Sonic is in the air
      • If Sonic is 32 px away from the "bias" in either direction, move the camera towards Sonic at a speed of 16 px/frame.
      • Otherwise
        • If the bottom level boundary is changing, move the camera right at Sonic's Y position (to be honest, probably a side effect due to the code always doing that whenever updating the camera to take into account boundary changes).
        • Otherwise, don't move the camera vertically.
    Boundary checks and level wrapping take place at the end when the camera's Y position is updated.

    So, on the ground, it tries to stay centered at Sonic's Y position, but in the air, Sonic generally has to be 32 px away from that "bias" in order for it to scroll.

    EDIT: Also WOW are bullet points glitchy here.
     
    Last edited: Jun 20, 2022
  18. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    18,822
    703
    93
    Long-term happiness
    Please, please use the edit button if you've just made a post.
     
  19. Cokie

    Cokie

    C. Okie Member
    49
    7
    8
    upload_2022-6-23_20-33-29.png

    I believe I understand it, give me a yes / no if this sounds about right, ( maybe I oversimplify some of it let me know please )

    The image shown shows a red line representing the bias at 96. The transparent yellow box is his bounding
    box, the black dot with white around it is sonic center. and the cyan lines are the two height radius.

    Using Sonic 2 Disasm code, Assuming I pressed the button to roll sonic on the ground (like the video), but before Obj01_DoRoll is called...
    sonic y coordinate variable position is at the black dot of the left picture. After Obj01_DoRol moves his y 5 pixels down ,
    sonic y coordinate position is as shown at the black dot of the right picture. Left picture has him at the camera y pos bias
    and the right picture has him 5 pixel below to align him with the floor as he goes in the ball. When ScrollVerti is called,
    since it sees sonic is rolling, it needs to subtract 5 to the temporary d0 register storing sonic local coordinate (sonicy - cameray),
    before ScrollVerti calcualtes how far sonic moved from bias . Otherwise if we didn't, it will think sonic moved 5 pixels, below the
    camera y bias,consquently moving the camera down to adjust. Am I understanding it correctly?

    Thanks for everything!
     
  20. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    Yup, that's basically how it goes.