Language…
6 users online: BUX88, HaruMKT, marvisjj, OrangeBronzeDaisy, Sweetdude, Th3Ruan057 - Guests: 143 - Bots: 380
Users: 64,667 (2,404 active)
Latest user: DarthHylian

Official Hex/ASM/Etc. Help Thread

  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 407
  • 408
  • 409
  • 410
  • 411
  • 412
  • 413
  • 414
  • 415
  • 416
  • 417
  • 418
  • 419
  • 420
hoping someone can clarify this for an asm dummy such as myself. I want to have diggin chucks rock moving left without a slope or ground. & I noticed this section in the disassembly asm file
Code
LDA !1588,x		;
AND #$04		; if the sprite is not touching the ground...
BEQ NoSpeed		; don't set any speed values 

The asm newbie in me says just change NoSpeed to F8 but me & asm arent the best mix
currently working on The Amazingly Randy
BEQ is a branch command. "BEQ NoSpeed" means that (if the conditions are met) the code will jump to the label named "NoSpeed:", a couple lines further down, and continue running from there.

If you don't want the code to jump to that label, simply removing the three lines you posted should do the trick.


 
Originally posted by WhiteYoshiEgg
BEQ is a branch command. "BEQ NoSpeed" means that (if the conditions are met) the code will jump to the label named "NoSpeed:", a couple lines further down, and continue running from there.

If you don't want the code to jump to that label, simply removing the three lines you posted should do the trick.

So I removed the 3 lines & it made the rock drift upwards. ill actually be able to use this #w{=3} but I am still curious about about a rock born with x speed.

also thanks for the nugget of coder wisdom!
currently working on The Amazingly Randy
Originally posted by XLIXER
So I removed the 3 lines & it made the rock drift upwards. ill actually be able to use this #w{=3} but I am still curious about about a rock born with x speed.

Ah I see, I didn't quite remember how the rock works.

It's probably best to leave those three lines in then, and instead do one of these (or both):

- to make the rock move left when it touches flat ground, remove this line, a little futher down:
Code
BEQ NoSpeed		; X speed = 00 if the sprite is on flat ground


- to make the rock move left as soon as it spawns, find this very near the top:
Code
print "INIT ",pc
RTL

and change it to this:
Code
print "INIT ",pc
LDA #$F8
STA !B6,x
RTL



 
Originally posted by WhiteYoshiEgg
It's probably best to leave those three lines in then, and instead do one of these (or both):

- to make the rock move left when it touches flat ground, remove this line, a little futher down:
Code
BEQ NoSpeed		; X speed = 00 if the sprite is on flat ground


- to make the rock move left as soon as it spawns, find this very near the top:
Code
print "INIT ",pc
RTL

and change it to this:
Code
print "INIT ",pc
LDA #$F8
STA !B6,x
RTL

Thanks a million m8! Youve given me a couple things to work with now #w{:>}
currently working on The Amazingly Randy
So I was bored and messing with some things and noticed that each right slope object appears to be misaligned by one pixel.

Shown in this image, the absolute closest your hitbox can be towards the slope before it begins to lift you up, showing that you have to be a pixel closer for it to detect that you're on the right slope. Would anyone happen to know what causes this?
Don't eat the sandwich
Why do I keep getting this message in Asar? Any help?

Rename the extension at the end from .sfc to .smc, then try again. Asar often gets confused when it spots an .sfc extension (which is weird and kinda dumb).


YY-CHR > Photoshop.
I have no idea how you guys are able to make Mario move without controller inputs. Like in cutscenes. How is this done? And how can I change up what happens in the end credits?
This is a footer.


Originally posted by MinecraftGamerLR
I have no idea how you guys are able to make Mario move without controller inputs. Like in cutscenes. How is this done? And how can I change up what happens in the end credits?

There's various options for that, such as this UberASM code. You can also write UberASM code to manually enter inputs, which is effectively what the castle-beaten cutscenes and title screen are doing.

