Views: 772,013,154
10 users online:  1UPdudes, FailSandwich, Fullcannon, GamecraftOriginal,  Giftshaven,  idol, Infinity, placeholdertest, SiameseTwins,  Tahixham - Guests: 34 - Bots: 201Users: 40,552 (1,856 active)
Latest: jonaskohl
Tip: Try running your hack on various SNES emulators to see if anything is incompatible. Not logged in.
Street Fighter II Research (*Hitbox Viewer Hack!*)
Forum Index - Non-SMW Hacking - Misc. ROM Hacking - Street Fighter II Research (*Hitbox Viewer Hack!*)
Pages: « 1 »
I'm surprised that there hasn't seemed to have been much interest in Street Fighter II in the ROM hacking community, considering that it's one of the classic big hits of the early 90's. There's a lot of potential for fun hacking in SF2, IMO. At any rate, I've done a bit of research on my own, which I will publish here. I'm a complete novice at this, and have no real knowledge of programming or hacking. Thus I might not know proper terminology for things (any corrections would be appreciated), and I could simply be mistaken on some of my statements. I hope that this will spur some interest in SF2 among ROM hackers and lead to further investigation of the game and its possibilities.

NOTE: All data is in reference to the arcade version of the game. Specifically the Japanese region Street Fighter II' Turbo (romset sf2tj) is currently being used for reference. The various arcade versions of SF2 run on the CPS1 and CPS2 systems, which share a lot in common hardware-wise, and from what comparisons I've done, much of the system data-wise is the same or similar across all incarnations. All values given are as displayed in FBARR's RAM viewer and MAME's memory window. This means they are byte-swapped compared to the raw ROM data.

*Object Test*

This was an invaluable tool in my research, and I have to thank T. Akiba and Kung Fu Man for helping make it available to me. It lets you view all of a character's animation frames and associated parameters. It was originally accessed via dipswitches, but these are hard to manage, and include side effects that make navigating through the test menu difficult. The easiest and most useful way to access the test is by forcing RAM address 0xFF08CE to value $B3 via the cheat function and pressing the Test/Service button.

(Although this test menu is only known to exist in the CPS1 versions of SF2, I have found text for similar menus within the ROM data of the CPS2 versions, as well as in other CPS2 games. Might they be accessible through some hacking?...)

There are 4 modes in the Object Test, NORMAL, EDIT, CATCH, and an unlabeled mode I'll refer to as "CATCH2".
NORMAL offers the basic animation viewer as well as tile data for each animation frame.
EDIT displays hitboxes and their associated data.
CATCH displays 2 characters standing on the same spot, for some reason.
"CATCH2" displays an opponent character with a specific sprite and position offset as determined by the value of the primary character's CATCH parameter. This allows you to review how an opponent who is grabbed with a throw technique will be displayed.

Here are the known controls. For the descriptions, "P1" refers to the character present in all 4 modes, "P2" refers to the secondary character that appears in the CATCH and "CATCH2" modes.

P1 Start: Increment Stage(?)
P1 Up/Down: Increment "P1" animation.
P1 Left/Right: Toggle "P1" direction (NORMAL and CATCH modes only).
P1 LP: Decreases "P1" Chr Ctr value by 1 every frame while held down, thus playing back the current animation in realtime.
P1 MP: Reset "P1" current animation to its start.
P1 HP: Toggle priority of "P1" and "P2" sprites (CATCH mode only).
P1 HP + Up/Down: Increment "P1" character.
P1 LK: Toggle tile display (NORMAL mode only).
P1 MK: Disables character axis display while held.
P1 HK: Increments "P1" animation frame (EDIT and CATCH modes only).
P2 Start: Increment mode.
P2 Up/Down: Increment "P2" animation (CATCH mode only). / Increment DX value of currently displayed hitbox (EDIT mode only).
P2 Left/Right: Toggle "P2" direction (CATCH mode only). / Increment DY value of currently displayed hitbox (EDIT mode only).
P2 LP: Decreases "P2" Chr Ctr value by 1 every frame while held down, thus playing back the current animation in realtime (CATCH mode only).
P2 LP + Up/Down: Increment SX value of currently displayed hitbox (EDIT mode only).
P2 LP + Left/Right: Increment SY value of currently displayed hitbox (EDIT mode only).
P2 MP: Resets "P2" current animation to its start (CATCH mode only).
P2 HP: Nothing?
P2 HP + Up/Down: Increment "P2" character.
P2 LK: Increment hitbox type selection (EDIT mode only).
P2 MK: Nothing?
P2 HK: Increments "P2" animation frame (CATCH mode only). / Displays/resets currently selected hitbox type of current animation frame (EDIT mode only). (The display does not update until P2 HK is pressed again, even if you move to another animation frame or hitbox type.)

