Banner
Views: 843,304,140
Time:
22 users online: chickaDEE Magazine, Daizo Dee Von, Darolac, DeppySlide, edgar, elieltonl, Hunter-,  JamesD28, JayDee, kebabchilla, Lumy, marioman07, Moichumoi, MORC, Nirv, Ralshi02, savagecabbage, Super_Mike, Truxton, VixTheVixen, XGAMER 2009, Yagami - Guests: 78 - Bots: 113 Users: 46,327 (2,857 active)
Latest: marioman07
Tip: Remember to remove the original SMW events, both layer 2 and layer 1, when making a new overworld.Not logged in.
Posts by SchwerMuta
SchwerMuta's Profile - Posts by SchwerMuta
Pages: « 1 2 »
Offending Background

I downloaded this for use recently, got it set up and even improved on it a bit... unfortunately, it was only after this that I realized that it uses colors that the status bar uses. In order to look good, it has to overwrite the status bar colors, destroying it in the process. This is even in direct violation of one of the "tips of the day" shown at the top of the site:

"Don't overwrite the status bar colors with the background's palette."

I also downloaded this one and found that it has a similar problem, although not nearly as unusable. (It only overwrites three colors instead of all ten.)

I have to wonder how many more backgrounds by this creator have this problem, or if any others have the same problem overall...
It's kind of unfortunate that there's so many ExGFX lacking proper files or not following basic guidelines. A recent BG file I downloaded lacked every file but the binary itself... it was rather pitiful.

Anyways I used Lightvayne's suggestion and just simply nixed a few objects that used the palette rows I replaced so now I've worked around the issue, at least for that level. Thanks.
I use a few custom blocks in my hack, and they worked fine when I first put them in, but after a while I noticed that they stopped working exactly correct. That is, the blocks I'm using have their 'Act As' setting set to 25 (blank tile) and their code sets them to 130 (cement block) under certain circumstances. (Like On/Off blocks that are only solid depending on the On/Off setting) They used to imitate the solidity of the cement block well until suddenly their side collisions started working incorrectly, where Mario would go through the side of the block and promptly be ejected downwards instead of sideways like he's supposed to. The bug was only discovered very long after I had last tested them so there's a large variety of things that could be wrong, but at the same time I feel as if it's also something simple and easy that I'm just missing because I'm not super hyper pro at hacking yet, so I figured I'd ask here before going through a long trial and error process of backtracking through the two or so months of hacking I've done since the last test.

tl;dr: Custom blocks that are solid but don't Act As 130 have faulty side collision, am I just being dumb?
I downloaded a disassembly of the "Dark Room Spotlight" (which is informally known as the disco ball) and while the graphic drawing routine is compact, I'm too poor in ASM to really make enough sense of it to do what I want, and rather then spend a few hours looking through ASM guides just to do one little thing, I thought I'd ask here, if that's okay.

