Basic Questions and Answers Thread

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

  1. Painto

    Painto Arthurus Paintus Erinaceus Member

    Joined:
    Mar 24, 2014
    Messages:
    321
    Location:
    Lublin, Poland
    Yeah, noticed that. Anyway, now as I'm looking at this, I think that easier just would be edit a bit the art. Thanks for your help (and for getting me to that conclusion).
     
    Last edited by a moderator: Aug 26, 2014
  2. vladikcomper

    vladikcomper Well-Known Member Member

    Joined:
    Dec 2, 2009
    Messages:
    415
    The black "background" is actually meant to hide the loading process from you, and it's not a background at all per se. Basically, the last three palette lines are entirely set to black while the game loads a level, so you don't see incomplete art being drawn in front of your eyes. I guess you might be able to change it to another solid color, or use sprites which use a color from the first palette line to draw something

    Actually, everything gets drawn at the very last moment before the level fades in. Most of the time goes for decompressing Nemesis art, which is extremely unoptimized to be fair and makes loading process last about 4 times longer than it could be (compare it to loading times in Sonic 2), but that timing looked pretty tolerantable with the design of title cards in Sonic 1 and presentation-wise.

    What makes it extremely cycle-wasting is using the Pattern Load Cues system during the title cards loop instead of decompressing art right away. The said PLC system was designed to decompress Nemesis art by little portions per frame not to overload processor and allow it to process game logic simultaneously. This system works perfectly fine when you reach the boss arena or signpost for example -- the game slowly decompresses new art without halting the gaming process for you, unlike many other games of that time (take the Golden Axe series or Moonwalker for example). However, all title cards do most of the time is just displaying a set of static sprites, so a huge number of cycles saved by the PLC system for game logic processing is eventually wasted. Normally, the PLC system decompresses 3 tiles per frame, however in order to speed up unreasonably slow loading process title cards loop uses a special VBlank routine that does 9 tiles per frame instead.

    Now, speaking of your question, EasterBanana, as nineko has already pointed out, you may easily change the background color during on title cards screen to any other color of your choice by filling 3 last palette lines with that color. Doing so is fairly easy, here is a little example for you:


    lea $FFFFFB00+$20,a0 ; load active palette buffer, starting from the second line
    lea $FFFFFA80+$20,a1 ; load active palette buffer (underwater), starting from the second line
    move #$888,d0 ; set fill color to $888 (gray)
    move #48-1,d1 ; set number of colors to 48

    @fpal move.w d0,(a0)+ ; fill palette
    move.w d0,(a1)+ ; fill palette (underwater)
    dbf d1,@fpal ; repeat until all colors are done

    Just place my code above "Level_TtlCard:" label and see how it works.

    However, if you have decided to use background color, different from black or white, you'll need to program your own palette fading routines in order to handle fading in to level correctly. Standard routines in Sonic 1 are hardcoded to fade to or from black and white and barely can be used to fade from or to any other colors.

    Sonic 2 indeed applies a little magic when it comes to the title cards. All moving solid rectangles that appear on the title cards are rendered on the Plane A. This means both title cards and level foreground share the same layer, but the game tricks you into thinking those are separate things due to drawing tricks it uses.

    The scrolling of the rectangle when the card goes off is actually faked. The rectangle doesn't really move, the game just starts drawing rows of 16x16 blocks over the solid rectangle, one row per frame. This way, it simulates a solid rectangle over the foreground moving up 16 pixels per frame and one may think it actually moves.

    EDIT: More quotes due to next page.
     
    Last edited by a moderator: Aug 26, 2014
  3. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    Ha, I thought Sonic 2 did something like that, thanks for explaining!
     
  4. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Oh, Rev01, no wonder it didn't work, I thought you were working with Rev00.

    What they did for Rev01 is instead of using the original system, they decided to use specific routines dedicated to each zone, for GHZ, the routines are what you want to look at are; sub_6DA6 and sub_6EA4.

    sub_6DA6 is what you DON'T want running, it deals with drawing the bottom mounts, to disable it, goto Deform_GHZ and comment out the call to "ScrollBlock5".

    sub_6EA4 is what you want to alter:

    sub_6EA4:
    tst.b (a2)
    beq.w locret_6EF0
    cmpi.b #2,($FFFFFE10).w
    beq.w loc_6F54
    bclr #0,(a2)
    beq.s loc_6ED0_2
    move.w #$40,d4 ; '@'
    moveq #-$10,d5
    bsr.w Calc_VRAM_Pos
    move.w #$40,d4 ; '@'
    moveq #-$10,d5
    moveq #2,d6
    bsr.w DrawTiles_TB2

    loc_6ED0_2:
    bclr #1,(a2)
    beq.s locret_6EF0
    move.w #$40,d4 ; '@'
    move.w #$140,d5
    bsr.w Calc_VRAM_Pos
    move.w #$40,d4 ; '@'
    move.w #$140,d5
    moveq #2,d6
    bsr.w DrawTiles_TB2

    locret_6EF0:
    rts The "moveq #2,d6"s you see are the number of blocks that scroll section draws, change them to 6 to fix the bottom mounts (you could make it a larger number if you wanted to fix the grass, but given the grass is a repetive pattern means you probably won't need that drawing).
    Now don't worry about SBZ or MZ using that same routine, they have different bit settings for ScrollBlock6, so they'll run their own specific drawing routines (assuming I haven't missed anything).

    The problem with this method is that it's too specific making it difficult to comprehend and alter, you really have to scrutinise the code thoroughly.
     
  5. Stardust Gear

    Stardust Gear A Programmer Member

    Joined:
    Apr 27, 2014
    Messages:
    134
    How to add Homing Attack to Sonic 1?

    I want this move in my hack.
     
  6. ThomasThePencil

    ThomasThePencil resident psycho Member

    Joined:
    Jan 29, 2013
    Messages:
    910
    Location:
    the united states. where else?
    Step 1: Try to do it yourself.

    I'm being serious. Stardust Gear, if there is only one thing you ever learn from me, let it be this: If you do not attempt to do things on your own then you will never become a great hacker. If you have tried for weeks or even months without success, consult me or someone else about it. I have a method which, while pretty barebones in its inner workings, is fully functional in Sonic 2, but I won't give it out because, well, it's a pretty simple thing to figure out when you think about it. :U

    But since I'm feeling in a generous mood today, here's a hint: Triangles.
     
    Last edited by a moderator: Aug 27, 2014
  7. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Actually, that's a major understatement which should not be confused. Triangle usage is simply a byproduct and is not necessary to allow one item to move to another. Trigonometry is used to remove heavy calculation on the smallest productional distances in an illusionary form. And it's highly misleading, as a homing attack can be coded without the use of trigonometry.

    http://sonicresearch.org/forums/index.php?showtopic=1335&p=43973

    You have to be careful not to confuse the two as being part of the same product, these are individual minute functional calculations, and do not account as "being" the homing attack (or a necessary part of it).
     
  8. Stardust Gear

    Stardust Gear A Programmer Member

    Joined:
    Apr 27, 2014
    Messages:
    134
    I got a rare bug in my game when I tried to build it:

    D:SONIC HACKINGPROJECTSS1STAR-MEGAPCMSOUNDMUSICMZ2.BIN(1) : Error : Illegal character [black Dot] (7) in input.

    It is Volcano Valley Zone Act 2 Music from Sonic 3D Blast, ported to MegaPCM with the PSG and DAC Shifting by Ralakimus.

    And another bug:

    I think MegaPCM corrupts the PSG3 Noise. I don't hear these after I've ported MegaPCM to Sonic 1.
     
  9. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    So, I was trying to insert the S2 clone driver into my S2 hack, and ended up with these errors:

    > > >s2.asm(6102): error: short addressing not allowed
    > > >         move.b  #$80,(Clone_Driver_RAM+f_stopmusic).w   ; unpause music
    > > >s2.asm(6102): error: addressing mode not allowed here
    > > >         move.b  #$80,(Clone_Driver_RAM+f_stopmusic).w   ; unpause music

    What do they mean? How would I fix stuff like this in the future? I've never seen this crap in S1 before o.0
     
  10. Pokepunch

    Pokepunch That guy who posts on occasion Member

    Joined:
    Aug 7, 2009
    Messages:
    270
    Location:
    UK
    I'm trying to edit the 100 points text object to simply make it so it appears for 2 seconds then disappears. I have attempted to set up a timer but it doesn't seem to be working as intended. Right now the text just stays there forever.


    ; ===========================================================================
    ; ----------------------------------------------------------------------------
    ; Object 29 - "100 points" text
    ; ----------------------------------------------------------------------------
    ; Sprite_11DC6:
    Obj29:
    moveq #0,d0
    move.b routine(a0),d0
    move.w off_11DD4(pc,d0.w),d1
    jmp off_11DD4(pc,d1.w)
    ; ===========================================================================
    off_11DD4:
    dc.w loc_11DD8-off_11DD4
    dc.w Points_Timer-off_11DD4
    dc.w loc_11E06-off_11DD4; 4
    ; ===========================================================================

    loc_11DD8:
    addq.b #2,routine(a0)
    move.l #Obj29_MapUnc_11ED0,mappings(a0)
    move.w #$84AC,art_tile(a0)
    bsr.w Adjust2PArtPointer
    move.b #4,render_flags(a0)
    move.w #$80,priority(a0)
    move.b #8,width_pixels(a0)
    bra.w DisplaySprite
    move.b #$78,anim_frame_duration(a0)
    addq.b #2,routine(a0)

    Points_Timer:
    bra.w DisplaySprite
    sub.b #1,anim_frame_duration(a0) ; subtracts from the timer
    tst.b anim_frame_duration(a0)
    beq.s loc_11E06 ; tests if timer has hit 0
    rts

    loc_11E06:
    bra.w DeleteObject 
    Can somebody lead me in the right direction as to how to fix this?
     
  11. warr1or2

    warr1or2 I AM CLG Member

    Joined:
    Apr 7, 2008
    Messages:
    416
    Location:
    Town Creek, AL
    I use MegaPCM and everytine i add music everything's fine. Where are you incbin-ing at? From what I know all music & sound are incbin-ed at the end of sonic1.asm.
     
  12. vladikcomper

    vladikcomper Well-Known Member Member

    Joined:
    Dec 2, 2009
    Messages:
    415
    "Illegal character in input" error usually occurs when you mistakenly include binary data as an assembly code, like this:


    include "soundmusicmz2.bin"

    Use "incbin" directive instead for ASM68K and "binclude" directive for the AS macro assembler.

    As for your second bug, Mega PCM driver has no relationship to the SN76489 sound chip, in other words, it cannot interfere with PSG channels in any way as it doesn't access PSG ports at all.

    Assembler says it cannot use short addressing mode on the (Clone_Driver_RAM+f_stopmusic).w operand. This usually means, that the RAM address in the question is incorrect and cannot be used in short addressing mode. Show us what Clone_Driver_RAM and f_stopmusic are evaluated to, the problem is definitely with their values.

    EDIT:

    Pokepunch, you almost got everything right, except for one bit:


    Points_Timer:
    bra.w DisplaySprite
    sub.b #1,anim_frame_duration(a0) ; subtracts from the timer
    tst.b anim_frame_duration(a0)
    beq.s loc_11E06 ; tests if timer has hit 0
    rts

    loc_11E06:
    bra.w DeleteObject

    The code that subtracts timer and checks it simply doesn't work because you use direct jump (BRA) instead of a subroutine call (BSR) right before. The processor jumps to the "DisplaySprite" routine and never gets back.

    This should work better:


    Points_Timer:
    bsr.w DisplaySprite
    sub.b #1,anim_frame_duration(a0) ; subtracts from the timer
    tst.b anim_frame_duration(a0)
    beq.s loc_11E06 ; tests if timer has hit 0
    rts

    loc_11E06:
    bra.w DeleteObject

    In fact, you can optimize your code to this state:

    Code:
    	subq.b	#1,anim_frame_duration(a0)	; subtracts from the timer
    	beq.s	loc_11E06			; if the result is zero, branch
    	bra.w	DisplaySprite
    
    loc_11E06:
            bra.w   DeleteObject
    
     
    Last edited by a moderator: Aug 27, 2014
  13. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    HEY

    ...it's 'Clone Driver v2'

    ...dang people getting the name wrong. Next thing you know, people will be calling me "Clownancy"... oh wait

    Welcome to the AS Macro Assembler, where the errors are vague and confusing! Where on earth did you put Clone_Driver_RAM? If you put it in the normal place (the $500 bytes of free RAM rearranged to have $600 bytes free), you shouldn't be encountering that error. You've either messed the equate up somehow, or you just need to change the ').w' into a ').l' Though, I'm still unsure on the latter, I'm not too familiar with address ranges and limitations.
     
    Last edited by a moderator: Aug 27, 2014
  14. Stardust Gear

    Stardust Gear A Programmer Member

    Joined:
    Apr 27, 2014
    Messages:
    134
    Thanks Vladinkcomper.

    I forgot to change the include to incbin.

    The previous MZ2 music was in flamewing .asm format.
     
  15. Dexetroyer

    Dexetroyer Newcomer Trialist

    Joined:
    Aug 22, 2014
    Messages:
    6
    Location:
    New York, NY
    Hi everyone. I have a question regarding the Github dissasembly and Adding the Spindash to it. I've been following the guide in sonicretro.org about how to add it to Hivebrain's dissasembly and its pretty much done. What i cant seem to do is fix when sonic does the spindash and gets hit instead of the destroying the enemy. I Cant find where to put this line of code in the Github dissassembly:

    cmpi.b    #$1F,$1C(a0)    ; is Sonic Spin Dashing?
    beq.w    loc_1AF40    ; if yes, branch

    So where do i put this to fix the bug?
     
  16. warr1or2

    warr1or2 I AM CLG Member

    Joined:
    Apr 7, 2008
    Messages:
    416
    Location:
    Town Creek, AL
    I don't know about github s1 disassembly, but what I done to sucessfully have one up required SonMapEd, The final spindash code (#9, $1C(a0) instead) & the dash dust code (basically all section 3). But for some reason the spindust won't appear in mine.

    Just use sonmaped to open sonic 2's art, map & dplc (make sure format is Sonic 2) change format to Sonic 1 & save art, map & dplc, changing  to load sonic 2's art, map & dplc instead & sucess. I done this in Hivebrain (addressed music by MJ) with no problem
     
  17. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    In the GitHub disassembly, Touch_Enemy was renamed React_Enemy. It's in the _incObj/sub ReactToItem.asm file. Put your code there.
     
    Last edited by a moderator: Aug 27, 2014
  18. Dexetroyer

    Dexetroyer Newcomer Trialist

    Joined:
    Aug 22, 2014
    Messages:
    6
    Location:
    New York, NY
    Thanks, Clownacy. Now to add the smoke.
     
  19. Dexetroyer

    Dexetroyer Newcomer Trialist

    Joined:
    Aug 22, 2014
    Messages:
    6
    Location:
    New York, NY
    Also where was Loc_A1EC Moved to? Im trying to fix the monitor bug.
     
  20. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    It's the code labelled '@normal:' in the _incObj/26 Monitor.asm file.