Basic Questions and Answers Thread

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

  1. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    802
    Location:
    Portland, Maine
    Typing "illegal" on a line will crash the game when it gets to that point, so you can just do this:
    Code:
    LevSel_Level:                ; XREF: LevSel_Level_SS
            andi.w    #$3FFF,d0
            move.w    d0,($FFFFFE10).w ; set level number
            cmp.b     #1,($FFFFFE10).w
            beq.s      CrashLevel
    
    PlayLevel:                ; XREF: ROM:00003246j ...
            move.b    #$C,($FFFFF600).w ; set    screen mode to $0C (level)
            move.b    #3,($FFFFFE12).w ; set lives to    3
            moveq    #0,d0
            move.w    d0,($FFFFFE20).w ; clear rings
            move.l    d0,($FFFFFE22).w ; clear time
            move.l    d0,($FFFFFE26).w ; clear score
            move.b    d0,($FFFFFE16).w ; clear special stage number
            move.b    d0,($FFFFFE57).w ; clear emeralds
            move.l    d0,($FFFFFE58).w ; clear emeralds
            move.l    d0,($FFFFFE5C).w ; clear emeralds
            move.b    d0,($FFFFFE18).w ; clear continues
            move.b    #$E0,d0
            bsr.w    PlaySound_Special ; fade out music
            rts   
    
    CrashLevel:
            illegal
    It's probably better to just have it do nothing, though. I don't see any reason to force players to restart just because they are feeling curious.
     
  2. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    802
    Location:
    Portland, Maine
    Now that I think about it, they don't exactly stall, they just take longer to process than the game has to create a frame. The problem is definitely coming from the game having everything it needs loaded during that frame.

    Your method is pretty efficient. I've done it by modifying the initial level code and I didn't run into that problem. It probably won't help the issue, but you should probably clear some variables for objects and stuff when a normal level is loaded to prevent possible issues. I'd guess that Screen_redraw_flag could be contributing to the issue because I didn't need to use it, so it may not be right for the situation. You may need a different subroutine in its place. After looking through what I did and what removing certain branches to subroutines did, I couldn't come to a conclusion of what exactly it could be. Hopefully someone who better understands how the game loads stuff can help.
     
    Pokepunch likes this.
  3. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    870
    IIRC, refreshing the entire screen like that takes more than one frame to complete, which is why S3K takes special care to ensure that all act transitions take place in areas that are identical in both acts, and where the background is hidden, so it doesn't have to redraw anything.
     
  4. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    704
    Location:
    Long and dangerous river
    One of the important issues here, from what I can gather, is that the camera moves. More specifically, the plane does. The camera view, even if the same on both ends, are at different points of the plane vertically and horizontally. Therefore, a redraw is required after camera is moved, which unless can be completed in the same frame (most likely not), it will produce a glitch effect where the plane has failed to redraw. Like MainMemory said, S3K does this very carefully, and without moving the camera at all. Since the camera does not move, the game only has to ensure that the areas right outside of the screen are updated correctly, so the camera and move freely. In theory this is unnecessary for the foreground too, but really does not hurt either. What I can suggest is, always ending the level so that the camera is at the same region inside of the plane, so if the screen ends at $1FE0 $222, the new level could start at, for example, $01E0 $122. This is the same offset in the plane, and therefore does not require the foreground to be redrawn, as long as the chunks are the same. The plane is 512 pixels (AND $1FF) horizontally, and 256 (AND $0FF) vertically. Of course, you must ensure the panning of the camera stays consistent. If the level bottom is at $1F0, the new level bottom should be at $F0.
     
    ProjectFM, Pokepunch and AkumaYin like this.
  5. Pokepunch

    Pokepunch That guy who posts on occasion Member

    Joined:
    Aug 7, 2009
    Messages:
    270
    Location:
    UK
    Thank you everyone! That information about the plane locations solved the problem I was having and the transitions work perfectly now.
     
    maple_t, Trickster and Natsumi like this.
  6. Iso Kilo

    Iso Kilo Sonic 1 Beta Researcher Member

    Joined:
    Oct 9, 2017
    Messages:
    176
    Location:
    Small Town in BC, Canada
    So, I've been trying to reimplement that 'standing breathe' animation in S1. However it doesn't seem to work. I think it has to do with the time in which the bubble can be collected, but I'm not sure. Here's a look at what I have set up, at the moment it acts like default Sonic 1.
    Code:
    ;(Obj64_Wobble)
    Bubble_AniChk:
            cmpi.b    #$20,$22(a0)
            beq.s    Stand_Breathe
            move.b    #$15,$1C(a1)
            bra.s    Breathe_Cont
    Stand_Breathe:
            move.b    #$20,$1C(a1)
    Breathe_Cont:
     
  7. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    802
    Location:
    Portland, Maine
    $22(a0) is worked with as a series of 8 bits rather than a single byte. Your code will only work if the bubble object itself (a0) is facing right, right-side up, Sonic isn't standing on it, Sonic is pushing on it, and the other bits aren't set. Assuming you want it to work while Sonic is pushing on it, you'd have to go with:
    Code:
    ;(Obj64_Wobble)
    Bubble_AniChk:
            btst    #5,$22(a0)
            bne.s    Stand_Breathe
            move.b    #$15,$1C(a1)
            bra.s    Breathe_Cont
    Stand_Breathe:
            move.b    #$20,$1C(a1)
    Breathe_Cont:
    It checks if only the pushing bit is zero, then does the new animation if it isn't.
     
  8. Iso Kilo

    Iso Kilo Sonic 1 Beta Researcher Member

    Joined:
    Oct 9, 2017
    Messages:
    176
    Location:
    Small Town in BC, Canada
    Gave it a shot, still acts like default S1. What my check was trying to do was see if the player was jumping, if they were it'd play the normal animation. Though it's possible that I also needed the underwater bit added to it too.
     
  9. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    802
    Location:
    Portland, Maine
    I wasn't sure what the conditions were supposed to be, so thanks for clearing that up.

    In this case, you should do this:
    Code:
    ;(Obj64_Wobble)
    Bubble_AniChk:
           btst    #1,$22(a1)
           bne.s    Stand_Breathe
           move.b    #$15,$1C(a1)
           bra.s    Breathe_Cont
    Stand_Breathe:
           move.b    #$20,$1C(a1)
    Breathe_Cont:
    
    (a0) points to the bubble object's SSTs (a series of variables specific to that object) while (a1) points to Sonic's. Bit 1 is only set if Sonic is in the air. If he needs to be jumping to trigger the animation then you'd have to check bit 2 also.
     
  10. Iso Kilo

    Iso Kilo Sonic 1 Beta Researcher Member

    Joined:
    Oct 9, 2017
    Messages:
    176
    Location:
    Small Town in BC, Canada
    Close, it now does the opposite. Should be as simple as changing the bne.s to a beq.s.
     
  11. EMK-20218

    EMK-20218 Okie dokie, name is back Member

    Joined:
    Aug 8, 2008
    Messages:
    1,041
    Location:
    Jardim Capelinha, São Paulo
    Guys, someone experienced enough please help me.
    I'm trying to work in a palette cycle routine, but the compiler is returning me a ILLEGAL VALUE error in this code here:
    Code:
       moveq #0,d0 ; limpa d0 move.b ($FFFFF632).w,d0 ; move um valor de cor pra d0
       add.b #$2,($FFFFF632).w ; adicionar 2 no timer
       move.w Cycle_PlacaNEON(pc,d0.w),($FFFFFB60+$1E).w ; carrega a cor no ultimo slot de cores da ram
       cmpi.b #$8,($FFFFF632).w ; compara se o timer chegou no fim bne.s NaoChegou ; se não, ir pra essa rotina
       move.b #$00,($FFFFF632).w ; se chegou, limpar
    NaoChegou:
       rts
    
    And the error is in this line specifically:
    move.w Cycle_PlacaNEON(pc,d0.w),($FFFFFB60+$1E).w

    What would be wrong on this for it to not to compile?

    -

    EDIT: It was just a distance range error. Jorge did already help me with this. I solved the problem thanks to his help in the SSR Discord chat. In case the answer gets to be posted here too, thanks anyway!
     
    Last edited: Apr 19, 2019
  12. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    704
    Location:
    Long and dangerous river
    Cycle_PlacaNEON is too far away from the line using it. Try moving it right below that rts.
     
    EMK-20218 likes this.
  13. Trickster

    Trickster Previously called Megalomania Member

    Joined:
    Aug 22, 2018
    Messages:
    81
    Location:
    Brazil Bad Future
    What's the best size for chunks?

    upload_2019-4-22_19-43-57.png upload_2019-4-22_19-44-48.png
    256 x 256, Or 128 x 128?

    In my case, I prefer the larger size, since there's more space to make me able to produce lots of visual, with few repetitions.
    I'm focusing in making the level art visually varied, like Sonic CD.
    Also, 256 x 256 technically means chunk quantity multiplied, but locked in pattern of 4 per 4.
    Anyway, I need some advices, I'm a newbie. :^P
    I also need to even know how to change the size, but well, I'll think about this later.​
     
    Last edited: Apr 23, 2019
    ProjectFM likes this.
  14. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    802
    Location:
    Portland, Maine
    128x128 all the way. The chunks themselves will look less repetitive, but the layouts will end up being more repetitve due to the smaller number of chunks to work with. I believe there is a way to use $FF 256x256 chunks, so if you're willing to add in that, you could try it out, but I'd still say go with 128x128 chunks.

    Think of it like this: for every one 256x256 chunk, there are 256^4 ways four 128x128 chunks can take its place. It allows for a lot of flexibility while still being very managable to work with.
     
    Last edited: Apr 23, 2019
    Ralakimia, Trickster and Natsumi like this.
  15. Trickster

    Trickster Previously called Megalomania Member

    Joined:
    Aug 22, 2018
    Messages:
    81
    Location:
    Brazil Bad Future
    So, if I would put the larger size, It would be required gimmicks such as different chunkset per act? or even more?
     
  16. Ralakimia

    Ralakimia Pour your misery down on me Member

    Joined:
    Aug 26, 2013
    Messages:
    988
    The process would include modifying the level renderer, collision engine, or really anything else that uses layout and chunk data to account for the new chunk size (you'd have to change how it locates a chunk and how it also locates a block within a chunk for each), and also updating the level data to handle the new chunk size. The actual ASM work SHOULD be just be a matter of changing the math in converting a pixel position to layout/chunk offset.

    There does exist a version of the Sonic 1 disassembly called "Project 1 Two Eight" which already has the smaller chunk size implemented and ready to use, alongside pathswappers like in Sonic 2/3K, instead of Sonic 1's awfully limited chunk swap list.
     
  17. Tanman Tanner

    Tanman Tanner Well-Known Member Member

    Joined:
    Dec 23, 2016
    Messages:
    70
    Location:
    Buffalo, New York
    I have a question regarding the Z80 Sound Driver in the Sonic 3 & Knuckles GitHub disassembly.
    How would you make it support _smps2asm_inc.asm, similar to Flamewings S3K Sound Driver?
     
    Last edited: Apr 28, 2019
  18. Greenknight9000

    Greenknight9000 Well-Known Member Member

    Joined:
    Apr 30, 2014
    Messages:
    53
    Hello everyone, I'm doing a side-project on me practicing Sonic 1 ASM hacking and whatnot, and the one thing I STILL can't manage is porting Super Sonic in the game, there only tutorial is the one on Sonic Retro that's EXTREMELY outdated and unfinished, I've asked this question on this thread many times but it always ends to a deadend, hopefully third time's the charm and I need someone who's willing to help me out here, I've seem to have been more comfortable with Sonic 2's code, with me able to add things in the game (with a little help of course), but Sonic 1's code is a little more difficult and is confusing as all hell.
    As much as I'd love to just copy-and-paste code and stuff in, I suppose it wouldn't hurt to at least have a few attempts to question/work things out with a bit of assistance.

    I'm going to start from scratch with a new unmodified Sonic 1 ASM file, and work from there.
     
  19. RyeBread

    RyeBread Well-Known Member Member

    Joined:
    May 10, 2013
    Messages:
    155
    Location:
    Devon, UK
    So, beginner question, but I'm assuming it's a quick fix or a simple mistake;

    I'm toying around with SMPS for the first time using Mid2SMPS and the midi drivers for FL.
    The songs I make work fine in Sonic 1, but after trying to import a Sonic 2 boss theme into Sonic 2, this error popped up.
    upload_2019-5-7_0-48-10.png
    I, uh, can't really tell what it means. Google didn't help as it doesn't usually with Sonic hacking.
     
  20. Tanman Tanner

    Tanman Tanner Well-Known Member Member

    Joined:
    Dec 23, 2016
    Messages:
    70
    Location:
    Buffalo, New York
    The bank is filled up to its limit, and simply the compiler refuses to let you compile if that's the case. Make another bank and put the songs that are pushing it over in this new bank.
    Sonic 1 doesn't use an anally specific sized bank system like Sonic 2 & 3, so it doesn't matter how large the music is, compared to S2&3, where if it's too large, it spills out, so to speak.
    Sonic 2&3 uses startBank and finishBank to define where banks start and end.
    It'd look like something like this (pseudo-ish):
    Code:
    Bank1: startBank
    ASong: "a.bin"
    BSong: "b.bin"
    ;CSong: "c.bin" ; this is too big
    finishBank
    
    Bank2: startBank
    CSong: "c.bin"
    finishBank
    
     
    Last edited: May 7, 2019