Banner
Views: 853,841,286
Time:
25 users online: autisticsceptile1993, Ayami, Carld923, Connnnair, containercore, Earthling, ExONightZ, JDC, kellykelster,  Lazy, Linatic, lustreflux, lx5, NewPointless, nickofzo, Para_0, PineSkyz, qantuum, RPG Hacker, Runic_Rain, Samantha, Super Wario Man, Ultima, Von Fahrenheit, Zareption - Guests: 107 - Bots: 69 Users: 47,115 (2,477 active)
Latest: Eber
Tip: Not logged in.
PIXI v1.2: Some Sprite Insertion Tool of Sorts
Forum Index - SMW Hacking - Resource & Tool Releases - PIXI v1.2: Some Sprite Insertion Tool of Sorts
Pages: « 1 2 3 411 12 »
I found the corresponding code (which is the same in sprite tool's main file actually) but I can't make much sense of it. I assume sprite tool just inserts some (undocumented as so often) hijack at $01D43E.
So far, I can't really make any sense of this so I guess I'll have to debug a sprite tool ROM by chance and see what it does ^^'

Code
.HandleCustomSprite
	LDA !extra_prop_2,x
	BMI .CallMain
	PHA
	LDA $02,s			;load state back in A
	JSL $01D43E|!BankB		;handle sprite based on status
	PLA
	ASL A
	BMI .CallMain
	PLA
	CMP #$09
	BCS .CallMain2
	CMP #$03
	BEQ .CallMain2
	JML $0185C2|!BankB
.CallMain2
	PHA
.CallMain
	;continue as normal


--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Bit 6 also has a function. The way I heard it is that setting neither bit will cause the default routines for statuses 3, 9, A, and B to call the main routine afterward, setting bit 6 will cause all default status routines to call the main routine afterward, and setting bit 7 will skip the default routines entirely and call the main routine in place of all of them. (No special behavior for setting both bits, though, which seems like a waste.)
Never mind, I checked code again, here is what it's suppose to do.

Status 0 and 1 and 8 are always "default" handled. Quoted because default is hijacked by custom sprites anyway. For custom sprites, if the status is anything else, it checks bit 7 of extra property byte:

bit 7 set -> go to custom sprite main routine.
bit 7 clear -> run default handle for sprite status and then check bit 6

bit 6 set -> now call main.
bit 6 clear -> call main only if status is 3 or >= 9 (if not, return)

So bit 7 is like an override bit, while bit 6 is an append bit.
As such it seems rather pointless to me that we actually call main when bit 6 is set and the status is 3,9,A or B. Is any sprite even using this? 'far as I know all sprites just check for $14C8,x == #$08 anyway.
Might just be better to adjust that code to always skip or append given bit 6, no?

Anyway, I haven't checked it but given my recent (bad) experience with shifting, I'm pretty sure the error is caused by the LDY because I forgot to add .b so @SkywinDragoon you can try just opening the asm/main.asm file and adding the .b

Code
	LDA !new_sprite_num,x
	JSR GetMainPtr		; get sprite main pointer in [$00]
	PLA			; clear stack.

	LDY.b #$01|(!BankB>>16)	;\
	PHY			;| setup stack so that RTL will goto $0185C2
	PEA $85C1		;/
	JML [!Base1]		; goto sprite main code.


--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
If the PIXIV will be accepted, i wonder if can be possible that we'll have CLDC (Chocolate Level Design Contest) that uses sprites per level.
I mean, a CLDC that would be similar to VLDC7, VLDC8 and VLDC9.
To be honest, same sprites with different numbers each level is better than same sprites, same numbers in all the levels.

This makes things too easy, don't you think?
Could it be possible?
Sprites are the only reason why CLDC aren't compiled into the ROM? In what kind of world do you live in. Individually used patches, especially made exclusively for the level, are more a problem.

--------------------
Okay, my layout looks ugly.
Well, with the first version accepted, I guess it's time to think about what else I'd want for this tool to be capable of doing. I actually have 3 main targets for now: Extended and Cluster Sprites, extra byte usage and more CFG information.

Extended and Cluster should be simple enough to understand what I mean with, right?
As for how they'll be implemented, I thought maybe have the list file be able to switch between modes with lines like:

Code
SPRITES:	;list file now in sprite mode (default)
	00 Hammerbro.cfg
	...
EXTENDED:	;list file now in extended sprite mode
	00 somefile.asm
	...
CLUSTER:	;you get the point
	00

Cluster and Extended are simple enough but maybe I could also add ow sprites if I can get to it.




Extra byte usage is something that imamelia originally did with tesserar and was then added to Lunar Magic too (or maybe it was vica versa, not sure honestly). In any case, it is Lunar Magic's ability to insert sprites with more than the default 3 bytes into a level. Just like the extra bit we know and live, which means you can have different behavior for each individual sprite based on these extra bytes. The number of extra bytes can be anything per sprite number but I was thinking about just constantly setting it to 3 or 2 for all sprites (because honestly, what kind of sprite needs more than 24 bits of custom information for each individual sprite?).
I could also add it to the cfg file but I wonder if just setting it constant is not the less bothersome way to go.




Now for what is actually my main goal for now, more CFG information, namely, information to generate ssc, s16, mwt and mw2 files for Lunar Magic's custom display function (to have sprites not just as red Xs)
I was thinking something like this for cfg files after the usual stuff:

Code
NUMNAME NUMMAP16 NUMSSC (line 7 of cfg file)


NUMNAME is the number of lines following this that hold the sprites name to be put in Lunar Magics list. The number can be in between 0-2. 0 just means there is no name (will use cfg filename by default), 1 means just the sprite name and 2 means the first line is the sprite name and the second is the name for the sprite with extra bit set. Example:

Code
2 0 0
Ball 'n Chain clockwise
Ball 'n Chain counter clockwise


NUMMAP16 would be the number of custom map16 tiles that will be needed to display the sprite, each tile taking one line. The line would have to be the raw data map16 data, can't think of any way to make this "pretty". The line holds 8 bytes, character and yxpccctt data for the 8x8 tiles. But honestly, when generating this, you can just open your own s16 file in a hex editor and copy the stuff over. Example:

Code
1 2 0
Hammer Bro		;name
48 09 58 09 49 09 59 09 ;top tile
58 09 4A 09 59 09 7F 09	;bottom tile


Lastly, NUMSSC is the number of lines used for the ssc file. Honestly, I can't think of a way to make this "prettier" either, so I guess it will just be 1:1 the same as a normal ssc file lines minus the sprite number. For custom display map16 data, you can assume the previously inserted map16 tiles to start at 0x400 (tool will add proper offset). Example:

Code
1 2 2
Hammer Bro		;name
48 09 58 09 49 09 59 09 ;top tile
58 09 4A 09 59 09 7F 09	;bottom tile
0020 A classic hammer bro. Throws hammers and jumps.
0022 10,-14,1DB 0,0,401 0,-8,400


For anybody unfamiliar with the ssc file format, the 4 leading hex digits indicate whether the line is a description text or the display information, as well as "what" the information is targeted at (sprite, sprite with extra bit set, sprite at position x&1, sprite at y&1 etc...)

Note that line 7 itself won't be mandatory. If the cfg file ends before there, that's that.
I also might just make it replace line 6 (assembler in sprite_tool) and have the tool recognize if the line only holds one number (= old cfg file for sprite tool).

Any thoughts on the matter?

--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
I have a little idea!

Adding sprite tables function:
User can assign freeram to make custom sprite table on a separate list.
The program will clear the freeram (12 bytes on lorom, and 22 for sa-1 rom) upon clearing table routine.

--------------------
Receiving?
If you need more sprite tables (why even, there are tons?), just pick some freeram and use them. Clear it on sprite init and that's it. Or am I overlooking something here?
Sure, it won't be cleared along with the clear tables routine, but how often do you even call that outside of when spawning a sprite?

--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Originally posted by JackTheSpades
As for how they'll be implemented, I thought maybe have the list file be able to switch between modes with lines like:

Code
SPRITES:	;list file now in sprite mode (default)
	00 Hammerbro.cfg
	...
EXTENDED:	;list file now in extended sprite mode
	00 somefile.asm
	...
CLUSTER:	;you get the point
	00

Cluster and Extended are simple enough but maybe I could also add ow sprites if I can get to it.

Yes. That system is incredibly easy to get, do that. Using multiple lists would be a mess. Nothing else would make nearly as much sense.

Originally posted by JackTheSpades
Extra byte usage is something that imamelia originally did with tesserar and was then added to Lunar Magic too (or maybe it was vica versa, not sure honestly). In any case, it is Lunar Magic's ability to insert sprites with more than the default 3 bytes into a level. Just like the extra bit we know and live, which means you can have different behavior for each individual sprite based on these extra bytes. The number of extra bytes can be anything per sprite number but I was thinking about just constantly setting it to 3 or 2 for all sprites (because honestly, what kind of sprite needs more than 24 bits of custom information for each individual sprite?).
I could also add it to the cfg file but I wonder if just setting it constant is not the less bothersome way to go.

Make it a CFG option. Making the end-user define it for each sprite that might want to use it seems silly if it'll stay consistent per-sprite and could go into the CFG anyway.
Hardcoding it is always the inferior route if it can be hidden from the user anyway. Coders know what they do.

Originally posted by JackTheSpades
Code
1 2 2
Hammer Bro		;name
48 09 58 09 49 09 59 09 ;top tile
58 09 4A 09 59 09 7F 09	;bottom tile
0020 A classic hammer bro. Throws hammers and jumps.
0022 10,-14,1DB 0,0,401 0,-8,400


[...]

Note that line 7 itself won't be mandatory. If the cfg file ends before there, that's that.
I also might just make it replace line 6 (assembler in sprite_tool) and have the tool recognize if the line only holds one number (= old cfg file for sprite tool).

Any thoughts on the matter?

Couldn't you bundle up SpriteTIP with PIXI?
Like, only include name and description informations in the cfg (much like how GPS includes its print statements) and then run SpriteTIP using all that info. If a sprite has no line 7+ then it'd just use the cfg's name with no description, while still running SpriteTIP on it.

If that's not an option (it'd be a loooot better, since a lot of people remap sprite tiles), then yeah, your proposal seems fine. Just replace the original assembler bit, sure. PIXI has literally no use for it and we don't need PIXI->Romi backwards compatibility.

