Basic Questions and Answers Thread

Discussion in 'Discussion & Q&A' started by Malevolence, Jul 7, 2009.

  1. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    Like I said, that doesn't need to be there anymore. You deleted its code.
     
  2. brickrick

    brickrick Active Member Member

    Joined:
    Apr 30, 2012
    Messages:
    33
    Like I said, that doesn't need to be there anymore. You deleted its code.




    Oh sorry, I just wanted to make sure... I got confused. ^^


    ). About ${paddingSoFar} bytes are padding. "
    endif
    ; share these symbols externally (WARNING: don't rename, move or remove these labels!)
    shared word_728C_user,Obj5F_MapUnc_7240,off_3A294,MapRUnc_Sonic,movewZ80CompSize
    EndOfRom:
    END


    So I removed the label at the end there and: no errors now! It build the ROM. I might dance if everything is ok. Thank you for all the help. I will report (edit) the results. :)

    (by the way, I should probably have mentioned that I moved the Nemesis art that was in the middle of the previous sound driver and stuffed them next to the other Nemesis art code bits... but that's for another time! ^^)

    EDIT: I could have reported the results sooner, so sorry for that, but I was busy dancing. :D

    Thank you Clownancy, for the guidance, and also thanks to Kram1024 for making the tutorial. Although there are some minor bugs here and there, but I will not bother with them (at least for now) because, overall, I can now say that the sound driver has been successfully ported. I am really glad I'm moved away from S3K to Sonic 2, it seems I might be able to do more than just hexing random objects. :)

    I am going to make a playthrough of the ROM and a log with all the issues I may find. Maybe it will be useful to refine the code, I don't know, this is just me babbling now. Anyway, thank you again!

    EDIT2: I am being able to make fixes/workarounds to some of the bugs (I am really amazed with ASM's capabilities now, considering my ignorance/"noobism") and if it is worth it, I will contact (someone/staff/you?) for directions about publishing said fixes. I have another question regarding ASM, but I will leave room for other people now. In the meantime, I will check other tutorials too, art editing I guess. Cheers!
     
    Last edited by a moderator: Mar 29, 2015
  3. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    When applying SBZ 2's post-signpost code to a level, the camera will slow down once Sonic starts running too fast, making Sonic run off-screen. Is there anyway to stop this and make the camera act like it would normally?

    Edit: Another question: Is there a simple way to check if Sonic is touching the ground? I'm using the Hivebrain Project 128 disassembly.
     
    Last edited by a moderator: Mar 31, 2015
  4. Selbi

    Selbi The Euphonic Mess Member

    Joined:
    Jul 20, 2008
    Messages:
    2,429
    Location:
    Northern Germany
    Yes, you just gotta check if the "in-air" bit is not set:

    Code:
    		btst	#1,$22(a0)	; is Sonic's in-air flag set?
    		beq.s	SomeLabel	; if not, branch
    		bne.s	SomeOtherLabel	; if yes, branch
     
  5. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    Will this work in the code for a different object?
     
  6. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    I bring this up for the third or fourth time.
     
    Regular Status bitfield

    Bit  Hex  Description

    0  $01  X Orientation. Clear is left and set is right.
    1  $02  Y Orientation. Clear is right-side up, and set is upside-down
    2  $04  Unknown or unused
    3  $08  Set if Sonic is standing on this object.
    4  $10  Unknown or unused
    5  $20  Set if Sonic is pushing on this object.
    6  $40  Unknown or unused
    7  $80  Unknown or unused
     
    Sonic's Status bitfield

    Bit  Hex  Description

    0  $01  Orientation. Clear is left and set is right.
    1  $02  Set if Sonic is in the air (jump counts).
    2  $04  Set if jumping or rolling.
    3  $08  Set if Sonic isn't on the ground but shouldn't fall. (Usually when he is on a object that should stop him falling, like a platform or a bridge.)
    4  $10  Set if jumping after rolling.
    5  $20  Set if pushing something.
    6  $40  Set if underwater.
    7  $80  Unused.
     
    As you can see, only Sonic has this variable, meaning Selbi's method will not work on other objects, as the code will check their 'Y-orientation' bit instead.
     
  7. brickrick

    brickrick Active Member Member

    Joined:
    Apr 30, 2012
    Messages:
    33
    Excuse for jumping in again. I just need clarification on some things before I can go back to my cave and start juggling with the code like a mad man. I am pretty sure these are really basic/fundamental concepts, but I'd rather show my ignorance and have answers than the opposite (or something like that ^^). My doubts are all about the ROM building process, and how changing data in the ASM files affects the actual hex data. Firstly, about the builder's output (cmd) window:


    s2.macros.asm<219>
    misc/obj1E_a.asm<360>
    misc/obj1E_b.asm<134>
    misc/obj67.asm<120>
    ROM size is $200000 bytes <2048 kb>. About $D38CF bytes are padding.
    s2.asm<89327>
    PASS 3

    #1: What does "padding" mean here? Are the "padding bytes" just the amount of free space or is there something wrong with the ROM? (which has 2048 kb after porting S3's Sound Driver btw).

    #2: About text formating in the ASM: Does the builder differentiate "tabs" from spaces? I am using wordpad, so I am hesitating a little more because of this doubt. And also for the possibility of making a small 3rd party application (for coding support purposes) in Flash, which does not allow "tabs" in the text boxes.

    And #3: This is the most baffling to me, which is: Does the builder reorganize the pointers? What I mean is: imagine you move a chunk of code to another place. (I actually did this when porting the Sound Driver: there was Nemesis Art in the middle of a section to remove. The guide did not say how to move it and I just copy/pasted it next to some other Nemesis Art. Turns out the objects were working fine. How?) Or if you add code to an object: If it were hex, one could not add bytes unless a pointer were used (to some free space) or else it would overwrite data, right? But I am "feeling" that with ASM it is different. Am I making any sense here? ... Basically, to what extent can I move/add/remove code without overwriting other data? And how do I know that?

    Sorry for the needlessly long post, but I am eager to know these. >:D

    EDIT: punctuation, plus (where are my manners?): pretty please? =D
     
    Last edited by a moderator: Mar 31, 2015
  8. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    1. Yes, that is the number of unused bytes in the assembled ROM that ensure certain data lines up at certain places, via the 'even', 'align', 'org', or 'cnop' macros (see s2.macrosetup.asm).

    2. Tabs and spaces are completely interchangeable.

    3. Any time you see reference to a label, such as 'jsr (PlayMusic).l' or 'dc.l Obj01', the assembler will automatically adjust the generated code to point to the correct location (or generate a warning if the instruction's addressing mode can't reach the label). Essentially, you can put anything anywhere, as long as the ROM header is at the start, though you may have to change some instructions if the label they point to moves too far away.
     
    Last edited by a moderator: Mar 31, 2015
  9. brickrick

    brickrick Active Member Member

    Joined:
    Apr 30, 2012
    Messages:
    33
    Wow, it really is that flexible... this is amazing! Thank you for the explanation, MainMemory. =)

    That will be it for now. =D
     
  10. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    Sonic's Status bitfield

    Bit  Hex  Description


    0  $01  Orientation. Clear is left and set is right.


    1  $02  Set if Sonic is in the air (jump counts).


    2  $04  Set if jumping or rolling.


    3  $08  Set if Sonic isn't on the ground but shouldn't fall. (Usually when he is on a object that should stop him falling, like a platform or a bridge.)


    4  $10  Set if jumping after rolling.


    5  $20  Set if pushing something.


    6  $40  Set if underwater.


    7  $80  Unused.


    As you can see, only Sonic has this variable, meaning Selbi's method will not work on other objects, as the code will check their 'Y-orientation' bit instead.



    Just to clarify, I meant putting the check for Sonic being in the air in the code for a different object. For example, if I wanted the motobug to move quicker if Sonic was on the ground. I'm sorry if you thought I meant that I wanted to check if the object I was editing was in the air.
     
  11. Selbi

    Selbi The Euphonic Mess Member

    Joined:
    Jul 20, 2008
    Messages:
    2,429
    Location:
    Northern Germany
    In that case, you can directly check for that bit in the RAM. Sonic's $40 object definition is starting at $FFFFD000. This works universally at any point in the game.

    Therefore, what you can do is this:

    Code:
    		btst	#1,($FFFFD022).w	; is Sonic's in-air flag set?
    		beq.s	SomeLabel		; if not, branch
    		bne.s	SomeOtherLabel		; if yes, branch
     
    Last edited by a moderator: Apr 1, 2015
  12. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    Thanks, Selbi, this works exactly as I want it to.

    And now about my first question:

    Does anybody know a solution to this?
     
  13. tilk

    tilk Active Member Member

    Joined:
    Feb 2, 2012
    Messages:
    30
    Hi!
    So I was looking to this guide this guide, and I wonder: How I can aplly the optimized "object_move" to the "boss_move" Routine? (Yes, those 2 Sonic 2 routines exists in Sonic 1, with a different name...)


    BossMove:
            move.l    $30(a0),d2
            move.l    $38(a0),d3
            move.w    obVelX(a0),d0
            ext.l    d0
            asl.l    #8,d0
            add.l    d0,d2
            move.w    obVelY(a0),d0
            ext.l    d0
            asl.l    #8,d0
            add.l    d0,d3
            move.l    d2,$30(a0)
            move.l    d3,$38(a0)
            rts
    ; End of function BossMove
    Also, a question about the kraminator Disassembly: It's the collision compresed? If so, where I can find the routine? (want to apply a guide that I saw to have it uncompressed, if it is.)

    Thanks beforehand! ^_^
     
  14. Pokepunch

    Pokepunch That guy who posts on occasion Member

    Joined:
    Aug 7, 2009
    Messages:
    270
    Location:
    UK
    In that guide redhotsonic shows ObjectMove:


    move.l x_pos(a0),d2 ; load x position
    move.l y_pos(a0),d3 ; load y position
    move.w x_vel(a0),d0 ; load horizontal speed
    ext.l d0
    asl.l #8,d0 ; shift velocity to line up with the middle 16 bits of the 32-bit position
    add.l d0,d2 ; add to x-axis position ; note this affects the subpixel position objoff_A(a0) = 2+x_pos(a0)
    move.w y_vel(a0),d0 ; load vertical speed
    ext.l d0
    asl.l #8,d0 ; shift velocity to line up with the middle 16 bits of the 32-bit position
    add.l d0,d3 ; add to y-axis position ; note this affects the subpixel position objoff_E(a0) = 2+y_pos(a0)
    move.l d2,x_pos(a0) ; update x-axis position
    move.l d3,y_pos(a0) ; update y-axis position
    rts

    If you compare your BossMove to this you can see that they are practically the same, the only difference is the equates:


    x_pos = $30
    y_pos = $38
    x_vel = obVelX
    y_vel = obVelY

    Use this table to help you make the optimized code usable in your disassembly, here is the first line for example:


    move.w x_vel(a0),d0 
    From the table you know that x_vel = obVelX, so change the x_vel to obVelX

    Code:
           move.w  obVelX(a0),d0
    
     
  15. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    http://info.sonicretro.org/Project_Sonic_1:_Two-Eight#Kram1024_Fork

    If you look at the section on porting from Sonic 2, you'll see that the collision needs to be uncompressed.


    But... why would you want to follow that guide? The 128 modification already frees up a large amount of RAM (the chunk table is reduced to $8000 bytes from $A400, freeing $2400). Other parts of the modification may use some of it, but there's no way all of it's been used.
     
    Last edited by a moderator: Apr 2, 2015
  16. tilk

    tilk Active Member Member

    Joined:
    Feb 2, 2012
    Messages:
    30
    thank you! with some small changes, I've added this to the HG disassembly. Here's the Output for anyone interested in applying this Speed up to his hack:


    ; ---------------------------------------------------------------------------
    ; Subroutine to move a boss
    ; ---------------------------------------------------------------------------

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

    BossMove:
            move.w    obVelX(a0),d0
            ext.l     d0
            lsl.l     #8,d0
            add.l     d0,boss_VelX(a0)
            move.w    obVelY(a0),d0
            ext.l     d0
            lsl.l     #8,d0
            add.l     d0,boss_VelY(a0)
            rts
    ; End of function BossMove
    And don't forget to declare this in the constants:

    Code:
    boss_PosX:	equ $30	; x-axis position (2 bytes)
    boss_PosY:	equ $38	; y-axis position (2 bytes)
    
     
    Last edited by a moderator: Apr 2, 2015
  17. tilk

    tilk Active Member Member

    Joined:
    Feb 2, 2012
    Messages:
    30
    http://info.sonicretro.org/Project_Sonic_1:_Two-Eight#Kram1024_Fork

    If you look at the section on porting from Sonic 2, you'll see that the collision needs to be uncompressed.


    But... why would you want to follow that guide? The 128 modification already frees up a large amount of RAM (the chunk table is reduced to $8000 bytes from $A400, freeing $2400). Other parts of the modification may use some of it, but there's no way all of it's been used.



    Right, you're alright. To be precise, $1C08 bytes of ram. (Did the calculation by AA00-408+(200+400) the result of this was rested to C800, and gave me the exact ammount of Ram.)
     
  18. Pokepunch

    Pokepunch That guy who posts on occasion Member

    Joined:
    Aug 7, 2009
    Messages:
    270
    Location:
    UK
    $30 and $38 are not related to velocity and are to do with an objects position, they are also not limited to bosses and are used by most objects. You'd be better off naming them obPosX and obPosY.
     
    Last edited by a moderator: Apr 2, 2015
  19. tilk

    tilk Active Member Member

    Joined:
    Feb 2, 2012
    Messages:
    30
    renamed. ;) The code itself works perfectly...
     
  20. tilk

    tilk Active Member Member

    Joined:
    Feb 2, 2012
    Messages:
    30
    By the way! How I can use water in every level? I'm currently looking for implementing it in some levels...
     
    Last edited by a moderator: Apr 2, 2015