How would I be able to make the sprite animate slower? As well as not cycle through every sprite palette and stick to one. I'm totally okay with inserting an edit of the disassembly as a custom sprite but if it's possible to do with some hex editing on the base sprite (doubtful) then that's cool too. Thanks.
Thanks! That's simple enough to remember. I'd still like to know how to stop it from cycling through several palettes though, as it's an annoying habit of a couple SMW sprites I've seen (the throw block sprite is a particularly egregious example that I've found frustrating whenever I wanted to replace the sprite)
Thank you very much! The sprite works exactly how I wanted it to now, and I've learned a couple valuable things too. Thanks a bunch.
Look out someone's making another b(l)a(n)d super mario world hack.

Super Mario World has been around since my child hood. Super Mario Bros. 1 was my very first video game and I grew up on Super Mario Bros 3 and thought it was the best thing ever. I really don't remember when I first played Super Mario World but it wasn't until a long, long while after I played Super Mario Bros 3 (at that point I already had Super Mario All Stars) However, probably over a decade later after having played it, I'm still playing it, and still loving it. I don't think I'll ever outgrow classic Mario platforming. That's probably why I liked SMW hacks so much. I'd play a ton of them, even long after normal people likely would have gotten bored since a lot of hacks are still basically Super Mario World.

I've made no attempt to really set myself apart to that end, because when it comes down to it, that's what I'm here for; classic Mario platforming. Back during a time when we were actually excited to rescue the Princess again. Back during a time when we could separate levels by world and the levels told you what world they belonged to. Back during a time where there weren't any funky control gimmicks, weird goals or anything that distracted you from the overall feel that it was a Mario game, nothing more, nothing less. Just straight up run, jump, shoot fireballs, swing your cape, stomp on enemies and stuff like that. I've made this hack with that in mind, it's nothing but classic Mario platforming. Don't expect anything flashy, both on part of that and on part of my general inexperience and laziness in hacking.

That said, on with the screenshots.











There's custom music, blocks, sprites and graphics, yes, so it's a chocolate hack more or less, but there are still quite a lot of vanilla aspects of it left in, though I've tried hard to make sure none of the new stuff doesn't clash with SMW's own included content. Of course, the overworld and level layouts are all entirely new.
Although there's quite a few level layout reuses from my old hack, but since no one played it from what I assume, I figured it was alright to take from it what I felt was good enough to revamp.


Click here to download the IPS patch.

I have to make it known that this is a work in progress and is quite much in beta. Me and a friend have tested it mostly but a lot of it still goes untested as it isn't wholly finished yet. It works, but there might be some things that don't work as intended. It's also not finished; it only goes up to world 7.

Known issues:
* The collision detection on some custom blocks (special breakable blocks, ON/OFF blocks) is a little wonky. Super Mario will have faulty collision when his head collides with the side of one of these blocks and he'll go through it even if it's supposed to be solid. I don't know what's caused this since it cropped up on upgrading Lunar Magic.
* Graphics rendering in vertical levels freaks out sometimes. This is most notable in the second part of the "Lighthouse" level. I have no clue what causes this at all, as it feels very random.
* If you stay on the main overworld too long, the game crashes. I'm certain I know what causes this, but I haven't felt the need to remove the patch that's caused it because you have to stay on the overworld a rather long time for it to occur as far as I know, so I'm considering looking for a fix rather then remove the patch straight up. (I believe it is caused by this patch.)
* Star Road is not only unfinished but the way I tried dealing with it doesn't work properly; it's supposed to work similarly to Demo World in that clearing a normal exit reveals a path and clearing the secret exit reveals a star road that takes you back. (I did this because I was running out of event and level numbers) However, I made a mistake and the secret exit enables paths instead of keeping you where you are. I've fixed this, but only after having already made the patch, uploaded it and made this post. I'm not gonna bother uploading the fix since it's minor and non-fatal anyways.
* The message box at the end of the demo (after Larry's Castle) doesn't work, probably due to an absent minded mistake on my part as I whipped up that filler level at 4 in the morning.
* The bonus game is kind of nonexistant. I still haven't figured out what I'm actually gonna do with it yet in all honesty.
* The Star still procs score increase + 1-ups against certain enemies (mainly custom ones) even though I introduced a patch to remove that funcationality. I haven't gotten around to fixing this one even though I know how to.

I think that's about it. Note that this hack was only tested on ZSNES since I haven't gotten anywhere near a fully finished state yet. However, if you download and play, then I thank you for at least trying it out. The most I'll ask is that if you find a bug that isn't already shown on this post, then you post it here and tell me. Although if you know how to fix the bugs that I haven't found out how to yet, that would be excellent and I would love you forever.
I thought I'd post this video too while I'm at it. It's not in the current public demo but it's something I felt like showing off a bit.
Yeah, I'm making another thread if you spied my other one in the WIP boards. I'm just a lurker (a bad one at that) so I'm not really sure if I'm doing it right, but nonetheless here it goes. So that I don't needlessly repeat myself, I may as well quote the opening paragraphs from my original post to explain.

Originally posted by SchwerMuta
Super Mario World has been around since my child hood. Super Mario Bros. 1 was my very first video game and I grew up on Super Mario Bros 3 and thought it was the best thing ever. I really don't remember when I first played Super Mario World but it wasn't until a long, long while after I played Super Mario Bros 3 (at that point I already had Super Mario All Stars) However, probably over a decade later after having played it, I'm still playing it, and still loving it. I don't think I'll ever outgrow classic Mario platforming. That's probably why I liked SMW hacks so much. I'd play a ton of them, even long after normal people likely would have gotten bored since a lot of hacks are still basically Super Mario World.

I've made no attempt to really set myself apart to that end, because when it comes down to it, that's what I'm here for; classic Mario platforming. Back during a time when we were actually excited to rescue the Princess again. Back during a time when we could separate levels by world and the levels told you what world they belonged to. Back during a time where there weren't any funky control gimmicks, weird goals or anything that distracted you from the overall feel that it was a Mario game, nothing more, nothing less. Just straight up run, jump, shoot fireballs, swing your cape, stomp on enemies and stuff like that. I've made this hack with that in mind, it's nothing but classic Mario platforming. Don't expect anything flashy, both on part of that and on part of my general inexperience and laziness in hacking.


I've been working rather hard on this hack, fine tuning it time and time again, designing levels that always introduce something new or do something difference with each pass, trying to make it visually pleasing without including too many ExGFX files (most you'll see is about a page worth of foreground blocks, a selection of interesting backgrounds and a slew of different sprites based on the new ones I've inserted.) It's went through gratuitous testing both on my part and my beloved friends who've been beta testing it (with the promise of cookies) and it's starting to approach a presentable state now. That said, I haven't really gotten the time to get any new screenshots or videos (I had to rush the title screen to get it out before I have to leave) but here are the ones I got from the other thread:





Video of a later level I designed.

Click here to download the IPS patch.

It currently goes up to 'World 9.' World 9 is a secret world that you must find via star road or the red switch palace. Disregarding World 9, you can go through the entire main game to World 8 up until Bowser's Castle, which I haven't finished yet. Currently, apart from Bowser's Castle, all I have left to do is the Star Road levels (currently they're placeholders), the 'Special World' that you unlock by finding a secret exit later on in World 9 and, if I really decide to do it, replacing the currently boring SMW bosses with custom ones if I can manage it.

Originally posted by SchwerMuta
Known issues:
* The collision detection on some custom blocks (special breakable blocks, ON/OFF blocks) is a little wonky. Super Mario will have faulty collision when his head collides with the side of one of these blocks and he'll go through it even if it's supposed to be solid. I don't know what's caused this since it cropped up on upgrading Lunar Magic.
* Graphics rendering in vertical levels freaks out sometimes. This is most notable in the second part of the "Lighthouse" level. I have no clue what causes this at all, as it feels very random.
* If you stay on the main overworld too long, the game crashes. I'm certain I know what causes this, but I haven't felt the need to remove the patch that's caused it because you have to stay on the overworld a rather long time for it to occur as far as I know, so I'm considering looking for a fix rather then remove the patch straight up. (I believe it is caused by this patch.)
* The bonus game is kind of nonexistant. I still haven't figured out what I'm actually gonna do with it yet in all honesty.
* The Star still procs score increase + 1-ups against certain enemies (mainly custom ones) even though I introduced a patch to remove that funcationality. I haven't gotten around to fixing this one even though I know how to.


The bugs still more or less apply. If I can't figure out how to fix some of them I might end up having to carry over some stuff to a new ROM, something I really don't want to do since, like an idiot, there's a bunch of changes I never logged (mainly stuff that I did through hex editing) but for all I know, some of these bugs (the vertical level rendering problem in particular) might just be ZSNES acting up as I haven't yet tested this hack in SNES9X or bsnes.

That's about all I have to say about it. Thanks for trying out the hack if you decide to. I'll probably update my WIP thread next time or if I get that far without deciding to post an update, just straight up release it to the hacks section.
I've been dealing with this bug for quite some time and even when I use the restore function on lunar magic or use a clean ROM, the bug still persists, making me think that something's wrong with the custom blocks in question. It has to do with their collision behavior regarding Super Mario.



When Mario bumps his head into a block (a solid one, like 130, the cement block) while big, he stops at the side of the block. This is how it's supposed to be.



But custom blocks that have an 'Acts like' setting of 25 with code that makes them solid (like this block that's only solid when the ON/OFF switch is set to ON) don't stop Mario like that. He can freely walk up to half way into the block if it isn't foot level with him.



It gets worse. With a solid block directly under Mario, a solid block head level with him and nothing directly in front and below him, he's still stopped properly.



Replace the solid blocks with the aforementioned custom blocks and the higher block tries to push Mario down while the lower block tries pushing Mario forward when he's pushed down into it... resulting in a highly unfortunate case of Mario being forced through a gap he should be too big to fit through!

The most extreme case happens when you combine these kinds of custom blocks with the purple triangle... when Mario tries to run up the custom blocks like a wall, the game outright denies him and he's pushed INTO the blocks, which then proceed to push Mario DOWN... typically to his doom.

I've redownloaded these blocks and tried various others and they all end the same, even though their code is extremely simple, the game seems to screw it up very easily. Has anyone encountered anything like this? Is there a fix for this? Or should I just try editing the blocks to 'reverse' their behavior so that I can use 130 as their Acts Like setting? Or would that not work? Thanks for any responses.
This block here is the one I used in the screenshots, though pretty much any custom block whose Acts Like setting isn't explicitly 130 suffers from this problem I've seen.

Code
JMP MarioBelow : JMP MarioAbove : JMP MarioSide : JMP SpriteV : JMP SpriteH : JMP MarioCape : JMP MarioFireBall

MarioAbove:
MarioBelow:
MarioSide:
SpriteV:
SpriteH:
MarioCape:
MarioFireBall:
	LDA $14AF
	BNE Return
	LDY #$01	;act like tile 130
	LDA #$30
	STA $1693

Return:
	RTL


This is the relevant code. This is pretty much half of what that download consists of, with the other half being pretty much the same thing, but replacing the BNE with BEQ (for the opposite effect) The block is supposed to be solid when the ON/OFF switch is ON but the Acts Like setting is supposed to be 25.
Thanks a bunch! That solved it. Go me being a complete noob at this asm malarky still. I guess we all start somewhere.
Looking for someone to test my hack. It's more or less complete, I just don't really have time to go through it multiple times in different emulators. (That and I can't possibly think of everything on how to break the game)

An old thread I made for it can be found here, in case you want a basic description of what to expect.

The newest version which I completed (and isn't found in that thread) can be found here.

I will give credit as a tester if anyone reports any bugs or that it's in working order on bsnes or snes9x. Thanks.
I'm editing a sprite where it's range of speeds vary depending on the Extra Property Byte, making several different sprites that more or less use the same code but behave differently because of the differently referenced tables. I may not be doing it right though, and I'm most certainly overworking it; I'm getting a 'positive branch too long' error with my 'expert handiwork' that you can see here:

Code
	LDA $157C,x
	BEQ Right
	LDA $7FAB28,x
	CMP #$00
	BEQ ATbl1
	LDA $7FAB28,x
	CMP #$01
	BEQ BTbl1
	LDA $7FAB28,x
	CMP #$02
	BEQ CTbl1
	LDA $7FAB28,x
	CMP #$03
	BEQ DTbl1
	LDA $7FAB28,x
	CMP #$04
	BEQ ETbl1
	LDA $7FAB28,x
	CMP #$05
	BEQ FTbl1
	LDA $7FAB28,x
	CMP #$06
	BEQ GTbl1
AfterCmp1:
	EOR #$FF
	INC A
	STA $1626;,y
	LDA $1626;,y
	BRA SetSpeed
Right:
	LDA $7FAB28,x
	CMP #$00
	BEQ ATbl2
	LDA $7FAB28,x
	CMP #$01
	BEQ BTbl2
	LDA $7FAB28,x
	CMP #$02
	BEQ CTbl2
	LDA $7FAB28,x
	CMP #$03
	BEQ DTbl2
	LDA $7FAB28,x
	CMP #$04
	BEQ ETbl2
	LDA $7FAB28,x
	CMP #$05
	BEQ FTbl2
	LDA $7FAB28,x
	CMP #$06
	BEQ GTbl2
SetSpeed:
	STA $B6,x
	LDA $7F998F
	BNE UpdatePos
	BRA Moving

ATbl1:
	LDA Tbl1R,y	
	JMP AfterCmp1

BTbl1:
	LDA Tbl2R,y	
	JMP AfterCmp1

CTbl1:
	LDA Tbl3R,y
	JMP AfterCmp1

DTbl1:
	LDA Tbl4R,y
	JMP AfterCmp1

ETbl1:
	LDA Tbl5R,y
	JMP AfterCmp1

FTbl1:
	LDA Tbl6R,y
	JMP AfterCmp1

GTbl1:
	LDA Tbl7R,y
	JMP AfterCmp1

ATbl2:
	LDA Tbl1R,y	
	JMP SetSpeed

BTbl2:
	LDA Tbl2R,y	
	JMP SetSpeed

CTbl2:
	LDA Tbl3R,y
	JMP SetSpeed

DTbl2:
	LDA Tbl4R,y
	JMP SetSpeed

ETbl2:
	LDA Tbl5R,y
	JMP SetSpeed

FTbl2:
	LDA Tbl6R,y
	JMP SetSpeed

GTbl2:
	LDA Tbl7R,y
	JMP SetSpeed


I haven't really gotten around to editing the other tables yet since I was gonna do that after testing it but these are all the tables nonetheless:

Code
Tbl1R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11
Tbl2R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11
Tbl3R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11
Tbl4R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11
Tbl5R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11
Tbl6R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11
Tbl7R:  db $00,$11,$13,$15,$15,$13,$11,$11,$11


As you can see, it's a complete mess. Knowing how I can check the Extra Property Byte without being so messy (and whether or not I'm even doing it right) would be a godsend to me at this point. I'm a complete and utter noob when it comes to ASM so you might have to explain it in layman's terms. Thanks in advance though.
(restricted)
After a little tweaking, I got it to work and it runs very magnificently, and you have my thanks! I just have one little question for my grand adventure into further ASM learning. I was taught that LDA $addr,x means to load that address indexed by the X register. I noticed that when I left out the ,x out of LDA $7FAB28,x then it would load from a slightly different position, but it works as expected with it tacked on. I don't even know what the X register contains at this point as it seems to be out of the scope of the sprite itself. Should I always have it on regardless of what the X register contains? Or are there periods where I should leave it out or pull from the stack before doing something like that?
Hello, I'm having trouble with timed events that rely on a RAM address for it's timer. Specifically, I'm trying to get a sprite to copy the behavior of the popular Hammer Bro sprite, where it displays it's hammer for a brief moment before actually throwing it. After much deliberation, I came to my final dead end and realized that no matter how much recoding I did, the only revision of my sprite that worked anymore was before I started all this to begin with.

In my latest revision, I'm using $1570 as my timer (!HammerTimer) and decrementing it manually, and $1534 for the flag (!ThrowCheck) that checks if it should display the sprite. Neither of these addresses are used elsewhere in the sprite as far as I'm concerned and I'm indexing them both by x as they should be. But for some reason, much of the sprite code somehow goes ignore upon spawning, including collision with Mario, until the sprite goes off screen and then comes back on, in which case it works fine until it's destroyed, at which point the game hangs.

This is the code I use to decrement the timer and set the flag (where ... is where other timer decrementing code is that's short but irrelevant):
Code
	LDA !HammerTimer,x
	BEQ +
	DEC !HammerTimer,x
+
...
	LDA !HammerTimer,x
	CMP #$10
	BNE DontSetHammer
	LDA #$01
	STA !ThrowCheck,x
DontSetHammer:
	RTS


This is where the timer is used to determine when to throw a hammer (where ThrowHammer is a label for some basic spawn extended sprite code):
Code
	LDA !HammerTimer,x
	CMP #$00
	BEQ GetHammer
	RTS
GetHammer:
	LDA #$38
	STA !HammerTimer,x
	STZ !ThrowCheck,x
	JMP ThrowHammer


And this is the graphics routine, which I more or less lifted from mikeyk's Hammer Bro, though I looked through each command and understood it, and it even works correctly, so I can't believe it's really the problem:
Code
HAMMER_OFFSET:
	db $F6,$0A

	LDA !Flash,x
	CMP #$00
	BNE NO_SHOW
	LDA !ThrowCheck,x
	CMP #$01
	BNE NO_SHOW

	PHX

	LDA $00
	LDX $02
	CLC
	ADC HAMMER_OFFSET,x
	STA $0300,y
	
	LDA $01                 ; \ tile y position = sprite y location ($01) + tile displacement
	CLC                     ;  |
	ADC #$F2
	STA $0301,y             ; /

	LDA #$6D                ; \ store tile
	STA $0302,y             ; / 

	PHX
	TYA                     ; \ get index to sprite property map ($460)...
	LSR A                   ; |    ...we use the sprite OAM index...
	LSR A                   ; |    ...and divide by 4 because a 16x16 tile is 4 8x8 tiles
	TAX                     ; | 
	LDA #$02
	STA $0460,x             ; /  
	PLX     

	LDA #$07 
	CPX #$00
	BNE NO_FLIP_HAMMER     
	ORA #$40
NO_FLIP_HAMMER:
	ORA $64                 ;  | put in level properties
	STA $0303,y             ; / store tile properties

	PLX
	INY                     ;  | increase index to sprite tile map ($300)...
	INY                     ;  |    ...we wrote 1 16x16 tile...
	INY                     ;  |    ...sprite OAM is 8x8...
	INY                     ;  |    ...so increment 4 times

	LDY #$02
	LDA #$04
	JSL $01B7B3
	RTS

NO_SHOW:
	LDY #$02                ; \ 02, because we didn't write to 460 yet
	LDA #$03                ;  | A = number of tiles drawn - 1
	JSL $01B7B3             ; / don't draw if offscreen
	RTS                     ; return


I also had an earlier revision where I didn't use a ThrowCheck flag, and instead just used this code at the beginning of the graphics routine:
Code
	LDA !HammerTimer,x
	CMP #$02
	BCC NO_SHOW
	CMP #$10
	BCS NO_SHOW


This worked better then the later revision where I used a check flag, but it was just outright refusing to branch; the hammer tile would just always display regardless of the state of the timer (which led me to believe that BCC and BCS aren't as simple as tutorials would lead you to believe)

I have no clue what's wrong, and I would really appreciate any help given for this. I've looked through mikeyk's code on multiple occasions but I don't seem to understand what I'm doing wrong. Thanks in advance.
The first code snippet is part of a subroutine that decrements all the timers I use in the sprite. The second code snippet is also part of a subroutine, and in fact the entire subroutine it comes from is just that snippet and the actual spawning of the hammer. The third code snippet is, as you guessed, only used for drawing the hammer itself and attaching it to the rest of the sprite, which is already drawn at that point, correctly might I add.

The sprite works fine with all those RTS commands there, as it's essentially the same thing in an earlier revision but with all references to the flag taken out, it just doesn't do the graphics writing any favors.

The actual asm file itself is rather huge as it's a boss script, and I haven't really organized it very well, so I'm probably going to clean it up before being forced to post it.
I misunderstood what you meant by 'already drawn.' It's already prepared and ready to be written to the OAM but not actually 'drawn drawn.' The JSL to $01B7B3 in NO_SHOW is the first time it's called if the hammer isn't drawn, and the graphic routine for the hammer has one for when it needs to be drawn. I was just trying to say that the sprite is already prepared and the code I posted just attaches the hammer to the prepared sprite and then draws all of it all at once, and it just draws the sprite without the hammer if displaying the hammer is skipped.

Originally posted by JackTheSpades
I did find another possible error though.
In your graphics routine, you pushed x on the stack twice (PHX), but you only pull it back one (PLX)

Unless you get it bakc elsewere, this will screw up all of the sprite's ram storege, where you index with X


Just looking at the code I posted I can see two PHX and two PLX commands so I have no idea what you're talking about.
I tried changing the RAM addresses I used before already but it produced the same exact results. Using JMP was intended in many places I put it in but I have tried replacing all of them with BRA and RTS... still nothing.

Even though the sprite displays just fine, removing the hammer from the graphics routine actually causes the sprite to work fine, without any errors and jamming the emulator CPU, so the error has to be there... but I can't see any obvious flaw in the code itself. That same exact code would run fine in any other sprite. I'm kind of clueless as to why it would be messing up.
Pages: « 1 2 »
SchwerMuta's Profile - Posts by SchwerMuta

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy