Banner
The Overworld Design Contest ends in
1 MONTH, 4 DAYS, 12 HOURS, 25 MINUTES AND 44 SECONDS
Views: 897,862,657
Time:
22 users online:  Anorakun, badrapppername, Bench-kun, BootaNoBijuu, Darkguii, ExONightZ, Fingolfin, Insanit, jardeson01,  MarioFanGamer, Mirann, Nao, NewPointless,  Ninja Boy,  NopeContest, pat94plus, Prestinator13, qantuum,  shovda, Shuttles, tobson, Zuluna - Guests: 87 - Bots: 120 Users: 50,377 (2,291 active)
Latest: hightower7
Tip: Use palettes that aren't difficult to look at. Clashing, overly-bright, or overly-dim colours may make your level difficult to play.
Not logged in.
Yoshifanatic's ASM Showoff
Forum Index - Sunken Ghost Ship - C3 Museum - Winter 2016 - Yoshifanatic's ASM Showoff
Pages: « 1 2 » Link
Originally posted by yoshifanatic

That's neat you tried creating a dynamic level loading routine as well. How far did you get with it?


I have most of the code that creates objects, and I'm more or less figuring out why what I have isn't working. I figure if I check some things the loading routine does and fix them, it will work fine (Like certain values have to be set, index registers, routines I didn't run, ect.)

--------------------
‎▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
‎―••~asuka over rei every day~••―
‎90% of teens smoke weed. if you're
‎part of the 10% put this in your sig
‎▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
Whoa, now here's an ASM prodigy who wasn't on my radar at all. #tb{'_'}

I've only skimmed through this thread and it's enough to make me gasp audbily - not to mention it's a great inspiration for my own, less advanced, projects.

Imagine me taking a humble bow right now.

--------------------


 
Originally posted by yoshifanatic
For example, did you know that the both Ninji Ceiling Fix and Rope Fix 1 are not necessary because simple hex edits can fix the bugs these patches fix, but better? The bug that the former patch fixes can be fixed by simply changing the byte at $03C36A from 04 to 0C. The latter can be fixed because the game actually does check to see if Mario touches a wall while climbing a line guided rope (it's at $01D9F3), it's just that it doesn't branch to the code where it disconnects Mario from the rope when he touches a wall (it branches to an RTS). Changing the byte at $01D9F8 so that the branch points to $01DA03 instead of $01DA09 will fix it.


Is it okay to submit these single byte bug fixes to the smwc tom map? Since these were discovered by you.

Speaking of looking at Smw's source code, are you planning to update the smwdisc after my update (the one with the bytes of the opcode not being displayed being fixed)? With more comments (I do this a lot on any of my asm stuff to keep in track), it makes it easier to modify smw. Lots of places were not commented.

--------------------
Give thanks to RPG hacker for working on Asar.
Wow

This looks good, hella good
Y'know what, you deserve this

*gives Yoshifanatic a chubby yoshi dakimakura*

Don't ask me why I had that lying around

--------------------
HackPortsASM"Uploader"

As a quick update guys, I've been working a little bit more on my dynamic sprite routine and I've fixed most of the bugs that were shown in the .gif of that. Well, except for the one where the mega mole glitches since I don't understand why that's happening, but anyway, here is a better .gif showing more sprites I've made dynamic:


Also, I've gotten AddmusicK to work with my modified source code ROM, and I've also gotten my improved version of Con's MSU-1 patch to cooperate with AddmusicK. It was as simple as making the SPC700 play a blank song when the MSU-1 plays a song and having the MSU-1 not attempt to play whatever song number the blank song (that way, it doesn't try to play a new song on the next frame) or the Nintendo Presents sound has (that way, the SMW samples get loaded into ARAM). Speaking of which, I'm going to be using the MSU-1 for the music in my kaizo hack, though I will include a normal soundtrack for those that can't or don't want to enable the MSU-1. Consider the MSU-1 soundtrack as a bonus feature. ;)

Lastly, I've decided to post an IPS patch of my modified source code ROM so you guys can see all the stuff I showed off here for yourself.

Link

A couple notes:

- The game over text won't show up if Mario dies, because I haven't integrated that into the source code ROM yet.

- Many sprites haven't been made dynamic yet, so they'll of course be glitched. All the sprites in the above .gif will show up correctly, and a few almost do (ex. For some reason, pitchin' chucks lose their head when they hold a baseball. I haven't figured out what causes it yet). A few, such as the koopa kids have been deleted from the ROM or replaced with a custom sprite.

- Sprite 12 is the Mario head sprite, 7C is a(n) (unfinished) save block, and 85 is a poison mushroom. These aren't normal custom sprites since they're handled through SMW's sprite table rather than the SpriteTool one, so you must spawn them the same way you would with an unused SMW sprite.

- Most of the titlescreen layer 3 won't show up because I disabled the IRQ from occurring in my attempts to disable the status bar. The file select stuff is still present, it will just be invisible.

- Mario's graphics can be glitched up when entering a level. This is because the game doesn't yet clear out a certain table on level load and thus thinks that Mario already has his graphics loaded when they were actually overwritten. Mario's graphics will fix themselves if he does a pose where his body and/or head is different from his standing frame. Also, some of Mario's poses will be glitched anyway because I haven't yet fixed them when I modified his graphics routine so it could handle Yoshi's animations.

- There are other miscellaneous glitches caused by some of the changes I made to the source code. Mostly graphical stuff though.


Anyway, onto the replies:
Originally posted by antimatterhunter
oh my god, if this kicks off, this will be the best thing ever! Go for it!!!


I'll make sure it will. ;) I'd like to see what kinds of interesting level designs people come up with when I eventually release a patch for this.

Originally posted by Mellonpizza
I have most of the code that creates objects, and I'm more or less figuring out why what I have isn't working. I figure if I check some things the loading routine does and fix them, it will work fine (Like certain values have to be set, index registers, routines I didn't run, ect.)



That's interesting. When I was making my optimized level loading code, I mainly just copied the existing code elsewhere, LM hijacks and all, and then optimized it as best as I could so it would take as little time as possible. I did learn a little bit of how it worked, but there is still some stuff I don't understand.

Also, here is a fun fact that I learned about the level load routine. If you paste as many direct map16 tiles into a level as you can and re-size them to their limit both horizontally and vertically and paste the max number of sprites allowed, then it will literally take 30 minutes for the level to load. Not even my optimized level loading routine could put a dent in that. O_o


Originally posted by WhiteYoshiEgg
Whoa, now here's an ASM prodigy who wasn't on my radar at all. #tb{'_'}

I've only skimmed through this thread and it's enough to make me gasp audbily - not to mention it's a great inspiration for my own, less advanced, projects.

Imagine me taking a humble bow right now.


I'm not surprised you might not have heard of me. I'm not the most active user here outside of the threads I've made and I don't go on the IRC either, so yeah. XD I probably should start being more active here now that I think about it...

Anyway, I'm glad to hear you liked what I had to show off, and good luck with whatever projects you're working on. :)

Originally posted by GreenHammerBro
Is it okay to submit these single byte bug fixes to the smwc tom map? Since these were discovered by you.

Speaking of looking at Smw's source code, are you planning to update the smwdisc after my update (the one with the bytes of the opcode not being displayed being fixed)? With more comments (I do this a lot on any of my asm stuff to keep in track), it makes it easier to modify smw. Lots of places were not commented.


You can submit those to the ROM map if you want.

Also, I wasn't planning on updating smwdisc, but I could help out a little with that.

Originally posted by Leomon
Wow

This looks good, hella good
Y'know what, you deserve this

*gives Yoshifanatic a chubby yoshi dakimakura*

Don't ask me why I had that lying around


Thanks. XD

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Question: is the dynamic loading over 1 frame? Spreading it across multiple would be an easy fix for the temporary freeze. Like, load a couple screens of objects per frame.

--------------------
‎▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
‎―••~asuka over rei every day~••―
‎90% of teens smoke weed. if you're
‎part of the 10% put this in your sig
‎▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
Originally posted by Mellonpizza
Question: is the dynamic loading over 1 frame? Spreading it across multiple would be an easy fix for the temporary freeze. Like, load a couple screens of objects per frame.


My dynamic level loading routine splits everything it has to load across multiple frames. It's set to load the level data all in one frame like in SMW (I did try to make the game load the level data across multiple frames, but I couldn't get it to work correctly), but unlike SMW, I made it do the sprite data on the next frame. That was one of the biggest improvements I was able to make to my dynamic level loading routine since SMW feels the need to not only load the sprite data, but also go through all the main sprite handling routines, including the ones in bank 2 which I don't think are even relevant. It's especially bad because those routines can be optimized better (ex. The game checks to see if a sprite exists in Slot N after a JSR, when it can do it before the JSR and save 12 cycles for each sprite that doesn't exist. Likewise, not only can this be applied to all the sprite handling routines in bank 2, but they can all be combined into a single routine where the game immediately goes to the next routine at the end of the previous one to get rid of a big ugly list of ~6 JSRs).

In the IPS patch I posted, the biggest source of lag is actually the graphics decompression, but using the improved LC_LZ2 patch in LM will remove pretty much all that lag (you can also reduce slowdown by having the new and old level share graphics files, since my routine checks to see if the same graphics file is loaded in a given slot in both the old and new level before it attempts to decompress it). I haven't integrated that into the source code ROM, but it can be applied with LM without issue. After that, the only lag that is left is the lag from the level loading, the length of which depends on how much data the game has to load for the new level, but is still faster than it takes SMW to load a level normally. I'll continue to find ways to speed it up so that it will load as quickly as possible without the help of the SA-1.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Just a quick update. I'm working on improving my dynamic level loading routine with Mellonpizza's suggestion in mind. With the way that I implemented the loading for the level data, it's going to lag more and more as you add objects and make them bigger, so I'm working on implementing a pre-loading system that will solve this issue.

Specifically, what is going to happen is that there will be two custom blocks that trigger the dynamic level loading. The second one works just like the dynamic level loading works now with a few differences while the first one sets a flag that tells the game to start pre-loading the level data for the new level (which level it is depends on what level number you define in a table that is indexed by both the current level number and the screen number the pre-load block is on). When Mario touches the first block, the game will start silently loading level data into the SRAM like it would normally at $7EC800 and $7FC800 though in order to reduce the lag, the game will only load one block per frame (this is because map16 objects that are at their max size cause the game to lag slightly even when only one is being loaded). Once it's done, touching the second block will cause the game to copy all the pre-loaded data to $7EC800 and $7FC800 as well as load the other stuff it has to over the course of the next few frames. If Mario touches this block before the game finishes pre-loading the level data, then it will not start loading the new level until the pre-loading is finished. With this pre-loading system, this will solve the issue and make the level loading more seamless, assuming that the game is given enough time to pre-load the level data before it has to load everything else.



Unless something changes at some point, here are some things you guys will have to keep in mind if you want to use the dynamic level loading patch once it's released:

- It will be your guys responsibility to make sure that the player can't reach the second loading block before the game finishes pre-loading the level data. You'll have to make sure that the pre-load blocks are unavoidable and placed far enough away from the second loading block so that the game will always finish pre-loading the new level before the player reaches the second loading block.

- You'll need to make sure that the new and old level have a section that looks identical when the game loads the new level because the layer 1 tilemap won't get updated until the screen scrolls. You'll also have to play around with the position the player spawns at to make sure the camera scrolls as little as possible when the new level loads (Otherwise, the camera will snap to the player when they move and it can cause glitched graphics to appear).

- Be careful when changing the graphics, palette, and backgrounds mid-level. The graphics and palette are loaded on different frames so if the graphics you're loading require a different palette from the current graphics, then they will have a bad palette for a few frames. Also, the background will noticeably update if it's visible during level loading so you generally want to completely obscure it from view when it loads.

- Apply the improved LC _LZ2 patch included in Lunar Magic. That will greatly speed up the level loading when it goes to decompress the graphics. If you're not using that for some reason, then keep in mind that the fewer graphics files the new and the old level share, the laggier the level loading will be.

- If the player touches a pre-load block on another screen after touching another of these blocks that is on a different screen, it will cancel loading the level it was working on and start loading the new level.

- This patch will likely require quite a bit of ROM space. Currently it needs 2 ROM banks, but the amount will change when I release it depending on how I implement certain things.

- The game will be more likely to lag when the game starts pre-loading the next level (unless you use the SA-1), so try to keep the number of onscreen sprites to a minimum once the pre-loading starts.

- This patch will require over 24 KB of free RAM in order to store the pre-loaded level data. The patch will automatically expand the SRAM so it will have enough RAM to work with.

- The larger the blocks you place in the new level are, the more likely the game will lag. Blocks that take up a single tile lag the least while direct map16 tiles expanded to their maximum size create the most lag.

- While dynamic level loading, the sky is the limit with what you can do with it once you get the hang of using it. Make levels that are longer than what SMW normally allows (without using transitions like doors and pipes)! Make levels with wacky level layouts (spiral shaped level, anyone?)! Create levels that seamlessly change under certain conditions (like Chocolate Island 2, but without any transitions, or any of those castles in SMB1 that loop if you take the wrong path)! Make a huge, seamless, Metroid-esque world for players to explore! Once this is released, I want to see what you guys can come up with! :)

- There may be some more stuff to mention, but I'll mention them and anything I mentioned here in the readme for the patch once it's released.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
As always stated on my thread too much making stuff, etc, etc, so I ended up commenting almost nothing.

Your ASM is pretty impressive. I always noticed that you have some good ASM skills so I'm not even surprised at this rate.

The dynamic level loading is pretty awesome. I actually did it too with a few levels of Touhou Mario 2 but hardcoded together with some cutscenes and conditions so it would look smooth enough.

If you're planning to make a SA-1 version of it, just use Parallel Mode for the pre-loading, so it won't affect in-game performance (for who don't know Parallel Mode is a special SA-1 mode that lets you run whatever code you want while SA-1 is idle and does not affect original gameplay).

I liked the game over thing. While I don't find it very suitable, because of the usual Mario games public target (though 10-11 year old people are getting so matured regarding violent games that I don't know if this count as a valid argument anymore but...), I find it interesting to have different deaths/lives mode because that gives a new feel into the game. Nice job with this.

As for the new dynamic sprites, I remember many people asking me "Aaaah Vitor what about a system that all sprites and palettes are dynamic and they work on demand and stuff" but I never had courage to do that because I know it's holy complicated to do, having to edit every single sprite to add support for it but it's cool to see you making something similar. I hope you have success with this.

It would be good to you be more present at SMW Central, posting more interesting stuff at ASM showoff thread or occasionally posting something in our sections. Who knows how far you can lead with your ASM skills?

--------------------
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
As always stated on my thread too much making stuff, etc, etc, so I ended up commenting almost nothing.

Your ASM is pretty impressive. I always noticed that you have some good ASM skills so I'm not even surprised at this rate.

The dynamic level loading is pretty awesome. I actually did it too with a few levels of Touhou Mario 2 but hardcoded together with some cutscenes and conditions so it would look smooth enough.

If you're planning to make a SA-1 version of it, just use Parallel Mode for the pre-loading, so it won't affect in-game performance (for who don't know Parallel Mode is a special SA-1 mode that lets you run whatever code you want while SA-1 is idle and does not affect original gameplay).

I liked the game over thing. While I don't find it very suitable, because of the usual Mario games public target (though 10-11 year old people are getting so matured regarding violent games that I don't know if this count as a valid argument anymore but...), I find it interesting to have different deaths/lives mode because that gives a new feel into the game. Nice job with this.

As for the new dynamic sprites, I remember many people asking me "Aaaah Vitor what about a system that all sprites and palettes are dynamic and they work on demand and stuff" but I never had courage to do that because I know it's holy complicated to do, having to edit every single sprite to add support for it but it's cool to see you making something similar. I hope you have success with this.

