Posts by betalogic - SMW Central

Hey everyone,

I've been lurking for a long time, trying to learn ASM. Now is the first time I've genuinely been confused to the point where I don't think I can find any resources to help me about it.
I've been trying to make a relatively simple patch that makes it so that 1. you always throw a carried item in the direction you are holding on the d-pad (to remove spin-jump frame variance jank) and 2. if you are spinning and drop or up-throw an item, you throw it out from the center of mario, a la mario maker.
It all works, however, for some reason, part of my motified drop code doesn't properly work. The thing is, I basically copy-pasted the code from the the disassembly (from address $01A049, to be specific), so I don't know whats different and why it won't work.

What ends up happening is the item gets places a screen too early when facing right, and magically disappears when facing left. Even without the high-byte addition, the item drops ~32 pixels right of where its supposed to be.

Here's the code in question

Code

DropLow:  db $F3, $0D ; Low-byte values, -13 and +13
DropHigh: db $FF, $00 ; High-byte values

LDA $D1        ; Get Mario's x-position
CLC            ; 
ADC DropLow,y  ; Add the relevant value
STA $E4,X      ; Set the carried sprite's x-position
LDA $D2        ; \
ADC DropHigh,y ; | Repeat for the high-byte
STA $14E0,X    ; /

Thank you in advance for anyone who helps!

Edit: Thank you guys! I guess I have to review addressing a little.

Okay, for a segment of a level I am working on, I have two brown/checkboarded line-guided platforms that the player rides on. To have a better control over how the camera scrolls, I decided to make some UberASM code to search for spawned platforms, average the first two that it finds, and set that as the horizontal camera position.

The code works perfectly except that it sometimes fails to spawn sprites. I have tried to fix this by setting other relevant RAM addresses, such as $1A and $210D, and even by setting the layer 1 position difference, $17BD. I've also tried looking at the disassembly but I haven't been able to find anything helpful. I was wondering if anyone has run into a similar issues and what I might be able to do to fix this.

Here is the code, if anyone is curious.

Thank you!
Beta Logic~

EDIT:
Welp, I'm dumb. I found a patch that fixes this very problem!

Here is a link to the patch if anyone needs it.

If you want to bounce off of it exactly like you would an enemy, you can jump to the "boost player" subroutine (address $01AA33). You might put it

Code

...
        ;; Set player Y position relative to sprite
        lda !sprite_y_low,x : sec : sbc $00 : sta !PlayerY
        lda !sprite_y_high,x : sbc #$00 : sta !PlayerY+1

        JSL $01AA33

        ;; Play switch SFX
        lda.b #!Switch_Sfx_Number : sta.w !Switch_Sfx_Bank|!Base2
...

under the "P-Switch collision handler" .NoCarry label.

For the second added feature, that might be a little more difficult. While you might be able to solve it by jump to the sprite-sprite interaction routine (address $018032), that might also make shells kill it, which I assume is not desired behavior. If that doesn't matter, you can put

Code

...
Pswitch_Main:
        ;; Branch if sprites locked
        lda !LockAnimationFlag : beq +
        jmp .graphics
        +
        ;; Offscreen moved from bottom of sprite routine
        %SubOffScreen()

        ;; Update sprite position with gravity
        jsl $01802A|!BankB
        JSL $018032

        ;; Handle touching the ground
        lda !sprite_blocked_status,x : and #$04 : beq .Not_Touching_Ground
        jsr Handle_Touch_Ground
...

under the "Stunned/Main routine" section.

If you don't want that to happen, it will probably be significantly harder. You might have to partially disassemble the sprite-sprite interaction routine to check for and filter out carriable and kicked sprites. Alternatively, you could make a patch that modifies the sprite-sprite interaction routine to check for an additional sprite property to not interact with carriable or kicked sprites. That might actually be useful in other circumstances, so I am willing to make it if you want me to.

Before I decide to submit anything that takes advantage of it, I was wonder if it is considered a poor programming practice to use the reserved opcode "WDM". For those who don't know, opcode $42 is technically "reserved", which means it isn't used for anything. Essentially it acts like a NOP instruction with one key difference: WDM accepts a second byte, which it reads, but does nothing with. That means that, if put before a 1 byte instruction, it will "skip" over said instruction.

It could be used in a code like this:

Code

; .. something something
BPL +
    SEC
    WDM
+
CLC

Although I don't know if ASAR accepts WDM properly on its own like that, so I write the notably more ugly code

Code

BPL +
    SEC
    db $42 ; Skip the next instruction
+
CLC

I would understand if the community frowns upon its use -- it is obscure, not often useful and only saves one cycle and one byte over its alternative "BRA $01". I was just wondering because I had not seen it even mentioned before I started closely studying the technical documents on 65c816 ASM.