Hey all, I'm sure the issue of music breaking on Snes9x GX is familiar to some of you. I was wondering if anyone found a way to run romhacks on a Wii U SNES emulator without running into issues? Hacks that otherwise work fine on Snes9x, for instance. I don't think the GX branch is getting Wii U updates anymore, particularly not for the fork that can play from the gamepad. Maybe throw a core in the Wii U Retroarch build?
Does anyone know of a way that you could change your position on the overworld from inside a level? I've looked and haven't found anything, but I'm willing to go digging if I'm pointed in the right direction. The key idea is what if you had multiple distinct levels with maps that connected to each other, and level-ending sprites could cause you to pop back out on the overworld in a different location than you entered - based on the map you collected them in, presumably.
Obviously this would have implications on level clear events and such, but abstractly is it even possible and where might I go looking?
(originally titled "fast travel" because the general idea is it could be used to act like a fast travel system in an open world game)
Wow! That's a fantastic feature, thanks for the answer. This looks like exactly what I was looking for.
So the SMB3 Statusbar has room for adding new counters and such in its various customization options, but being very unseasoned in ASM I can't quite parse where it would go. I was thinking of using the Coinhunt coin as an additional collectible in my levels, which I was able to insert with no problem and it's being tracked in $58 - so I know that much. But as far as where to grab and insert a counter for it in the custom statusbar, I am at a loss. Does anyone have any experience with this patch?
Hi. It may not be directly because of the use of %set_item_memory(), but when I add it to my CoinHunt coin and insert it with GPS, it acts like a solid question block from below - one with wings, a p-balloon, or key in it it seems. This happens whether or not I use it as an object, so I don't think it has to do with ObjecTool. I've tested it and, simply removing %set_item_memory() 'fixes' the issue, while also disabling Item memory, obviously not what I want. The code for the coin is below, with the only changes I've made to it being to add %set_item_memory and set the !FreeRAM.
Code
;The custom coin.
;Set it to act like tile 25 for more stable results.
db $42
JMP Work : JMP Work : JMP Work : JMP Return : JMP Return : JMP Return : JMP Return : JMP Work : JMP Work : JMP Work
;PLEASE NOTE: if you're going to mess with the values below, you must change them on all the other blocks related to this one as well!
!Coins = 8 ;Needed amout of custom coins (decimal!)
!EmptyRAM = 5C ;Empty RAM adress for the custom coin counter ; originally 79
Work:
PHY
JSR Glitter ;Show glitter
PLY
PHY
LDA #$02 ;Replace with block 25
STA $9C
JSL $00BEB0 ;Make the block disappear
PLY
INC $13CC ;Increment coin counter. Remove this line if you don't need it\
%set_item_memory()
LDA $!EmptyRAM
CMP #$FF ;Counter won't reset if you get 256 coins
BEQ Return
INC $!EmptyRAM ;Increase !EmptyRAM counter
LDA $!EmptyRAM
CMP #!Coins ;Play correct SFX if total needed coins number reached
BEQ SFX
LDA #$01 ;\Play "coin" SFX. Go http://smwc.me/t/6665 to
STA $1DFC ;/find other SFX values so you can customize it
RTL
Glitter:
LDA $7F
ORA $81
BNE ReturnLoop
LDY #$03 ;Find free sprite effect slot
LoopStart:
LDA $17C0,y
BEQ CGlitter ;Branch if one found
DEY
BPL LoopStart
ReturnLoop:
RTS
CGlitter:
LDA #$05
STA $17C0,y
LDA $9A
AND #$F0
STA $17C8,y
LDA $98
AND #$F0
STA $17C4,y
LDA $1933
BEQ Addr
LDA $9A
SEC
SBC $26
AND #$F0
STA $17C8,y
LDA $98
SEC
SBC $28
AND #$F0
STA $17C4,y
Addr:
LDA #$10
STA $17CC,y
RTS
SFX:
LDA #$29 ;\Play "correct" SFX. Go http://smwc.me/t/6665 to
STA $1DFC ;/find other SFX values so you can customize it
; INC $14AF ;Uncomment this if you want the ON/OFF switch to turn off (see readme for details)
Return:
RTL
Again, this isn't my code, this is for the Coinhunt Pack, in order to create a "collectible coin" effect, I added %set_item_memory() and then inserted an object in ObjecTool. Moving %set_item_memory() to different locations didn't change anything, but it only works to set the memory if it's inside the Work routine (probably pretty obvious). The object insert code is:
Code
CustObj20:
;Red Coin tile 1570, uses item memory
LDA #$70
STA $0C
LDA #$15
STA $0D
LDX #$02
JMP SingleBlockObjects
And nowhere in the set_item_memory routine (in GPS/routines/set_item_memory.asm) do I see any hints as to what value is misplaced (either in the routine itself or in the block) for it to act like the offending question block (extended object 35).
Video of the behavior. When Mario hits from below it acts like a question block and still collects a coin (as seen in the counter). When Mario hits it from another direction it is briefly solid and then collects a coin and disappears. In Map16, the "Act As" is set to 25 - the displayed coins are inserted as Custom Objects but the behavior is the same with using the tile from Map16 as well.
Thoughts on this one?
Update: messing with the Act As changes the behavior. The closest I could get it to pass-thru was to set the Act As to B (climbing net tile) - which Mario still gets stopped for a split second when landing on top but no longer treats it as a question block. Everything else either spawns a question block (like Act As 25) or makes it solid all around before collected... I'm sure this is something I messed up somewhere >_<
Hey I thought I'd post this here, but I'm having an issue with a block when using one of the routines in GPS. Basically, when using %set_item_memory, the coinhunt coin is acting like Extended Object 35, or a Question Block with wings/pwing/key/shell - while also still being collectible (and item memory is set correctly otherwise). I'm not sure if it's an issue with the macro or the coin itself, but I thought I'd plug it here. See the thread for full details.
That makes a lot of sense, thank you.
Can someone point me in the right direction to figure out how to get specific bit values within Bytes? Using this method one could store 8 separate booleans in a single byte (instead of how SMW does it with entire Bytes dedicated to True/False values). I've definitely looked around but I can't find exactly what I'm looking for, or I can't wrap my brain around it if I see it lol.
E.g. something like:
Code
;pseudocode
!Address = $someaddress
!FLAG1 = 0x00000001
!FLAG2 = 0x00000010
if !FLAG1 do something
if !FLAG2 do something also
Ah, exactly what I was looking for. Thank you very much, your explanation was very clear.
I'm talking like a familiar in SOTN or an option in Gradius, for instance. In SMW terms it would be a non-hostile sprite, which follows you, and attacks enemies - if it's not easy to aim at foes it could also just be a traveling hitbox that they can run into, or spawn the occasional fireball in a random direction.
I started working on one for my hack which I'll post for review separately once I work out the kinks. The movement code is still very wonky, so that's what I have to do next (it's originally based on the Stalking Goomba and I'm still figuring out the movement patterns I can get it to perform - the bit at the end where it flies all over the place because I moved a little bit is what I'm working on reducing)
Okay NOW it's really fun to play with. Turning down its aggression even slightly unfortunately sometimes causes it to indefinitely orbit sprites, so I'm trying to find a way to interrupt that, maybe just with a random movement. Tinkering with the speed settings even in small amounts can cause REALLY erratic results, such as going off screen and wrapping around to the other side with even a slight boost in speed (to catch up to Mario) or moving too slowly to even stay apace with Mario at all.
I could see this general concept being useful in casual hacks as well as some devious kaizo situations (like it eats a sprite before you can jump on it)
So far the customization options are:
-Amount of time it takes to "swallow" a sprite (so it will hold it in its mouth and go back to following Mario until it does so)
-Amount of frames it waits between updating its speed (which controls its movement accuracy)
-Whether it can eat inedible sprites (anything Yoshi can't swallow)
Both are depicted below as set to 00 which results in very aggressive behavior.
I also would like to set up a progressive reward system for eating - like it eats five things and then pops out a powerup like a Yoshi berry scenario. And I'll probably see if I can incorporate a timer or an "eats a certain amount then dies" setting.
Looking at tutorials and the manual it seems the only means of actually hearing newly-made SFX is by booting up the actual ROM after insertion via AddMusick. Is there a better method? AddMusick has a play button for music but not sounds - given that most of the sounds I've looked at are very simplistic hex strings I'd think it would be fairly simple to develop a preview option?
Specifically, my own project. I've been perusing all.log and have been able to use it to find hijacks for patches, and that got me to wondering how I might go about producing a similar disassembly for my own modded ROM?
I could do a side by side with the original and look at what's been changed, etc
Trying to decipher what I need to do to check the various statuses as listed in the wiki:
Code
Player blocked status - Used to check if player is blocked in a certain direction. Format: SxxMUDLR
The M bit means that the player is in the middle of a block.
The S bit indicates that the player is touching the side of the screens while horizontal screen scrolling is disabled.
UDLR = up, down, left, right (contact with walls).
L is checked each 4 frames when the player have negative X speed. Others frames is zero.
R is checked each 4 frames when the player have positive X speed. Others frames is zero.
I know that
Code
LDA $77 : AND #$04
will check down, and 1 and 2 seem to check to the sides. What is the breakdown of how to use the bits listed?
Apologies if this has already been answered somewhere, but I couldn't find a very straightforward answer. I see the Leaf Shield uses a hidden follower sprite that watches for a button press, and presumably uses %SpawnSprite() - which I have used in my sprites to success. But say I want an ability inserted that causes me to spawn, I dunno, a koopa when I press R (this is actually a summon ability for the pet sprites I am working on) - what would be the safest and cleanest way to do this? I can find and use hijacks so I'm not afraid to try and whip up a patch.
Thanks, you both were a huge help
*Sigh* I feel like I never stop asking questions at this point. I'm just trying to check the distance between a sprite and another sprite (not Mario) to check whether the sprite is within a certain X proximity. This is in a Sprite's own code (a friendly sprite that will enact certain behaviors if a hostile sprite is within X range of it). I have successfully modified %SubHorzPos() and %SubVertPos() to enable a sprite to know the direction of another sprite (for chasing that sprite, for instance), but getting the difference between two sprite coordinate sets is eluding me. Something to do with processor flags it looks like?
Originally posted by Koopster
It would be helpful if you posted your modified versions of these subroutines so we can figure out what's wrong with them.
The way to do it would roam about replacing Mario's coordinate addresses with the second sprite's. However, since sprite tables are indexed, you'll need the second sprite's index in another register (Y) to fetch them, and since SubHorzPos and SubVertPos natively use Y for the direction this may be where your conflict is coming from. But again, your code is crucial here; this is just a guess.
Got it. This is what I use in these sprites instead of SubHorzPos, for instance. A is loaded with the sprite index or 0 if the comparison is with Mario. It's good enough to get the direction from one sprite to another but that's about it.
Code
?main:
BEQ Mario
TAY
TargetSprite:
STZ $01 ;original uses Y for the direction, we put it here in scratch
LDA !E4,y
SEC
SBC !E4,x
STA $0E
LDA !14E0,y
SBC !14E0,x
STA $0F
BPL +
INC $01
LDY $01
RTL
+ LDY $01
JMP ?+
Mario:
LDY #$00 ;put 00 in Y
LDA $94 ;Mario x position
SEC
SBC !E4,x ;Sprite x position, low byte
STA $0E ;Distance
LDA $95 ;Mario x position
SBC !14E0,x ;Sprite x position, high byte
STA $0F
BPL ?+
INY
?+
RTL
Good point on the #$00. I reworked it so that it makes more sense (LDA #$FF for Mario instead) and now it's detecting the distance I'm looking for. I think I was only getting the correct results when the originating sprite was to the left and the checked sprite to the right - it wasn't checking absolute distance. So this is what I have. In the background I store Y into $05 before running (the original implementation returns Y as the direction) and then restore it after.
Code
; A = FF if Mario is the target
; A = sprite index if another sprite is the target
; Output: Y = direction
;use $00 as 16-bit X for Mario or "Myself" sprite
;use $02 as 16-bit X for Target or "Myself" sprite
;X should be loaded as the originating sprite
;store Y
?main:
CMP #$FF
BEQ Mario
TAY
Target:
LDA !E4,x
STA $00
LDA !14E0,x
STA $01
LDA !E4,y
STA $02
LDA !14E0,y
STA $03
JMP Compare
Mario:
LDA $94
STA $00
LDA $95
STA $01
LDA !E4,x
STA $02
LDA !14E0,x
STA $03
Compare:
LDY #$00
REP #$20
LDA $00
CMP $02
BCS .bigger ;Origin bigger means sprite is to left
.smaller:
LDA $02
SEC
SBC $00
STA $0D
INY
JMP ?+
.bigger:
LDA $00
SEC
SBC $02
STA $0D
?+
SEP #$20
RTL