It would be good to you be more present at SMW Central, posting more interesting stuff at ASM showoff thread or occasionally posting something in our sections. Who knows how far you can lead with your ASM skills?



Thanks! ^_^

Regarding the dynamic level loading, this was a lot of hard work, but I'm very happy with the results. Especially now that I've gotten the pre-loading routine to work so now it can seamlessly load a new level when a loading point is touched after all the pre-loading is done. Also, that's neat that you did something similar in your hack. :)


As for the SA-1, I'll make this compatible with it when I release it. The Parallel Mode would certainly help with speeding up the pre-loading routine and also allow certain things that load on separate frames for performance reasons to be loaded on the same frame. However, even without the SA-1, my dynamic level loading is fairly fast. The pre-loading does cause some lag currently, but I can potentially optimize those routines some more to speed them up. Also, the game is able to load the new level data almost instantaneously once Mario touches a level loading point no matter how big the new level is, and everything else that loads over the next few frames loads fast enough that the player is unlikely to travel very far from the loading point before it's done.


Regarding the game over thing, I'll admit that it does seem out of place in the context of Mario, but I'm not going to let that stop me from implementing any interesting ideas I may have. As long as I can make it work within the context of my hack, then it's fine. Personally, I feel it adds some humor to the constant deaths that will occur in my kaizo hack due to not only how over the top the animation is by itself, but also because of all the interactions Mario's head will have with different sprites. Basically, when Mario dies, you have no idea what's going to happen afterwards. Maybe Mario's head will go on a mini-adventure of its own. Maybe a chuck will tackle it halfway across the mushroom kingdom. Maybe it will land the final hit on a boss. Or maybe it will just fall to the ground after Mario made a pitiful attempt at getting a haircut using a muncher. Who knows?

Also, due to this and one other thing in my kaizo hack, I will put a warning in the hack's description when I release a demo that the hack contains stuff that may not be suitable for younger players.