--------------------
Your layout has been removed.
Originally posted by leod
Couldn't you bundle up SpriteTIP with PIXI?
Like, only include name and description informations in the cfg (much like how GPS includes its print statements) and then run SpriteTIP using all that info. If a sprite has no line 7+ then it'd just use the cfg's name with no description, while still running SpriteTIP on it.

If that's not an option (it'd be a loooot better, since a lot of people remap sprite tiles), then yeah, your proposal seems fine. Just replace the original assembler bit, sure. PIXI has literally no use for it and we don't need PIXI->Romi backwards compatibility.

Adding SpriteTIP seems rather pointless to me. Like, if people want to use SpriteTIP, they can just do a batch file instead calling it after PIXI.
I don't really get your point regarding remapping, since this has absolutely nothing to with appearance in Lunar Magic. I could make the thwomp look like a hammer bro in Lunar Magic and it would change nothing ingame.

Lastly, the point here is that you have full customization control from the cfg file.

--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Originally posted by JackTheSpades
Adding SpriteTIP seems rather pointless to me. Like, if people want to use SpriteTIP, they can just do a batch file instead calling it after PIXI.

Yes, but then they would still all have to write their own SpriteTIP parsed file for names and descriptions, which could be included in each downloaded sprite's CFG file this way.

Originally posted by JackTheSpades
I don't really get your point regarding remapping, since this has absolutely nothing to with appearance in Lunar Magic. I could make the thwomp look like a hammer bro in Lunar Magic and it would change nothing ingame.

