Basic Questions and Answers Thread

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

  1. Samey

    Samey Le Bored Hedgie Member

    Joined:
    May 3, 2017
    Messages:
    57
    I'm having a bit of a problem with animated tiles.

    I can't seem to be able to tell the game how many frames the art is supposed to have
    if I put it at any even number, it doesn't animate at all.
    If I put at at most odd numbers it only animates the first 2 frames
    and if I put it at F, it does the entire animation, and then some garbage tiles

    the Animation is supposed to have 9 frames and I honestly don't know what's wrong. :(

    here's the code if it helps:

    Code:
    AniArt_MZ_UFOs:
    
    @size:        equ $10    ; number of tiles per frame
    
            subq.b    #1,($FFFFF7B7).w ; decrement timer
            bpl.w    locret_1C1EA            ; branch if not 0
          
            move.b    #3,($FFFFF7B7).w ; time to display each frame
            lea    (Art_MzUFOs).l,a1 ; load torch    patterns
            moveq    #0,d0
            move.b    ($FFFFF7B8).w,d0
            addq.b    #1,($FFFFF7B8).w ; increment frame counter
            andi.b    #9,($FFFFF7B8).w ; there are 3 frames     ***this line!***
            mulu.w    #@size*$20,d0
            adda.w    d0,a1        ; jump to appropriate tile
            move.l    #$4E400001,($C00004).l
            move.w    #@size-1,d1
            bra.w    LoadTiles
    
    locret_1C1EA:
            rts    
    It's a amalgamation of Github and Hivebrain because I thought the Github variant was easier to read and edit.

    Edit: Yes, I've tried looking at some guides on doing this properly, but Markey's guide on Retro is virtually unreadable, and I had a bit of trouble with Firerat's also.
     
  2. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    I think you're misunderstanding how "and" works.

    If you want to use "and" to limit a variable's value, you can only limit it to being less than 1, 2, 4, 8, $10, $20, $40, $80, etc. because it is a bitwise operation. Otherwise you'll have to compare if the variable has reached a certain number, then reset it if it has.
     
    Samey likes this.
  3. Samey

    Samey Le Bored Hedgie Member

    Joined:
    May 3, 2017
    Messages:
    57
    Ah, thanks!
     
  4. Deactivated Account

    Deactivated Account Well-Known Member Exiled

    Joined:
    Aug 26, 2016
    Messages:
    244
    Hey, someone know which is the problem in Marble zone Act 3, why the lava gush with ripples that rises from the floor doesn't work?
     
  5. Samey

    Samey Le Bored Hedgie Member

    Joined:
    May 3, 2017
    Messages:
    57
    If I remember from lurking around here, the lava gush is actually hard coded into sonic1.asm
    Placing them doesn't really do anything but have them instantly activate and then delete themselves.

    I don't know exactly where it is in the file though.
     
    Deactivated Account likes this.
  6. Deactivated Account

    Deactivated Account Well-Known Member Exiled

    Joined:
    Aug 26, 2016
    Messages:
    244
    Alright thank you, if someone know tell me.
     
  7. Psi

    Psi Well-Known Member Member

    Joined:
    Dec 20, 2014
    Messages:
    102
    Does anyone here know how to port Tails' tails object to Sonic 1?

    There seems to be tutorial archived but it's given a disclaimer not to use it.
     
  8. DaSupaWaffle

    DaSupaWaffle Newcomer Trialist

    Joined:
    Aug 23, 2017
    Messages:
    8
    Location:
    United States
    For sprites, you just need to replace the original Sonic sprites with Tails'. There should be a sprite editing tutorial on Sonic Retro, but I forget the link.
    For flying, you need to take the code from Sonic 2 that controls flying and edit it so that it works with Sonic 1's code (by editing subroutine numbers and ect.) Start with the tutorial on adding new moves to Sonic 1 if you already don't know.

    ---I posted this in the wrong place, so I'm putting it here now, sorry---

    I've been working a bit with ASM for the first time, as I didn't have enough programming knowledge, but now that I do, I want to try to get some things to work. I am working with the 2005 Hivebrain disassembly of Sonic 1 and want to have sonic run into the first zone. Before, I just used a spring at the beginning of the level, but that obviously isn't ideal. Is there some kind of script I can put in for Sonic to run into a specific act? I've seen it done in a few hacks, but have no idea where to start other than maybe the zone start sections.

    >>> Staff Edit <<<
    This was originally two posts, posted around the same time. Please don't multi-post in the same thread like that.
     
    Last edited by a moderator: Aug 27, 2020
  9. Kilo

    Kilo Foxy Fren Exiled

    Joined:
    Oct 9, 2017
    Messages:
    391
    Location:
    A warm and lovely place~
    Each stage has a dynamic resizing routine. This is used to do things like scroll the camera boundaries (Like the S-Tube section in Green Hill Zone Act 1) You can use this routine to do other things as well, for example making Sonic run. The rest is up to you.
     
  10. DaSupaWaffle

    DaSupaWaffle Newcomer Trialist

    Joined:
    Aug 23, 2017
    Messages:
    8
    Location:
    United States
    Thank you, I will look into that. I appreciate your help.

    Sorry for asking so much at once, but I ran into a problem while editing. I'm not sure if this is an ASM, sprite editing, or SonLVL problem, but whenever I play my ROM, I get a distorted sign post that just glitches the game out. Any idea on why this is happening?

    upload_2020-8-26_17-16-21.png
     
  11. DeltaWooloo

    DeltaWooloo The noob next door Member

    Joined:
    Aug 7, 2019
    Messages:
    373
  12. DaSupaWaffle

    DaSupaWaffle Newcomer Trialist

    Joined:
    Aug 23, 2017
    Messages:
    8
    Location:
    United States
    It worked, thank you! However, the sprites are still messed up until Sonic actually hits the signpost. I've also noticed some of the enemy explosions will use the zone title sprites. I'm assuming these two glitches are connected somehow? Is there anything further I can do to fix this?
     
  13. Nat The Porcupine

    Nat The Porcupine Point & Click Funny Man Member

    Joined:
    Jun 23, 2017
    Messages:
    71
    Location:
    Pennsyltucky
    So, this isn't a really a basic question, in fact it's a rather technical one. A little while ago, I started work on a dynamic camera system for a project & I've recently decided to pick the code back up & fully document it with the hope of fully fleshing it out, but there's an odd quirk that's been around since the earliest versions of it that I want to be able to fully understand. Here's the code & then I'll explain what exactly it is (I apologize for the formatting; my comments are quite lengthy): https://pastebin.com/R51wTRXj

    Now, at the very beginning of the routine, you'll see a immediate value moved to d0 that is referred to in the line's comment as the right-most edge of the "deadzone". The "deadzone" is what I have dubbed this quirk, and once I explain exactly what it is, you'll understand. You see, that value was originally 160, because as far as I knew at the time, my camera should just pan back to the center any time you slow to a stop, given that the panning offset is calculated based on a factor of the player's speed. This worked just fine when traveling left: the value would reset to 160 when at a standstill after moving at high speed in that direction. However, when traveling right & then coming to a stop, something most interesting occurs. Instead of centering the camera fully, it would stop short of the center a maximum of 31 pixels early. Now, I will admit that over time, I grew to see enough potential in the quirk to be an actual feature of the camera system that I tweaked my code to properly embrace it & ended up with what I've shown today. I do have a loose theory for why it might happen, but I figured I'd drop it here to see if anyone could explain in better detail why this happens. After all, if I'm going to be calling it a "feature", I'd better be able to properly explain it on a technical level. xP

    I'm also going to include a ROM for the old project that implements the camera in case anyone who is able to answer this wants to take it for a spin & debug it during their investigation. Thanks in advance.
     

    Attached Files:

  14. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    I am very certain that this is responsible:
    Code:
    		move.w	(Horiz_scroll_pan).w,d1		; NTP: Load the previous horizontal pan value
    		add.w	d1,d0				; NTP: All of the following add/shift mess is, for the most part, identical to this equation, sans rounding differences: (d0 + 31(d1)) / 32
    		add.w	d1,d0				; NTP: What this accomplishes is the calculation an intermediate values that is heavily biased towards the pan value on the previous frame...
    		add.w	d1,d0				; NTP: ...That the pan value will be set to, allowing us to create a nice, smooth, dynamic camera pan that isn't too jarring or jerky.
    		asr.w	#2,d0
    		add.w	d1,d0				; NTP: Now the lot of you are probably wondering what causes the "deadzone" at the center of the screen, where slowing down doesn't scroll...
    		add.w	d1,d0				; NTP: ...the camera back towards the center of the screen until you begin moving in the opposite direction entirely, or why we need one at...
    		add.w	d1,d0				; NTP: ...all instead of just panning back to the center of the screen entirely. Well, truth be told... I have no ide what causes the deadzone!
    		asr.w	#2,d0				; NTP: It's true; it was a quirk in the code that popped up while I was writting this camera system that I loved so much that I fully embraced...
    		add.w	d1,d0				; NTP: ...it instead of investigating what had caused it to begin with. I personally think it's useful to still be able to see a slight bit...
    		asr.w	#1,d0				; NTP: ...ahead of you even after coming to a complete stop, but I could not even begin to tell you what caused it. I'll leave that to you all! :P
    		move.w	d0,(Horiz_scroll_pan).w		; NTP: Oh yeah, and uh, this line just sets the new pan value once we're done running all the calculations & such
    We'll pretend Sonic isn't moving, so his speed is 0. So, d0 should in theory have 159+16 = 175 (AF), and since the Horiz_scroll_pan is variable and fluctuates based on the position that comes out, we'll start it off as 0.
    Code:
    0 -> 175 = 5
    OK so, if the Horiz_scroll_pan was 0 before, after it's ran through the equation with d0 still having 175 (a.k.a 159+16), what comes out is 5 and is saved to Horiz_scroll_pan. Next frame:
    Code:
    5 -> 175 = 10
    Alright so, it's gone up again, now 10 is in Horiz_scroll_pan. Next frame:
    Code:
    10 -> 175 = 15
    Now it's 15, so it seems to be incrementing by about 5 each time. Next frame:
    Code:
    15 -> 175 = 20
    Another +5. Next frame:
    Code:
    20 -> 175 = 24
    Oh, it only went up by 4 this time, so I'd assume either it'll loop a few 5 and the occasional 4. Or it's getting gradually slower...
    Code:
    24 -> 175 = 28
    OK, it's gradually slowing down:
    Code:
    28 -> 175 = 32
    Let's keep going... (Scroll down~)
    Code:
    32 -> 175 = 36
    36 -> 175 = 40
    40 -> 175 = 44
    44 -> 175 = 48
    48 -> 175 = 51
    51 -> 175 = 54
    54 -> 175 = 57
    57 -> 175 = 60
    60 -> 175 = 63
    63 -> 175 = 66
    66 -> 175 = 69
    69 -> 175 = 72
    72 -> 175 = 75
    75 -> 175 = 78
    78 -> 175 = 81
    81 -> 175 = 83
    83 -> 175 = 85
    85 -> 175 = 87
    87 -> 175 = 89
    89 -> 175 = 91
    91 -> 175 = 93
    93 -> 175 = 95
    95 -> 175 = 97
    97 -> 175 = 99
    99 -> 175 = 101
    101 -> 175 = 103
    103 -> 175 = 105
    105 -> 175 = 107
    107 -> 175 = 109
    109 -> 175 = 111
    111 -> 175 = 113
    113 -> 175 = 114
    114 -> 175 = 115
    115 -> 175 = 116
    116 -> 175 = 117
    117 -> 175 = 118
    118 -> 175 = 119
    119 -> 175 = 120
    120 -> 175 = 121
    121 -> 175 = 122
    122 -> 175 = 123
    123 -> 175 = 124
    124 -> 175 = 125
    125 -> 175 = 126
    126 -> 175 = 127
    127 -> 175 = 128
    128 -> 175 = 129
    129 -> 175 = 130
    130 -> 175 = 131
    131 -> 175 = 132
    132 -> 175 = 133
    133 -> 175 = 134
    134 -> 175 = 135
    135 -> 175 = 136
    136 -> 175 = 137
    137 -> 175 = 138
    138 -> 175 = 139
    139 -> 175 = 140
    140 -> 175 = 141
    141 -> 175 = 142
    142 -> 175 = 143
    143 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    144 -> 175 = 144
    whoa
    whoa
    whoa
    whoa
    ...stop!
    144 is the threshold. 175 - 144 = 31.

    So that's why the gap is 31 pixels big, the routine eventually thresholds at that rate.
     
  15. Nat The Porcupine

    Nat The Porcupine Point & Click Funny Man Member

    Joined:
    Jun 23, 2017
    Messages:
    71
    Location:
    Pennsyltucky
    Thank you for the insight, Markey. I figured it might have something to do with that, but I wasn't quite sure. I'll update my comments to properly reflect what's described here.
     
    MarkeyJester likes this.
  16. Kilo

    Kilo Foxy Fren Exiled

    Joined:
    Oct 9, 2017
    Messages:
    391
    Location:
    A warm and lovely place~
    While I'm not exactly looking for a fix, I am looking for an explanation as to why this could occur.
    While working on a S1J2ME hack, I figured I'd try to see if the graphics library supported .BMP images. After fumbling and mistyping "mbp" and changing the extension of the wrong files, I finally got it sorted out. What resulted excited me:
    upload_2020-9-5_20-18-55.png
    Clearly, Sonic's not supposed to look like that. So my question is: What could be distorting Sonic's colors like this?
     
  17. Tanman Tanner

    Tanman Tanner Well-Known Member Member

    Joined:
    Dec 23, 2016
    Messages:
    116
    Location:
    Buffalo, New York
    Aren't BMP files structured in a different way from PNGs, and have a lot less colors to pick from? I'm just spitballing here, but just because it supports BMP, does the game properly have a way to handle a BMP file *as* an BMP file and not interpreting it as a PNG? The colors might be getting shifted because it's interpreting the BMP as a PNG and the (considering the colors still appear to be consistent, i.e. the range of the blues for its face and chest are shaded like it would normally be, albeit using the wrong color scheme) its color values are set to the same place as in PNG, which might be a totally different color altogether.
    The channels just appear to be swapped. PNGs use RGB while some BMPs use BGR. A lazy-ish and not a guarantee to work suggestion I'd throw your way is try to have code that could swap the R channel in the BGR BMP with the B channel, and vice versa.
     
    Last edited: Sep 7, 2020
  18. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    PNG is a completely different format than BMP, you can't "interpret a BMP file as a PNG". Also BMP files can be 24bpp and I think some programs support 32bpp BMPs, so it's not a color limitation. Looks to me like the channel order is swapped. No idea how you would fix that though.
     
    ProjectFM likes this.
  19. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    Yeah, 24-bit BMPs save the bytes in bgr order instead of rgb.
     
    ProjectFM likes this.
  20. Kilo

    Kilo Foxy Fren Exiled

    Joined:
    Oct 9, 2017
    Messages:
    391
    Location:
    A warm and lovely place~
    Well, thank you for the explanations!
    As for the fix to change the channel order, while it would be nice, currently the J2ME decompilation is non-buildable since it's heavily obfuscated, and most decompilers run into problems with most of the game class files. And even if the decompilation were to be usable, why not just add proper BMP support.