*Character Data Order*

For most data that is indexed by character, the order seems to be as follows:

00: Ryu
01: Honda
02: Blanka
03: Guile
04: Ken
05: Chun Li
06: Zangief
07: Dhalsim
08: Vega (aka M. Bison, final boss)
09: Sagat
0A: Bison (aka Balrog, boxer)
0B: Balrog (aka Vega, claw & mask)

*Hitbox Data*

Starting at address 0x067384 are 12 long words, each of which defines the starting address of a character's hitbox data list.

0x067384-87: Ryu hitbox list address
0x067388-8B: Honda hitbox list address
0x06738C-8F: Blanka hitbox list address
0x067390-93: Guile hitbox list address
0x067394-97: Ken hitbox list address
0x067398-9B: Chun Li hitbox list address
0x06739C-9F: Zangief hitbox list address
0x0673A0-A3: Dhalsim hitbox list address
0x0673A4-A7: Vega hitbox list address
0x0673A8-AB: Sagat hitbox list address
0x0673AC-AF: Bison hitbox list address
0x0673B0-B3: Balrog hitbox list address

Each of these individual lists starts with 6 words, each of which defines the start of a specific hitbox group as an offset from the start of the list. As labeled in the Object Test, these are:

Bytes 00-01: Head list offset
Bytes 02-03: Body list offset
Bytes 04-05: Foot list offset
Bytes 06-07: Weak list offset
Bytes 08-09: Atck list offset
Bytes 0A-0B: Body1 list offset

The first hitbox in each group is always a null or non-existant box. This is used for animation frames that lack a hitbox of that type.
Head, Body, and Foot are vulnerability boxes that determine where a character can be hit.
Weak seems to determine a weak point on a character that can have certain effects when hit. However, outside of Blanka's rolling attack in SF2WW, it does not seem to be used.
Atck is the offensive hitbox which determines what part of the character can deal damage with an attack.
Body1 determines the "solid" part of the character which causes them to push against the opponent.

Each individual hitbox is defined by 4 bytes, as labeled by the Object Test:

Byte 00: DX
Byte 01: DY
Byte 02: SX
Byte 03: SY

This defines a rectangle of width 2(SX) pixels and height 2(SY) pixels, centered around a 2x2 pixel axis which is offset a horizontal distance of DX pixels and a vertical distance of DY pixels from the character's own 2x2 pixel axis. For horizontal offset, Negative is in the direction the character is facing, Positive is the opposite. For vertical offset, Positive is up, Negative is down.

Atck box definitions append an additional 8 bytes to this for a total of 12 bytes per box. These determine attack characteristics. The additional 8 bytes are, as labeled by the Object Test:

Byte 04: Atck Dno Points to a range of $20 values that can form the base damage of the attack. The exact value chosen from this range is determined by the character's power index variable.
Byte 05: Hit Type Seems to figure into consecutive frames of an animation that each cause individual hits.
Byte 06: SD Code Determines sound to play on non-blocked hit.
Byte 07: Atck EX Attack classification. $00 = standard normal, $01 = normal sweep, $02 = jumping normal, $03 = special move (causes chip damage when blocked), $04 = normal with special property (knockdown, etc.)
Byte 08: Level Attack strength. $00 = light, $01 = medium, $02 = hard.
Byte 09: Adjust 1 Points to a range of $20 values that can be added to the attack's base damage. The exact value is chosen from this range at random.
Byte 0A: Adjust 2 Same as above, but used when health is lower than $3C.
Byte 0B: EX Code Determines opponent's reaction upon hit when Atck EX = $03 or $04.

*Animation Data*

Each frame of character animation is defined by a 24-byte string of data. A list, labeled as displayed in the Object Test follows:

Bytes 00-01: Chr Ctr Determines number of frames of gametime that the animation frame is to be displayed before advancing to the next frame.
Bytes 02-03: Chr Type For the last frame in an animation sequence, the high byte usually seems to be 80. Other functions currently unknown.
Bytes 04-07: Tilemap Pointer
Byte 08: Head Head hitbox for this animation frame.
Byte 09: Body Body hitbox for this animation frame.
Byte 0A: Foot Foot hitbox for this animation frame.
Byte 0B: Weak Weak hitbox for this animation frame.
Byte 0C: Atck Atck hitbox for this animation frame.
Byte 0D: Body1 Body1 hitbox for this animation frame.
Byte 0E: Kage Ground shadow sprite for this animation frame.
Byte 0F: Prio Sprite priority for this animation frame.(?)
Byte 10: Catch Determines opponent sprite and position offset for when they are grabbed by a throw technique. Seems to be tailored on a character by character basis, for example every character has their own sprite selection and position offset for reacting to a Ryu frame with a Catch value of $01, etc.
Byte 11: Block Determines whether this animation frame is considered to be blocking. $00 = no block, $01 = standing block, $02 = crouching block.
Byte 12: Weak No Would seem to determine effect on character when their weak box is hit.
Byte 13: Sit Determines whether this animation frame is considered to be standing or crouching. $00 = standing, $01 = crouching.
Bytes 14-15: ???
Byte 16: Yoke2 Not certain of function. Haven't even been able to get MAME's debugger to break when setting a watchpoint on it. However, I have noticed a pattern in the Object Test. For most attack animations, this parameter has a value of $00 during the startup and active frames of the attack, and a value of $01 during the recovery frames.
Byte 17: Yoke Again, unsure of function, but have noticed some patterns. Value of $17 for neutral jumps (including attacks), $06 for forward and backward jumps (again, including attacks), and $FF for standing and walking.

An extra 4 bytes are appended at the end of an animation sequence. This is a "loop frame pointer"; it points to the animation frame to go to when the sequence ends.

*Character Jump Velocities*

Starting at address 0x015F98 are the definitions for character's jump velocities. Each individual jump has an 8 byte definition as follows:

Byte 0: Initial X Velocity Integer
Byte 1: Initial X Velocity Fraction
Byte 2: X Acceleration Integer
Byte 3: X Acceleration Fraction
Byte 4: Initial Y Velocity Integer
Byte 5: Initial Y Velocity Fraction
Byte 6: Y Acceleration Integer
Byte 7: Y Acceleration Fraction

The X velocities are defined in terms of a character facing left.

Each character has 4 jump definitions, ordered as follows:

00: Forward Jump
01: Backward Jump
02: Neutral Jump
03: Neutral Jump

Each character seems to be two copies of the neutral jump, for whatever reason.

Some notes on SF2 velocities in general: Velocity and acceleration integer values are all signed. For X velocities, negative is left, positive is right. For Y velocities, negative is down, positive is up. For accelerations, it's the opposite: For X accelerations, negative is right, positive is left. For Y accelerations negative is up, positive is down. For all velocities and accelerations, the fraction values represent an effective positive value of x/256 that is added to the base integer value.

*RAM Map*

0xFF8086-88: Dip Switch Settings
0xFF8BC4-C5: Camera X Position
0xFF8BC8-C9: Camera Y Position
0xFF8BEE-EF: Camera X Velocity
0xFF8BF0-F1: Camera Y Velocity

Player 1 RAM Base: 0xFF83BE Player 2 RAM Base: 0xFF86BE

Player 1 Values (For player 2 values, add an offset of $0300)

