don't click here

Basic Questions & Answers thread

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

  1. MarkeyJester

    MarkeyJester

    Time to Grow Up. Resident Jester
    2,121
    246
    43
    Japan
    Underneith the crushers, in the floor, is an object which kills the player if they are touching the top/bottom of it. It's there because the crusher pushes Sonic through the floor instead of actually killing him.

    The floors in Marble Garden Zone are not flat, they ramp up and down. Under some of the crushers the floor is such that it ramps down just before ramping up where the crusher is. If Sonic is moving fast enough, he can be "technically" inside the ground because of the down ramp, and next frame, the collision system will put him on top of the up ramp floor so you don't actually see him inside it. Unfortunately, he can touch the killing object before that happens.
     
    • Informative Informative x 1
    • Useful Useful x 1
    • List
  2. Nik Pi

    Nik Pi

    Member
    How can I edit sprites for Sonic 1 PC decomp? I try to edit it in MSPaint- FAIL! Ok, it compress image, but I try to edit in Paint.NET, and it not compress my gif, but game still show random graphics instead of what is needed
     
  3. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    I personally use GraphicsGale.
     
  4. Nik Pi

    Nik Pi

    Member
    Thank you! I'll try it
     
  5. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    I should mention the reason why MS Paint and Paint.NET won't work is because RSDK actually utilizes the palette/color indicies in the image data itself. Resaving in either of those will mess it up.
     
  6. RDNexus

    RDNexus

    Member
    Given the latest progress in extracting stuff from Saturn games, does anyone know if anyone's tried to mod assets from Sonic 3D Saturn to the PC port?
     
  7. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,648
    214
    43
    SonLVL
    I managed to decode the sprite format, to some extent. Haven't tried to inject new ones. There's a Discord for Sonic 3D Blast modding, but it's pretty quiet most of the time.
     
  8. RDNexus

    RDNexus

    Member
    You have a link to that server? It'd be mainly to my brother.
    He was searching for potential Saturn mods to PC Sonic 3D.
     
  9. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,648
    214
    43
    SonLVL
    Here: https://discord.gg/R2ndqjhgXZ

    I don't know that there's ever going to be any kind of Saturn restoration mod though, considering that the Special Stage would take an enormous amount of work to port, and I don't know how any of the other missing effects would work.
     
  10. RDNexus

    RDNexus

    Member
    Not sure if I can ask it here...
    Anyone knows if S2HD is still under development?
    If there's been progress in the game's completion.
     
  11. Nik Pi

    Nik Pi

    Member
    Exists any way to "emulate" lock-on technology, or something? I need to test compatibility of my Sonic 3 and Sonic and Knuckles modifications..
     
  12. Devon

    Devon

    There's nothing left but faith Tech Member
    865
    600
    93
    Lock-on technology just maps the locked on ROM to the $200000-$3FFFFF region in ROM space.

    Couple notes on that, though:
    • The latter 2 MB of the ROM is locked on. ROMs <= 2 MB are mirrored, which makes it visible in latter 2 MB region. Otherwise, larger ROMs will have their data located at $200000 and above mapped.
    • The Knuckles in Sonic 2 UPMEM is mapped to $300000-$3FFFFF if you set the SRAM enable flag.
    So, to "emulate" it, if the ROM is <= 2 MB, you can just take a Sonic & Knuckles ROM, and append the ROM at $200000 via a hex editor. If the ROM is > 2 MB, then you take the data at $200000 in the source ROM and copy it to $200000 in the S&K ROM. To "emulate" Knuckles in Sonic 2, you also take the UPMEM and copy it to $300000 in the S&K ROM. Genesis Plus GX also natively can automatically map the ROMs.

    Just some examples to help illustrate my point:

    [​IMG]

    [​IMG]

    [​IMG]
     
    Last edited: Oct 27, 2022
  13. Overlord

    Overlord

    Now playable in Smash Bros Ultimate Moderator
    18,821
    701
    93
    Long-term happiness
    copy /b sonic3.bin sk.bin sonic3k.bin

    Just run that on a Windows command line.
     
    • Like Like x 3
    • Agree Agree x 1
    • List
  14. Alex Field

    Alex Field

    シュート! カオス・エメラルド・ザが消えようとしている! Member
    Bringing up a bizarre bug with my Simon Wai disassembly; for whatever reason, the palette cycles have a chance to corrupt randomly (mainly after the player takes damage and then exits to a new level), and this bug ONLY occurred when moving it to AS. Is this an AS-specific bug, or something else?

    https://github.com/AlexField442/Sonic-2-Simon-Wai-Disassembly
     
  15. Oh boy... I took a look at both the final ASM68K-based commit and the first AS-based one, and while I can't confirm that this is the cause of the problem, there is a deep-rooted issue with the disassembly that, combined with a particular behavior difference between ASM68K and AS, might be a factor.

    The disassembly has tons of bsr, bra, and conditional branch instructions without length attributes, as well as a number of lea instructions, including every instance in the palette-cycling routines, whose source operands lack length attributes. If the goal is bit-perfectness, this is a recipe for disaster, since the two assemblers handle these very differently: for branches, ASM68K always treats these as word length, while AS will optimize them to short on the second pass if possible; for leas, ASM68K appears to treat these as absolute long, but AS optimizes them to words if possible. These two differences alone are causing the two builds to differ significantly: my hex editor found 5429 differences between the two commits! I don't think these optimizations would cause problems, but you never know...

    Code (Motorola 68000 Assembler):
    1.  
    2. lea     (Pal_GHzCyc),a0 ; For this, ASM68K would produce the following: $41F9, $0000, $xxxx...
    3. lea     (Pal_GHzCyc),a0 ; ...but AS on the other hand produces this: $41F8, $xxxx
    4. lea     (Pal_GHzCyc)l.,a0 ; forcing absolute long produces the intended result in both: $41F9, $0000, $xxxx...
    5.  
    Before anything else, I would try correcting the lea instructions in the palette cycling routines so that they are absolute long instead of word. Longer-term, might be a good idea to use the listing file from the final ASM68K build to find and fix all of the branches, jumps, and leas without lengths, and address any other issues needed to get things building to the correct offsets again (that is, the offsets in the left column of the listing file match the IDA-generated labels; bit-perfect is a completely different story).
     
    Last edited: Oct 28, 2022
  16. Alex Field

    Alex Field

    シュート! カオス・エメラルド・ザが消えようとしている! Member
    Thanks for the information (although you wrote (Pal_GHzCyc)l.,a0 incorrectly); I also wouldn't be surprised if this is why the Special Stages also crash in the AS version, but not the ASM68K. Looks like my next update will just be fixing this.

    EDIT: Tried replacing all bsr/bra with .w and "lea (xxx)" with "lea (xxx).l", but it didn't fix the issue; at least it's closer to the original ROM?
     
    Last edited: Oct 29, 2022
  17. That the palette issue was not related to the instruction length issue was not too much of a surprise, but nevertheless it is much closer to the original ROM. Still needs some more work to get bit perfect, but that is something I could easily help with (spent several hours getting my yet-to-be-released Sonic 2 ASM68K disasm bit-perfect after the first successful build).
     
  18. Alex Field

    Alex Field

    シュート! カオス・エメラルド・ザが消えようとしている! Member
     
  19. Have my own fork set up and am working on it. :>
     
    Last edited: Oct 30, 2022
  20. XPointZPoint

    XPointZPoint

    That's no good! Member
    47
    13
    8
    (EDIT) Imma just start over from scratch.

    Heyo! I was working on a rom hack and I added a SEGA jingle that is using SMPS and not PCM format. While building, unfortunate things happened. No matter what I did, it would always build with
    Code (Text):
    1. J:
    2. J:\S1SPINDASHASM\SONIC1.ASM(39018) : Warning : Instruction has been word aligned
    3.  move.w #$100,($a11100).l
    4. J:\S1SPINDASHASM\SONIC1.ASM(39035) : Warning : Branch to odd address
    5.  bra.s sub_71b4c
    6. Errors during pass 1 - pass 2 aborted
    7. Assembly completed.
    8. 1 error(s) from 48235 lines in 0.17 seconds
    9.  
    10. Reported Size:  100303C Reported Checksum:    0
    11.  Size applied: FFFFFFFF  Checksum
    When this happens, the rom doesn't work.

    and the code in question?

    Code (Text):
    1. ; ---------------------------------------------------------------------------
    2. ; Music    Pointers
    3. ; ---------------------------------------------------------------------------
    4. MusicIndex:    dc.l Music81, Music82
    5.         dc.l Music83, Music84
    6.         dc.l Music85, Music86
    7.         dc.l Music87, Music88
    8.         dc.l Music89, Music8A
    9.         dc.l Music8B, Music8C
    10.         dc.l Music8D, Music8E
    11.         dc.l Music8F, Music90
    12.         dc.l Music91, Music92
    13.         dc.l Music93, Music94
    14. ; ---------------------------------------------------------------------------
    15. ; Type of sound    being played ($90 = music; $70 = normal    sound effect)
    16. ; ---------------------------------------------------------------------------
    17. SoundTypes:    dc.b $90, $90, $90, $90, $90, $90, $90,    $90, $90, $90, $90, $90, $90, $90, $90,    $90
    18.         dc.b $90, $90, $90, $90, $90, $90, $90,    $90, $90, $90, $90, $90, $90, $90, $90,    $80
    19.         dc.b $70, $70, $70, $70, $70, $70, $70,    $70, $70, $68, $70, $70, $70, $60, $70,    $70
    20.         dc.b $60, $70, $60, $70, $70, $70, $70,    $70, $70, $70, $70, $70, $70, $70, $7F,    $60
    21.         dc.b $70, $70, $70, $70, $70, $70, $70,    $70, $70, $70, $70, $70, $70, $70, $70,    $80
    22.         dc.b $80, $80, $80, $80, $80, $80, $80,    $80, $80, $80, $80, $80, $80, $80, $80, $80,    $90
    23.         dc.b $90,$90,$90,$90, $90                                               ; $E0
    24.  
    25.  
    26. ; ||||||||||||||| S U B    R O U T    I N E |||||||||||||||||||||||||||||||||||||||
    27.  
    28.  
    29. sub_71B4C:                ; XREF: loc_B10; PalToCRAM
    30.         move.w    #$100,($A11100).l ; stop the Z80
    31.         nop  
    32.         nop  
    33.         nop  
    34.  
    35. loc_71B5A:
    36.         btst    #0,($A11100).l
    37.         bne.s    loc_71B5A
    38.  
    39.         btst    #7,($A01FFD).l
    40.         beq.s    loc_71B82
    41.         move.w    #0,($A11100).l    ; start    the Z80
    42.         nop  
    43.         nop  
    44.         nop  
    45.         nop  
    46.         nop  
    47.         bra.s    sub_71B4C
    48. ; ===========================================================================
    Can someone help me out as to what I'm doing wrong? Note I have the spindash implemented and that seems to corrupt everything. A video demonstrating:
     
    Last edited: Oct 30, 2022