I think it also has to do with the more recent popularity of speedrun streams too, since both Kaizo hacks and (most) speedruns involve a lot of involved glitches/techniques that are commonly seen in speedruns. So I guess the two communities overlapped.
It's a little easter egg of LM, it allows for you to effectively paste an image into Map16, so if you want more colors and less fighting-against YY-CHR, this might be a viable option.
Definitely recommend copy & pasting your rom prior since, at least for me, I screw it up the first couple times.
Originally posted by Golden Yoshi
Name: Portable TNT with Flash Before Explosion
Type: Sprite
Description: Can I get an edit of this sprite with the addition that it flashes (similar to a Bob-Omb) before exploding?
Added some defines for how fast / when it starts blinking too.
Oh, yeah my bad, I should've elaborated. If you use LM's easter egg thing you should put your graphics on layer 1. Maybe plop some ExGFX on one constant layer and have any foreground you need on the other layer (you'll be short a background though, of course)
Another thing I could say about YY-CHR, is that if you copy the contents of GFX28/29 from YY-CHR into ms paint, edit it and paste it back into YY-CHR, you can fix the colors /relatively/ quickly by selecting the entire space and pressing CTRL + R. Helps get around some of YY-CHR's crustiness and works fine enough for me at least.
There is a way to make lava stay on screen while the screen moves. You can do this by adding lava on 'layer 2'.
Try this:
1. Click the "change properties in header" icon (looks like Mario's head)
2. Change 'SNES Registers and Level Modes' to 02.
3. Click the 'change other properties' icon (the green icon near Mario's head)
4. Change 'Layer 2 (BG) scrolling rate' to "H scroll: None V scroll: none"
5. Click the yellow ground icon (its next to the green shell)
6. Place the lava in the level
Note: When using layer 2, you can not have a background.
I think this is what you want. And your English is fine, no worries! I hope this helps.
Originally posted by Aram
(...) A level-specific patch that whenever you play a song in a level, but don't that song in the next level, but put said song again in the next level without restarting the whole song again and play where it left off.
As I understand it, you start a level with Song A. Then, lets say you go through a pipe and it plays Song B, then you enter a third pipe to a third level and song A plays again, and what you want is for it to continue to play song A from where it originally left off.
I'm not going to claim this yet, since it might be out of my skill, but I'll give it a shot. I'm thinking this might be doable via some a sound effect to tell the SPC to change $40/$41:
Code
$0030~003F RAM - 2bytes per chan. points to next (current?) music data byte for each channel
$0040~0041 RAM - Points to music data. Roughly corresponds to "current measure"
$0042 RAM - Dec by 1 each time song loops. If FF, never decreases. Music stops at 0.
$0043 RAM - Global transposition value. Negative values work.
If not, I'm guessing you want this because you're using a song with an intro you don't want to repeat. Alternatively you could have 2 songs in addmusic, one with the intro and one without, and just have the later level use the intro-less song. Assuming that's what you're going for.
EDIT: Wrote an UberASM routine to store ARAM $30-$46 (and variations) to free ARAM on level change, and vice versa on level load. Didn't work out, seems the ARAM values are move involved than just setting the position in the song. I'm stumped.
Request Name: Mario/Yoshi Damage Fix
Description: Fixes the damage type that is affected by Mario on Yoshi when interacting with Dino Torch Horizontal Flames, Wigglers, Mega Mole on normal ground, and harmful tiles when touched by side or upside down.
I'll claim this one. I actually already have a working patch, but I used some code from Koopster to make it SA-1 compatible (some weird Yoshi pointer thing) so I want to ask them for permission before submitting it.
None that I know of, but I can think of a quick way to do this with UberASM as a level code. Something like this:
Code
main:
LDA $187A|!addr ; \ If not riding yoshi..
BEQ + ; / Skip
STZ $148F|!addr ; Force Mario to be empty handed
+
Or as a patch probably something like this:
Code
!addr = $0000
if read1($00FFD5) == $23
sa1rom
!addr = $6000
endif
org $008650 ; Controller data update or something
NOP ; Just needed something that runs every frame
autoclean JSL FiveFingerDiscount
freedata
FiveFingerDiscount:
LDA $187A|!addr ; \ If not riding yoshi..
BEQ + ; / Skip
STZ $148F|!addr ; Force Mario to be empty handed
+
LDA $4218|!addr ; \ Replace the stuff I hijacked over
AND #$F0 ; /
RTL ; Return
Probably better spots to hijack as this just needs to run every frame, but that'll be a quick-fix solution to what you want.
Unless STZing the carry flag doesn't cut it but I recall this works. Didn't test the code above, but that should do it.
Hope this helps!
(restricted)
Hey! So was looking through tcrf and saw this thing on there. And I was thinking like, It'd be funny to implement this into SMW.
So far I have this, just a scrolling bullet, no collision or polish or anything like that:
Curious to hear your guys thoughts/suggestions on how this thing should work!
Also it's file is called Killer.scr, fitting lol.
Originally posted by Ondore's Lies
images
Wow, that's got to be like one of the nicest overworlds I've seen. Especially like the small details like the camping site. I'm hype for this!
Hey, so I have a layer 3 background that I want to give collision. My plan was to do something broadphase to narrowphase, using axis-aligned bounding box (aka rectangles) intersection between the background's position and Mario, followed by a narrowphase where I do some cross products to handle the slopes (testing which side Mario is on the slope's line)
Ignoring the narrow phase for now, I can't seem to get my AABB-AABB intersection to function.
For reference here is the layer 3 background:
I'm using a custom sprite to handle the functionality of the layer 3 background.
Here is my subroutine for testing AABB-AABB
Code
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Player's AABB-AABB intersection test
; $00, $01 X position of 2nd AABB's X position (within the screen)
; $02, $03 Same thing but for the Y position
; $04 : width
; $05 : height
; CLC = no collision, SEC = collision
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; 7E = mario's X (2b), 80 = mario's Y (2b)
AABBTest:
; Put Mario's width, height into $06, $07
LDA #$10
STA $06
STA $07
LDA $19
BEQ +
LDA #$20
STA $07
+
; TODO: Might have to check for yoshi and add #$10 to $07
LDA $04 ; \ Sum of widths
CLC ; |
ADC $06 ; |
STA $09 ; |
STZ $08 ; /
LDA $05 ; \ Sum of heights
CLC ; |
ADC $07 ; |
STA $0B ; |
STZ $0A ; /
REP #$20
LDA $00 ; \ Diference in X positions then * 2
SEC ; |
SBC $7E ; |
ASL ; /
CMP $08
BCS NoIntersection
LDA $02 ; \ Diference in Y positions then * 2
SEC ; |
SBC $80 ; |
ASL ; /
CMP $0A
BCS NoIntersection
SEC
BRA +
NoIntersection:
CLC
+
SEP #$20
RTS
And I call this subroutine as such
Code
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Collision code (oh god)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Check if mario is within an AABB over the bullet
LDA #$F0 ; \ 15 tiles
STA $04 ; /
LDA #$B0 ; \ 11 tiles
STA $05 ; /
REP #$20
LDA $22
CLC
ADC #$00D0 ; shift right (left?) 14 tiles
STA $00
LDA $24
CLC
ADC #$00F0
STA $02
SEP #$20
JSR AABBTest
BCC Return
;Todo: test front for angles (crossprod routine)
So basically a separating axis theorem approach to rect-rect intersection. Not sure what the issue is, honestly I suspect that my understanding of layer 3's position is just wrong outright.
If anyone has any good ideas on why this code is broken, or even a potential concept for a better approach, I'd love to hear! I'm stumped..
Thanks in advance!
Edit: Should mention, in the subroutines I wrote the Layer 3's rectangle position/width/height are fed in through scratch ram (as seen in the comments) and the other rectangle is based off Mario's position, width of #$10 and height #$10/#$20 depending on powerup.
Agreed, hack 1 2 3 but call it 1 2 2 2. Best named hack series ever haha.
Maybe even Hack 1 2 2 II just to be obnoxious.
Originally posted by monkey03297
Name: Bigger Timer Type: Patch Description: Made the timer using big number. References:
Name: Pink triangle... fix?
Type: Patch
Description: A patch that makes so you can use the pink triangle on any (solid) block without using tile 1EB.
That's "not possible" with SMW as-is. Really it's not. The best way if you *were* actually to do it would be to have a hijack do a pre-check before block collision with feet collision shifted up 1px (basically always apply a slope-assist by default) and if the map16 you lookup isn't a triangle shift the position back to normal. But that's so much extra processing. Just stick a slope assist where it's needed. I know it's annoying, but that's really better than making smw pretend there's a slope-assist under everything. (Given that, nobody's probably going to touch this request unless you can point out a use-case other than convenience).
Out of curiosity, I toyed around the idea of making a block that does this. Didn't get far, or really try as you mentioned it's a bit redundant, but I made this small block code:
Lil funky when you stand towards the low end of the triangle, and Yoshi is still a bit jank. Maybe someone can expand on this to make it work like a purple triangle proper. It's a start at least.
===============================================
EDIT: Did a little more messing around, was able to get these blocks to almost operate like purple triangles without the helper tile. There are a couple caveats, namely that they still need some sort of solid tile (doesn't matter which as long as it acts solid) underneath or Mario can fall through the thin side of the triangle, furthermore, Yoshi still refuses somewhat to get on top of the block, but if the player just runs into it it'll work more or less as intended (or at least the whole thing happens so fast they wont notice yoshi slightly clipping inside).
Hopefully someone to elaborate on this and make it less finnicky.
Originally posted by Rykon-V73
Since my request was forgotten or ignored, I decided to post a different request. I hope this is doable:
Name: Giant 32x32 Piranha Plant Type: Sprite Description: A giant 32x32 piranha plant that behaves like a regular piranha plant. Setting the extra bit makes it upside-down. It can also do other things depending on the extra byte. Extra byte 1: Enable fireball spit: 1-yes, 0-no; Extra byte 2: Spite a certain number of fireballs if Extra byte 1 is active; Extra byte 3: Enable rock spit: 1-yes, 0-no; Extra byte 4: Sprite number for rock; Extra byte 5: Spits a certain number of rocks set in Extra byte 4 if Extra byte 3 is set. References:This is equipped with proper GFX.
Is this what you're looking for? It seems it's meant for a 3 tile wide pipe, and I don't think it has the projectile functionality either. Figured I'd ask before going for it.