0xFF83C4-C5: X Position
0xFF83C8-C9: Y Position
0xFF83D2-D3: Chr Type
0xFF83D6-D7: Chr Ctr
0xFF83D8-DB: Animation Frame Data Pointer
0xFF83F2-F5: Hitbox List Pointer
0xFF83F6-F9: Defense Table Pointer Points to a range of $20 values than can form the character's defense factor. The exact value chosen from this range is determined by their power index variable.
0xFF83FA: X Velocity Integer
0xFF83FB: X Velocity Fraction
0xFF83FC: Y Velocity Integer
0xFF83FD: Y Velocity Fraction
0xFF83FE: X Acceleration Integer
0xFF83FF: X Acceleration Fraction
0xFF8400: Y Acceleration Integer
0xFF8401: Y Acceleration Fraction
0xFF8405: Hitstop Time
0xFF8416-17: Power Index Figures into character's offense and defense. Seems to be $10 by default, and to be affected by things such as losing rounds.
0xFF841A-1B: "Dizzy Meter" Clear Time Added to when character is attacked, decreases by 1 every frame of gametime. Upon reaching 0, the "Dizzy Meter" Value is reset to 0.
0xFF841C-1D: "Dizzy Meter" Value Added to when character is attacked, upon reaching a certain value character is put into dizzy state.
0xFF841E-1F: Dizzy Time Set to a specific value when a character is put into dizzy state, decreases by 1 every frame of gametime. Upon reaching 0, character recovers from dizzy state.
0xFF84AE-AF: Alt. X Velocity Integer
0xFF84B0-B1: Alt. X Velocity Fraction
0xFF84B2-B3: Alt. X Acceleration Integer
0xFF84B4-B5: Alt. X Acceleration Fraction
0xFF84B6-B7: Alt. Y Velocity Integer
0xFF84B8-B9: Alt. Y Velocity Fraction
0xFF84BA-BB: Alt. Y Acceleration Integer
0xFF84BC-BD: Alt. Y Acceleration Fraction These alternate velocity registers seem to be used for things such special moves. The velocities are of a different format than the previously-mentioned ones.
0xFF84D8-DB: Pushback Pointer Points to amount to be pushed backward during standing and crouching hitstun.
0xFF853F: Midair Flag
0xFF8540-1: X Distance From Opponent As judged by Body1 box, i.e., if the two players are pushing against each other, this value is 0.
0xFF8542-3: Y Distance From Opponent As judged by axis?

Projectile Slot 1 (There are multiple projectile slots (total of 8?), each is offset from the last by a value of -$C0)

0xFF98BC-BD: X Position
0xFF98C0-C1: Y Position
0xFF98C7: Direction (Movement) $00 = right, $01 = left.
0xFF98C8: Direction (Graphic) $00 = left, $01 = right.
0xFF98C9: Palette Stage (Bank)
0xFF98CA-CB: Chr Type
0xFF98CD: Palette
0xFF98CE-CF: Chr Ctr
0xFF98D0-D3: Animation Frame Data Pointer
0xFF98D6-D7: ID? For high byte, $00 = Hadouken, $01 = Yoga Fire, $02 = Yoga Flame, $03 = Sonic Boom, $04 = Tiger Shot. For low byte, $00 = light, $02 = medium, $04 = hard.
0xFF98E6-E9: Movement Data Pointer
0xFF98EA-ED: Hitbox List Pointer
0xFF98EE-F1: ??? Pointer

More to come later!
Hacking of fighting games is pretty much completely non-existant in romhacking community. The overall lack of hacking the most popular game in the genre makes it fairly obvious, it's just not a genre romhackers seem to involve themselves with for whatever reason. Recently I made a bugfix for an obscure fighting game, though pretty much only for myself. I modified the arcade cartridge I own and play it regularly so I got what I wanted out of it.

I like seeing this, it sucks that it's a completely dead genre for romhacking. Do you have any plans personally for applying this research to anything? Stuff like adding characters is a ridiculous amount of effort to even get on par with what was in the original game and I don't remember any glaring flaws from when I played my HF board. Just curious on what you plan to do or what you'd like to see. The formats look pretty standard and easy to work with so modifying stuff/making a simple tool wouldn't be hard.

Your terminology and all that seems fine. If you want to learn a bit of 68k ASM (I am pretty sure CPS1 is a vanilla 68k and CPS2 is the encrypted one) then mame debugger is a very powerful tool for researching/debugging any enhancements, but easier said than done ofcourse.
Thanks for the reply. As for what my plans are, the first thing I had in mind was creating a hitbox display LUA script. The CPS1 SF2s actually do have a realtime hitbox viewer that can be activated via dipswitches, but the necessary settings seem to have this side effect of making the game play at hyper speed that I can't find any way around. I don't actually know the scripting language yet, but I have seen that it has been used to make hitbox displays for other games, so I'm sure I can use those for reference. I think I have most of the necessary data identified.

After that, I'm not sure. I've envisioned things as simple as giving SSF2T Ryu a Hurricane Kick Super to as outlandish as porting over Felicia from Darkstalkers. For the time being, I'm just hoping to gather as much info as possible, possibly get some others interested, and maybe someday either I or someone else will be able to do something with it.

