"Street Fighter II" for the NES theoretically possible?

[mikejmoffitt]

They also lack any significant level management, since arenas are hardly wider than 2 screens and have very few interactions with the players.

This is a good point - using two pages of tiles I don't think any actual work would have to be done for scrolling in regards to loading tiles, changing attributes, etc.

[MottZilla]

It could be done, but you'd have to take shortcuts with hitbox accuracy, collision detection, etc.

I disagree. Older fighting games (like Street Fighter II) are not computationally intensive at all, seeing as there are few active objects and hardly any object management (objects aren't created/destroyed that frequently or in large quantities). They also lack any significant level management, since arenas are hardly wider than 2 screens and have very few interactions with the players.

I agree. I don't think SF2 would have any trouble on the NES. For instance, unlike SNES, you have nearly instant bankswitching to load new fighter graphics for any frame of animation. And I do think typically the level/arenas are only 2 screen widths wide so you don't even have to update nametables during scrolling. You'd have all the time you could need to run a GOOD fighting game engine. An experienced developer/team could probably make a version of SF2 on NES that is actually fun to play. And as I said, there are numerous ways you could have all 6 attacks.

[JimDaBim]

Sooo. Anybody interested to actually do that game? I would volunteer to rip all the necessary graphics from the arcade version. And to resize them if you can provide me a fitting algorithm.

[Dwedit]

Maybe use rotsprite to do the resizing. edit: nope, rotsprite doesn't let you change the aspect ratio.

[JimDaBim]

What would rotation have to do with it anyway?

[Dwedit]

Rotsprite also resizes better than the nearest-neighbor algorithm.

Here's a mockup I did of Ryu (SNES), it's attached here.
Based on http://www.nes-snes-sprites.com/StreetF ... Turbo.html then color-reduced down to 10 colors, obviously needs more work to become proper NES graphics.

Obviously, the mockup could be done much better, for example, getting every sprite on the sheet properly aligned before resizing.

[tepples]

Maybe use rotsprite to do the resizing. edit: nope, rotsprite doesn't let you change the aspect ratio.

Rotpixels, my Python/PIL based rewrite of rotsprite, does.

Aspect ratio correction is a form of scaling. Rotation, scaling, and shearing are all special cases of affine transformation. Rotsprite and Rotpixels are designed to perform affine transformation on pixel art while avoiding some of the undesirable edge artifacts commonly associated with nearest-neighbor resampling.

[mikejmoffitt]

It could be done, but you'd have to take shortcuts with hitbox accuracy, collision detection, etc.

I disagree. Older fighting games (like Street Fighter II) are not computationally intensive at all, seeing as there are few active objects and hardly any object management (objects aren't created/destroyed that frequently or in large quantities). They also lack any significant level management, since arenas are hardly wider than 2 screens and have very few interactions with the players.

I agree. I don't think SF2 would have any trouble on the NES. For instance, unlike SNES, you have nearly instant bankswitching to load new fighter graphics for any frame of animation. And I do think typically the level/arenas are only 2 screen widths wide so you don't even have to update nametables during scrolling. You'd have all the time you could need to run a GOOD fighting game engine. An experienced developer/team could probably make a version of SF2 on NES that is actually fun to play. And as I said, there are numerous ways you could have all 6 attacks.

I don't see how bankswitching is very useful here, unless you have a lot of banks and they are all extremely optimized for the situations.

For example, for a Ryu vs Chun Li match, if you wanted to change banks to switch to different animations, we'd either have to

1) have Chun Li also do different things whenever Ryu is using an animation from another bank, or
2) have four banks to fit both combinations of animation switches.

Using CHR-RAM, could any of this be simplified?

As for the graphics, I think best results would be obtained with redrawing of graphics, maybe based on scaled versions. Sprites overlapping one another to expand color palette should be minimized in order to keep flickering down. Maybe Ryu could just be dark brown, skin, and white for his body, and then a single red sprite could handle his headband and maybe dark blue hair shine? Those SNES-based sprites look pretty good, but I would be worried for what it would be like with two sets on-screen, especially with two players using different palettes.

[Shiru]