Exactly. Meaning if someone wants to remape a tile used by a Hammer Bro for example, they would have to open the .cfg file and figure out how the format even works just so it shows up fine in Lunar Magic too.
Having SpriteTIP do the work would mean that it always looks the same in-game as it does in Lunar Magic, without anyone having to mess with it.
The majority of sprites do not want different tiles based on their extra bit, so this behaviour would be much preferred (and doing the thing LM does where sprites strike a different pose in different x/y positions is not exactly super duper necessary for like, anything).

Originally posted by JackTheSpades
Lastly, the point here is that you have full customization control from the cfg file.

Yeah but I feel like this is a case of user friendliness (the majority of PIXI users will not know how to code, how tiles really work past simple remapping and won't want to learn this whole new format on top of that) vs. the ability to change the looks of like, 5% at most of sprites only in specific situations.
If you must have that, maybe make it a CFG option as well? Put a CFG Editor option for automatically figuring out tiles or something.
Maybe for the ultimate user experience, have a visual editor for the LM sprite format in the CFG Editor? Like, it would be greyed out while auto-config is ticked and when unticked, it lets you pick and move sprite Map16 tiles. Might be overkill to be honest.


Like in the end all my points are pro-user and especially newbie friendliness and lack of extra work on every single end user's part. If you really, really, absolutely need a way to edit it by hand then make it an option once again.

--------------------
Your layout has been removed.
Well, the first problem here is that SpriteTIP doesn't even support PIXI, and Vitor's code is kinda like dark magic. Putting that aside for now though, I honestly don't think it's that hard to understand even for novices. Suppose I do this for the CFG editor:

Names are simple enough, for the ssc information, I guess I could just make a list where you can add entries. Selecting one entry in the list allows you to edit what it stands for (x/y/extra bit) and displays the description and map16 data.
The map16 data should be easy enough to edit even for novices if you just show them how to view it in Lunar Magic. The only problem I have with displaying it in the cfg editor itself is that I'd need GFX files for that, and I don't know which ones the sprite will use (unless you put that as dummy information in the cfg file too).

The bigger problem, admittingly would be the additional map16 data to be added. I could add support to just import a number of tiles from an existing s16 file (again, simply telling users how to open it in LM).

Or, I just really add this to the CFG editor, again, just a pain because I need GFX files at hand:



--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Originally posted by JackTheSpades
Well, the first problem here is that SpriteTIP doesn't even support PIXI, and Vitor's code is kinda like dark magic. Putting that aside for now though, I honestly don't think it's that hard to understand even for novices.

You're not thinking of actual novices then. Real newbies think that figuring out how to insert ExGFX is a huge accomplishment. They won't figure out the format in 5 minutes, even if the documentation is right there.

I think all SpriteTIP does is run the sprite pointers in a faux-ROM in an emulator and then read out the OAM. I realize that that's not as simple as it sounds, but I feel like that isn't -that- dark magic? Might be worth asking Vitor if he could add suport for PIXI (isn't it just making it adopt shared subroutines as well as changing where the pointers are (assuming PIXI changes this location)?).


Originally posted by JackTheSpades
Or, I just really add this to the CFG editor, again, just a pain because I need GFX files at hand:

I think having people pick their own GFX files is something you can at least trust them to do, since they themselves pick the ExGFX number and inserting these graphics is an integral part of the sprite insertion process itself. If they don't know which ExGFX file they're using then they can't even really use the sprite!

That editor actually looks pretty good to me. It might be overkill, but that's a lot better than messing with raw tile data and properties (it's Extension, not Extansion by the way).



In the end, the solution you had in mind from the start would still totally work, it'd just look ugly and make the whole feature pointless to people who don't know how to remap sprite tiles in LM, leaving them with garbled sprites.
As it were, it's SpriteTIP-built-in > CFG-Editor-GUI-window > messing-with-raw-data-in-the-cfg.

--------------------
Your layout has been removed.
About sprite type separation: That seems reasonable to me. I think Daiyousei was doing something similar, with @normal/@extended/etc. (or something?). Besides cluster, extended, and overworld, other possible options for additional sprite types would be scroll, bounce, minor extended, score, smoke, and spinning coin. I don't know how many of them would be worth adding, though.

About extra bytes: Definitely add this functionality to PIXI. I really don't think the number of extra bytes should be hardcoded, though: it would waste ROM space for sprites that don't need them all, and while sprites that use all 4 extra bytes are rare, I have had ones that did require all 4 on a couple occasions. (Technically, Lunar Magic supports a sprite size of up to 255 total bytes total, but it seems to only be able to display 12, and Tessera only ever made room in RAM for 4.) On that note, don't forget to make sure that the sprite loading routine can handle more than 256 bytes of sprite data.

About the extra .cfg information: I feel like this would be hard to do without it inconveniencing somebody, at least either the sprite coders or people who like to arrange their sprite Map16 pages in a specific way, but it could work as an optional feature. At the very least, I guess the .mwt and .mw2 files as well as the descriptions would be reasonable, but it would be hard to do those without the other stuff. The editor does look pretty decent, though.

Oh, and for the record, I'd be willing to help with possible sprite remoderation...if we did it after the next version of PIXI comes out and at least supports extra bytes, if not the other stuff.
@shared list file: Hey, UberASM already does that. Why shouldn't PIXI do it?

@extra bytes: Hell yeah, without any arguments. I mean, while tessera did failed, the extra bits are surely a nice feature (in fact, I tried to implement them for the old sprite tool but without any success).
However, a constant value will just bloat up the ROM. It is reasonable for the level sprites (Lunar Magic only checks for the sprite number in placing a sprite*) but not all custom sprites requires the same amount of extra bits (that is, sometimes none).
Of course, you should leave the extra byte table for vanilla sprites an ASM file and not make them generated by PIXI. After all, extra bytes aren't just for custom sprites but also for vanilla ones if you properly modify them.

*Edit: And the extra bit. But you get the idea.

I also want to suggest to put the ASM files in "asm" into a sub folder. I mean, two tools already put a main.asm into a folder called ASM (AMK and UberASM tool), especially because PIXI uses the folder where the ROM is located and not of the tool's one.

Originally posted by imamelia
Oh, and for the record, I'd be willing to help with possible sprite remoderation...if we did it after the next version of PIXI comes out and at least supports extra bytes, if not the other stuff.

I don't think, a full remoderation is needed just to add extra byte support. At least these which could benefit of extra bytes could get updated. Then again, many sprites are still for TRASHM and shared routine support should be a thing too, so...

--------------------
Okay, my layout looks ugly.
Originally posted by MarioFanGamer
I also want to suggest to put the ASM files in "asm" into a sub folder. I mean, two tools already put a main.asm into a folder called ASM (AMK and UberASM tool), especially because PIXI uses the folder where the ROM is located and not of the tool's one.


Are you sure, it should actually call the asm folder from it's own directory. Like, the only thing it ever does with the rom path is open and save it from/to there, nothing else.

Also, I keep forgetting that some people just dump all the tools in one folder. I'm one to always use subfolders for all tools, so I never got any conflicts like that ^^'. Guess I could just rename it to pixi_asm or something.

Originally posted by imamelia
Besides cluster, extended, and overworld, other possible options for additional sprite types would be scroll, bounce, minor extended, score, smoke, and spinning coin. I don't know how many of them would be worth adding, though.

I think all of them actually run the same way, that is, loop over their RAM address and execute pointer to sprite number. So implementing wouldn't be that difficult (probably). But I very much doubt the need for it. I feel like scrolling is already being implemented via uberASM. Like, even cluster and extended sprites, which seem the most useful out of the lot and can already be implemented are hardly being used by people.

Originally posted by leod
You're not thinking of actual novices then. Real newbies think that figuring out how to insert ExGFX is a huge accomplishment. They won't figure out the format in 5 minutes, even if the documentation is right there

Going by that, understanding the tile and YXPPCCCT format needed for remapping sprites is more complicated to begin with, no?
Like, the format is explained in 6 steps:
1. open Lunar Magic map16 editor
2. press ctrl+shift+pgdown
3. go to page 80
4. hovering over a tile the number is displayed in the bottom corner
5. subtract the 8000
6. format is xoffset,yoffset,tilenumber (space) repeat

plus 4 more steps if they need custom tiles:
7. go to page 84
8. start building your tiles just like normal map16
9. press ctrl+shift+F9 (press OK on dialog) which saves a <romname>.s16 file
10. in cfg editor use "import from s16 file".

(And those steps are assuming I'm not doing my own editor for within the cfg editor)

I'll be honest, I just dislike the idea of calling external tools to do your job for you... even if it's a bit of a common notion in practice. And while SpriteTIP is great, it also has it's shortcomings. As you said, it reads the data from OAM, which means it (probably) can't depict some sprites that change appearance correctly, can it?
Plus, SpriteTIP is coded in C#, where as PIXI is in C++. While this shouldn't really pose a problem on windows, it might be on Linux if I just try to call it normally.
But you know, with all said and done, if Vitor updates it to work with pixi, I can simple add a command line option to use it instead of the build in functionality.
Maybe just generate a list file for SpriteTIP as .stip which you can then use via batch file or something.

--------------------
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Originally posted by JackTheSpades
Are you sure, it should actually call the asm folder from it's own directory. Like, the only thing it ever does with the rom path is open and save it from/to there, nothing else.

That happened because I used a batch file so that was the reason. In fact, if you use a batch file then the tool uses the path of said file instead of the one of the tool. Anyway, thanks for the clarification.

--------------------
Okay, my layout looks ugly.
Quote
That happened because I used a batch file so that was the reason. In fact, if you use a batch file then the tool uses the path of said file instead of the one of the tool. Anyway, thanks for the clarification.

You have to run <cd dir> before running the tool. How do you even run the tool without the <cd dir>? Are you calling it with full path?
Originally posted by MarioFanGamer
(Lunar Magic only checks for the sprite number in placing a sprite)

What do you mean by that? Because the extra byte count table is 0x400 bytes long, not 0x100.

Oh, and if you don't have it already, it would be a good idea to allow comments in sprite lists. And were you planning on implementing run-once sprites?
Originally posted by JackTheSpades
Going by that, understanding the tile and YXPPCCCT format needed for remapping sprites is more complicated to begin with, no?

Most people simply change tiles, not palettes. They don't need to figure out YXPPCCCT, especially if the palette set by the CFG is used.
That being said though, that is irrelevant. Learning how to remap in-game is absolutely mandatory if they need that, while remapping it in LM is simply additional learning and work for something not actually vital. It -can- be skipped and automated because this runs on an actual PC and not on the SNES.

I totally see that it's too much work to make your own SpriteTIP clone just for this though. As long as there's no PIXI compatible SpriteTIP it can't really be helped.
Bundling up that editor you showed off earlier in the CFG editor should do just fine as a replacement though, I'd have no issues with that.


Originally posted by JackTheSpades
Like, the format is explained in 6 steps:
[...]

plus 4 more steps if they need custom tiles:
[...]

(And those steps are assuming I'm not doing my own editor for within the cfg editor)

It's not terribly tough, no, but it's something that will have to be explained to different people roughly 500 times over the course of a few years when they remap a sprite (which will have its own question thread too...) still. People really seem to hate reading documentation and it's us that have to point them towards it every time if it isn't immediately obvious how to work it.

This all sounds a lot more serious than it really is by the way, in the end I wouldn't complain no matter what you do, just spitballing while you're in the design phase.


Originally posted by JackTheSpades
As you said, it reads the data from OAM, which means it (probably) can't depict some sprites that change appearance correctly, can it?

It has never had any issue with any sprite I've ever made, so I'm not sure about any shortcomings.


Originally posted by JackTheSpades
But you know, with all said and done, if Vitor updates it to work with pixi, I can simple add a command line option to use it instead of the build in functionality.

If it ever happens, making it a per-sprite cfg option definitely seems like the best choice to me, because some sprites will always benefit from manual design (eg generators using text, sprites changing visuals per x-pos, etc.) while the majority will be fine to be automatically generated by the tool.

--------------------
Your layout has been removed.
Pages: « 1 2 3 411 12 »
Forum Index - SMW Hacking - Resource & Tool Releases - PIXI v1.2: Some Sprite Insertion Tool of Sorts

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