I have been using the MAME debugger, although I'm so new to this stuff that it's mostly going over my head. I think I'm starting to learn little by little, though.

Anyway, I was typing up some documentation on the animation data format last night, but the browser ate it, so I think I'll go retype it now.
ok. Well, just keep a reference handy and the debugging stuff will start to make sense. Patching stuff within mamed's memory viewers just to see what would happen is pretty handy, and the very powerful break/watchpoint system is nice. You can make a break/watchpoint satisfy pretty much any condition you can think of but I don't know how much sense it makes to you now. When you do get a hang of it, it'll make finding/documenting stuff so much faster.

if you get stuck somewhere in it just post the details here.
There used to be a lot of SF2 hacks as I recall, things like play as bosses hacks and speed up hacks used to be popular. Never seen any data for it though.

Your layout has been removed.
There were a large number of bootleg hacks of SF2'CE made and circulated shortly after its release. They were so prevalent that they were starting to take business away from the genuine article. They were one of the reasons that SF2'T was developed, and probably influenced the decision to use encryption on the CPS2 system as well.

Many of these hacks are archived in MAME, but from what I've seen, they tend to be rather poorly-made. They're good for a laugh, but not much else. I suppose they could be useful in research as points of comparison against the original SF2'CE.
Found some nice references for 68k ASM and MAME debugger functions. I think I'm going to try and pick apart the damage calculation routine, because I'm still having trouble figuring out exactly how those AtckDno and Adjust values figure into it.
There is the "help" command in mamed that also provides examples and documentation on each function. It's actually more thorough than what MESS gives you in those pages IIRC.

There shouldn't be much do the damage calculator unless they choose a really obtuse way to implement. The simplest way to do it would be fractional mulu instructions which take into account defense/offense coefficients for the given hitboxes/character. I remember something about damage output being smaller the lower your health is, but I might be thinking of something else (I think World Warrior had that, I don't know). That would also have to be scaled if it exists. Post the code if you get stuck, although the damage calculator shouldn't be too hard to figure out if you know the variables it puts into the equations. It'll just feed some variables into a routine and subtract the output from your healthbar.
You're correct about damage getting lower as health gets lower. T. Akiba's page has a section where he's calculated how it scales. It seems to be the same for the entire SF2 series (with the exception of multi-hit grabs being scaled somewhat differently in WW). One other thing to consider is that there's a random component in all damage in SF2, so I'll have to see how that figures in. And thanks for suggesting the help command, I'll try that out.
A cheap way for a game to do it is to take the frame counter and have it lookup a table of 'random' values. They can mish mash the input in hopes of getting in more random like throwing controller input and previous values. If there's seemingly irrelevant nonsense in the code that factors into the damage output it's probably the randomness routine.
Ok, I think I've got the damage calculation worked out, aside from the scaling when life is low (although I did see a branch for that, I haven't checked it out yet).

Atck Dno points to an entry in a base damage value table which starts at 0x0C63E4. Each entry consists of $20 1-byte values. The value that is chosen from that range is determined by a parameter I only just found out about, which I'm calling the "power index" for now.

So that's how we get our base damage value. From there, we modify that with the Adjust parameters. Adjust1 if the character's life is greater than $3c, Adjust2 if it's equal to or lower than $3c. Like Atck Dno, the Adjust parameters point to entries in a table, each entry consisting of $20 different values. A value form within this range is chosen at random, and added to the previously-determined base damage value.

Now we get the opponent's defense factor. When a character is loaded into memory, along with their hitbox list pointer, a defense range pointer is loaded. This points to, again, a range of $20 different defense factor values. The exact value chosen from this range is determined by the previously mentioned "power index" variable.

Then, taking that defense factor, we calculate the final damage value with this formula:

Damage - (Damage * Defense)/$20

When I was studying this the other day, I noticed that a character who lost the first round of a match had their "power index" value slightly raised in the second. This reminded me of some talk of a "comeback boost" system that I had only rarely heard. Well, it seems that's what this is.
OK, here's what can be considered my first serious hack: Hitbox Viewer for SF2'T (romset sf2tj). This hack activates the game's built-in hitbox display without activating any of the weird dipswitch side effects.

MAME doesn't like hacked ROMs, so I'd recommend trying it out in Kawaks or Final Burn.