Mappers like MMC3 allow to switch 1K/2K parts of the CHR, so it helps a lot for a fighting game - you can select needed frames of two characters with just two register writes. With CHR RAM you would have to upload frames, which will take many TV frames to complete and require double buffering, as you only can upload like 300 bytes per frame. So actually bankswitching is the only real option for a fighting game on the NES, and that is what they actually use (TMNT Tournament Fighters, for example).

Answering to the original question, well, with all these chinese bootleg Street Fighter ports and other fighting games (Fatal Fury, Samurai Spirits, Mortal Kombat, etc), it is clear that it is possible - these ports just needs some polishing that is lacking, especially in the controls and the music. A good fighting SF-like game is also there, the Tournament Fighters. One major problem is that large sprites will have to flicker inevitably, so choosing a smaller size, perhaps without BG scrolling even (not really needed with small sprites), could help to create better impression.

[Sik]

It's been attempted: https://www.youtube.com/watch?v=_hQjFpGB6_k

That's actually one of the poorer attempts - this one (which is not by Yoko - it's a titlescreen hack of this one) is a bit better.

I think Street Fighter III is the original version actually (although it never had any copyright mention at all so I don't get from where the video author got that it's from Yoko).

But yeah, that's pretty much the best attempt so far, as in "it's the only one that's even playable at all". Shame they didn't port the music =| Also that's some rather good job with the backgrounds there (and even moreso with the sprites). Three of the characters are gone, but then again those are the big size characters so I guess that may be the reason. And Claw is still a bitch as usual.

And there must be several revisions because in the cartridge I had only eight backgrounds would be used at all (Dictator's stage uses Chun Li's background). I don't get that problem in emulators. No idea why, probably a different ROM. (also I used to have the great idea to play the game at the hardest difficulty back then... *sigh*)

[infiniteneslives]

I don't see how bankswitching is very useful here, unless you have a lot of banks and they are all extremely optimized for the situations.

For example, for a Ryu vs Chun Li match, if you wanted to change banks to switch to different animations, we'd either have to

1) have Chun Li also do different things whenever Ryu is using an animation from another bank, or
2) have four banks to fit both combinations of animation switches.

Using CHR-RAM, could any of this be simplified?

The combination finely banked CHR-RAM can be pretty powerful. Using 32-128KB of CHR-RAM on a MMC3 give you 32-128 banks of RAM to work with and 4 of them (1KB each) are visible at once for use with sprites. So 2 banks per character, or some other uneven method of sharing with one fixed/shared and 3 for animations. 32-128banks is quite a few banks if they only have to store what needs to be viewed in the current fight, so they don't have to be horrendously optimized. With that much you probably wouldn't even have to draw the characters because of bankswitching.

[tepples]

Double buffering could be made to work. There is enough VRAM in the sprite half of the pattern table to hold a unique image for each of 64 sprites twice over. The biggest problem would be vblank time, and that can be extended with a Battletoads-style top status bar and late enabling of rendering.

[tokumaru]

There are other non-pirate fighting games on the NES besides Joy Mecha Fight and the Ninja Turtles game. I can think of Datach's Dragon Ball Z and Yuu Yuu Hakusho games, which use fairly small sprites. I believe these games use CHR-RAM rather than bankswitching.

Also, the Dragon Ball Z RPG games have fighting sequences that look a lot like fighting games, even though characters aren't directly controllable. They do make use of the background color as an extra sprite color though, and one of the characters might be drawn with background tiles instead of sprites, preventing flickering by sacrificing background detail.

[MottZilla]

So far I'd say redoing the graphics in this style would probably suit the NES best. And then you could focus on the other elements that really bring the game together.

Another option: Instead of trying to replicate the arcade game, you could do the "Street Fighter II" equivalent of the NES conversion of "Final Fight": "Mighty Street Fighter II". Someone even created screenshot already:
http://www.listentome.net/omgrngs6.gif
http://www.listentome.net/omgrngs7.gif

[tepples]

In other words, instead of cloning Street Fighter II, clone Pocket Fighter, the fighting game based on the chibi characters introduced in Super Puzzle Fighter II.