For credits, just don't use the original game's credits and make your own by teleporting the player to a level or something. You can write out the credits text using some ExGFX and Map16, then just use an autoscroll/autowalk to scroll through them.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Okay, yes. I can see how the Map16 version of adding credits and such would work in a way, but I meant like the credits from VLDC11. I'm probably asking for too much.

Also, whatever happened to all.log? I tried to get it from MFG's Patch Creation tutorial, but it always says the file is not found.
This is a footer.
Originally posted by MinecraftGamerLR
Okay, yes. I can see how the Map16 version of adding credits and such would work in a way, but I meant like the credits from VLDC11. I'm probably asking for too much.

Also, whatever happened to all.log? I tried to get it from MFG's Patch Creation tutorial, but it always says the file is not found.

My tutorial linked to the old all.log but that has been superseeded by SMWDisC. Yet another reason to update my tutorial.
Hi, I've been reading the PIXI changelog to do a bit of catching up and noticed this line :

Code
  - (Atari2.0) Added a SpawnSpriteSafe routine to fix a problem related to how the vanilla game handles OAM in certain sprite slots.


I was wondering, what is the problem it speaks of? All the new routine seems to add vs. the normal version is the requirement to supply the starting sprite slot to seek (from the end of the table). So, I assume the issue is related to slot(s) at the end of the table?
Originally posted by aCrowned
Hi, I've been reading the PIXI changelog to do a bit of catching up and noticed this line :

Code
  - (Atari2.0) Added a SpawnSpriteSafe routine to fix a problem related to how the vanilla game handles OAM in certain sprite slots.


I was wondering, what is the problem it speaks of? All the new routine seems to add vs. the normal version is the requirement to supply the starting sprite slot to seek (from the end of the table). So, I assume the issue is related to slot(s) at the end of the table?

Indeed, the high slots are often not checked in some cases leading to unintended behavior, you can see a list (and a way to fix them) here.
Originally posted by Kevin
Originally posted by aCrowned
Hi, I've been reading the PIXI changelog to do a bit of catching up and noticed this line :

Code
  - (Atari2.0) Added a SpawnSpriteSafe routine to fix a problem related to how the vanilla game handles OAM in certain sprite slots.


I was wondering, what is the problem it speaks of? All the new routine seems to add vs. the normal version is the requirement to supply the starting sprite slot to seek (from the end of the table). So, I assume the issue is related to slot(s) at the end of the table?

Indeed, the high slots are often not checked in some cases leading to unintended behavior, you can see a list (and a way to fix them) here.


Wow, that's a lot of small issues fixed, and I don't think I knew about any of them before. #smrpg{haha}
Many thanks for the quick reply!
I'm recently making a lava-like block that kills entities and Mario when they touch it. The problem is that when a sprite that turns upon ledges (ex: Red Koopa) runs near it, it tries turning around and instantly dies without even(graphically) touching the lava. How to make that the block kill the sprite only if it falls in the block? (I edited the code to make the dry bones immune to lava, because it should be. But a red koopa behaves the same I described)


Edit: whoops, forgot the code
Code
SpriteV:			
	LDA !9E,x				; \ If the sprite's type is not equal to 33...
	CMP #$33				; |
	BEQ StayAlive				; /
	LDA !9E,x				; \ If the sprite's type is not equal to 22...
	CMP #$B6
	BEQ StayAlive
	LDA #$05				; \
	STZ !14C8,X				; | Kill the sprite as if by lava.
	LDA #$40				; |
	STA !1558,x
StayAlive: 
	LDA #$80
    STA $164A,x			
RTL


Yet another edit: Solved by making a check if the sprite is on the ground!
Code
	LDA !1588,x				; \ If the sprite is not on the ground....
	AND #$04				; |
	BEQ StayAlive			; /
	LDA #$04				; \
	STA !14C8,X				; |
	LDA #$1F				; | Kill the sprite with the spinjump effect.
	STA !1540,X				; |
	JSL $07FC3B				; |
	LDA #$08				; |
	STA $1DF9|!addr			; /