I had been planning on making a hitbox viewer with LUA script (I might still eventually anyway), but I started picking up on this ASM stuff quicker than I expected. The hitboxes are still in their original, not very helpful colors (body1 and foot are the exact same shade of brown, etc.), but I'll see about changing that later.
Post a thread on SRK with your hacks because you won't get much out of it here =(

The hack seems alright for someone getting into the game and seeing move priorities etc. MAME has been OK for me with hacked ROMs but maybe because I always run it with the -debug switch. It'll complain about the ROMs being wrong CRC32 and such but will allow me to run it.
Ah, I haven't been to SRK in a while. I'll make sure to post it there.

Can anyone help me figure out how I would go about editing CPS1/2 graphics? They're definitely compressed, because they come out as a tiny little block of random pixels in GGD. I have no idea what format the compression is, though. I suppose the MAME driver sources would detail it, but I can't make much sense of them. I do know that both systems have 4 different graphics types, Scroll1 (8x8 tiles), Scroll2 (16x16 tiles), Scroll3 (32x32 tiles), and Obj (16x16 tiles for sprites).

Strangely (or maybe not? I'm new to this, so maybe it's common), there also seem to be ASCII strings within the graphics ROMs. Presumably leftovers from some compiling process, because they mention Symantec Think Libraries and such.

On another note, I know a bit about the CPS2's sound system. The waveform ROMs are raw PCM (maybe byteswapped?), and the pointers that denote the start, end, and loop points of the individual samples are usually at 0x8000 in the Z80 ROM. I did manage to do some very simple hacking with it (replacing a bass sample in Vampire Hunter with one from Super Street Fighter II Turbo).
Unfortunately it looks like the code for the Object Test menu isn't in SSF2T. I found the routine that loads the text from that big block, but none of the branches to it in the code seem to load that particular text. There's also some other leftover development text there that never gets loaded.
you could always roll your own. If you know the format for graphics/hitboxes then you can set up some text printers in 68k and display it all on screen. CPS1/2 video looks very simple from what I've seen.

The GFX definitely won't be compressed if it's pulled straight off the ROMs on the PCB. A single tile make be split across several ROMs and be laid out in a strange format. If a tool doesn't exist for conversion already, you'll have to write one yourself ofcourse. NeoGeo sprites are interleaved and you must combine a pair of 'C' ROMs to get actual visible GFX to view/edit. There's a tool that already does this but I'm not sure about CPS.

There's also strings buried in QSound sample ROMs of some games, but nothing that will help much. Just diagnostic strings from the sample converter Capcom used if I remember right.
Considering that from what I've seen, much of the data structure of the CPS2 SF2s is the same as the CPS1 ones, and that both systems use the same processor, I suppose I could copy the code from one of the CPS1 ROMs into a CPS2 one and tweak as necessary. I think that's a bit beyond my current ability, but it's something I can aim for eventually.

And thanks for your input and advice, smkdan.
Awesome thread ! I used to be a streetfighter 2 fiend when i was younger , and i remember there was this hacked version with 2 guiles, 1 guile replaced e honda,. Ive tried searching for this version , or any info about it and i cant find a single thing ,.
How would i go about recreating this version? Ie swithching e honda for another guile?
Sweet! Thanks for making this! I've always been a bit interested in SF hacking. You should try researching SFIII (that would take forever). Is there any way to edit graphics or music? I'm sure it's obvious or something, but really all I can do is play the games and (I think) edit palletes.
Sweet! Thanks for making this! I've always been a bit interested in SF hacking. You should try researching SFIII (that would take forever). Is there any way to edit graphics or music? I'm sure it's obvious or something, but really all I can do is play the games and (I think) edit palletes.

MAME emulates CPS3 well enough and has an SH2 debugger so everything is there to hack into the games. The encryption is really simple and doesn't really get in the way at all.

I've gotten plenty of use out of it (and the cps3.c source which documents the system very well) for a bit of security cart hacking. That and people have already hacked 3S from what I've seen to add neat little extras.
Pages: « 1 »
Forum Index - Non-SMW Hacking - Misc. ROM Hacking - Street Fighter II Research (*Hitbox Viewer Hack!*)

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

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

Total queries: 9


Follow Us On

  • YouTube
  • Twitch
  • Twitter


  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • MFGG
  • Gaming Reinvented