As for the dynamic sprites, this was a lot of work to do, but not because of converting the existing sprites (though that does require some work), but rather because the routine I'm using is my 3rd attempt at this. My first attempt ended up being was way too complicated and it would have slowed the game down quite a bit because of the buffering routine. My 2nd attempt didn't get very far, but it would have made it so that each and every sprite animation frame was defined within a single routine and that sprites could be set to display any animation frame (so, if I set it so that a cheep cheep used a thwomp animation frame, it would actually appear as a thwomp). I gave on this because I realized how much work that would be and also because some animations would have been hard to define for sprites that animate through movement, like wall springboards.

My third and final attempt actually works similar to Mario's dynamic routine, but expanded so that more sprites can use it. As a result, the sprites don't need much code to be made dynamic, I don't need to buffer any graphics so I save lots of RAM and CPU cycles, and it's very simple compared to my previous attempts. The only downside is that it uses more V-blank time, but the uploading routine is pretty well optimized so it's not too big of an issue.


I may release a patch for this dynamic routine at some point, though whether I also release the code that makes many of the existing SMW sprites dynamic is less likely to happen because of the complications with that.



As for the last thing, yeah, I want to be more active here. I tend not to post much outside the threads I've made because I tend to have little to say (but when I do have something to say... XD) or I don't have much to add that hasn't been said already in a given thread. I'll try to post more often either way, and perhaps I'll try participating in a contest, like VLDC9, for once.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
This is absolutely impressive. I have to remember my code is for a specific level setup (all I'm loading is the map16 and sprites, not gfx and stuff like that) so to be able to make something that's reasonable for even the craziest combinations is amazing. This is probably one of the most impressive patches I've seen.

--------------------
‎▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
‎―••~asuka over rei every day~••―
‎90% of teens smoke weed. if you're
‎part of the 10% put this in your sig
‎▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬
Originally posted by Mellonpizza
This is absolutely impressive. I have to remember my code is for a specific level setup (all I'm loading is the map16 and sprites, not gfx and stuff like that) so to be able to make something that's reasonable for even the craziest combinations is amazing. This is probably one of the most impressive patches I've seen.



Thanks again. ^_^

If you or anyone else is curious about its progress, this is what I have left to do:
- Find a way to make all on screen sprites move with Mario to the new level in whatever state they're in. Currently, all sprites except held sprites and Yoshi (if Mario is riding him) despawn when the new level loads. My Mario head sprite also respawns, but that's only because I force a new one to spawn if one was present in the old level.

- Implement the layer 3 loading

- Fix any bugs I may come across. Currently, it seems that BSNES doesn't like something about the BG loading routine as it loads garbage when the BG is set to load. This didn't happen before I implemented the pre-loading.

- Optimize the code so it runs faster.

- Make this patch compatible with the SA-1

- Find a way to make the code teleport Mario to normal and midway entrances' positions. Currently, my code uses secondary entrances to determine what level to (pre-)load and where to put Mario in the new level once it loads which allows for 512 unique dynamic level loads. If I can figure out where LM stores the Mario positions for the other entrances, then the max number of unique DLLs will be either 1024 or 1536. I could also implement custom entrances if one somehow needs more unique DLLs than that, but those will naturally be harder to use because you can't edit them with LM. If I implement custom entrances with the way I'm thinking of doing it, the absolute maximum number of unique DLLs would be 8192 (512 sublevels * 16 types of entrances, 13 being custom).

It will be a while before this is done, but I'll likely post a thread in the Resource and Tool Releases forum when the time comes.


Also, as another little update, I'm working on improving the physics of the Mario head sprite and implementing the Game Over text into the source code ROM. For the new physics, I've made it so that it bounces when landing on the ground, it reacts to the ground shaking by bouncing at a height determined by how long the shaking was set to last, it bounces on springboards now, and it rebounds off of walls at half speed instead of stopping completely. Also, Yoshi is now programmed to react to Mario dying if Mario dies while riding Yoshi, Mario's head touches Yoshi, or it enters Yoshi's field of vision (he will see it if it's in front of him and is within 3 blocks above and below him).

I'm currently attempting to make the Mario head sprite lose/gain some speed when it bounces on a slope depending on what kind of slope it lands on, and lets just say that it's not working quite right:


It somewhat works, which you can see it doing when it does the high bounces (the only reason it bounces that high is so I can more easily see if it bounces on the slope as soon as it lands on one, which it isn't doing). But apparently, bouncing on a slope while going downhill applies the same force to the Mario head as being blast out of a cannon. If I told you guys that I've graduated from Truck Driving Collage, it would be as believable as these physics are. XD

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Pages: « 1 2 » Link
Forum Index - Sunken Ghost Ship - C3 Museum - Winter 2016 - Yoshifanatic's ASM Showoff

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

Copyright © 2005 - 2021 - 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
  • sm64romhacks