Thinking about what patcher to use.
Originally posted by Thiago678
I'm recently making a lava-like block that kills entities and Mario when they touch it. The problem is that when a sprite that turns upon ledges (ex: Red Koopa) runs near it, it tries turning around and instantly dies without even(graphically) touching the lava. How to make that the block kill the sprite only if it falls in the block? (I edited the code to make the dry bones immune to lava, because it should be. But a red koopa behaves the same I described)

One way to solve it is by checking for the position of the sprite or rather, interaction point (low byte of the Y position: $0C). If the low nibble (i.e. $x0-$xF) is at a certain position, the lava doesn't kill the sprite in question.


I have a problem myself too:

I wanted to release this sprite for C3 but unfortunately, I can't solve the problem where a cannon which stands right next to a wall to the right can clip through it when the player reenters the cannon at that position and moves farther left.

Here is the code


Originally posted by MarioFanGamer
I wanted to release this sprite for C3 but unfortunately, I can't solve the problem where a cannon which stands right next to a wall to the right can clip through it when the player reenters the cannon at that position and moves farther left.

I assume it's just because of the order of events. The sprite-object routine ($019138) is being called before the sprite's X speed is updated with the dummy speed, so it ends up using the previous frame's data. Meanwhile, the sprite's actual position update handling assumes it's the current frame. So for a frame between when Mario is assumed to be on the "right" side of the sprite and when he moves to the "left" side, the sprite will be checking the wrong side of itself for blocks, and thus can shift into the wall.

I think this actually should probably occur when the sprite moves in either direction, but it's easier to see with the left side since while Mario is inside the canon, the code's X position check will assume he's on the "right" side (because of how it sets his X position to the same offset).

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Oh, it's this easy! Thank you so much! #smw{:peace:}
Hi, I was making a cool custom block which transform a key into a mushroom block, but if I throw the key upwards or sideways it glitches:
-It replaces the block into tile 125 and activates for the former.
-It adds a tile 125 somewhere and activates for the latter.

Code
db $37

JMP MarioBelow : JMP MarioAbove : JMP MarioSide
JMP SpriteV : JMP SpriteH
JMP Cape : JMP Fireball
JMP MarioCorner : JMP MarioBody : JMP MarioHead
JMP WallFeet : JMP WallBody

SpriteV:
SpriteH:
	LDA !14C8,x				; \ If the sprite is not carried
	CMP #$0B				; |
	BEQ Label_0000				; /
	LDA !9E,x				; \ If the sprite's type is equal to #$80 (key)...
	CMP #$80				; |
	BNE Label_0000				; /
	%sprite_block_position()		; \
	%create_smoke()				; / Create smoke effect.
	LDA #$04				; \
	STA !14C8,X				; |
	LDA #$1F				; | Kill the sprite as if spin-jumping it.
	STA !1540,X				; |
	JSL $07FC3B				; |
	;LDA #$08				; | \ Ignored
	;STA $1DF9|!addr			; / /
 	LDA #$0C				; \ Play the "carry item past the goal" sound effect.
	STA $1DF9|!addr				; /
	PHX					; \ Change the block to tile $016B
	PHY					; | > [1]: I tried saving Y, but it solves nothing
	REP #$10				; |
	LDX #$016B				; |
	%change_map16()				; |
	SEP #$10				; |
	PLY					; | > [1]
	PLX					; /

Label_0000:					; > --------

MarioBelow:
MarioAbove:
MarioSide:
Cape:
Fireball:
MarioCorner:
MarioBody:
MarioHead:
WallFeet:
WallBody:
RTL

print "key to mushroom block"


What I am doing wrong?
My 1st romhack in progress (testing avaiable)...
(beta)
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 407
  • 408
  • 409
  • 410
  • 411
  • 412
  • 413
  • 414
  • 415
  • 416
  • 417
  • 418
  • 419
  • 420