Has anyone ever attempted to make SMB1 two players simultaneous? Like Super Mario Bros. Deluxe?
I asked this same question at Romhacking.net, where I was told that the sprites would have to look the same, the rom would probably need to be expanded, extra collision detection would need to be added, & extensive knowledge of ASM is required - which I agree, it's not something that any average hacker could pull off.
Is this something too far-fetched?
Sounds possible. Expand the ROM, probably use a mapper, have more RAM space for an aditional character (luigi) to run their version of what mario's engine is. Make some type of cooperation scrolling, like one that checks if both players are in the scroll area then scrolling is available.
IIRC they both have the same physics in SMB1.
You'd have to patch every single routine that handles player/object collisions--including potentially complex things like the flagpole and end-of-world sequences--to handle two different sets of player variables. SMB1 is also prone to (very glitchy) slowdown when too many things are happening, and that's with just one player...
It's not impossible, of course, but probably not very feasible with the existing game engine.
then there's more practical questions...
How the hell would you scroll the screen with two players?
Dwedit wrote:
then there's more practical questions...
How the hell would you scroll the screen with two players?
How did existing co-op games such as TMNT 2 and 3 do it?
The big difficulty I see with modding the engine of an NES game that doesn't already support two players is palette issues. There are four sprite palette spaces, and by the time you've put in Mario's palette and Luigi's palette, you've already taken up two of them, leaving one for a powerup and only one (instead of two) for enemies.
Oh, oops! Der!
I was thinking maybe Mario or Luigi could share palettes with something else. But then that would screw things up when one of them gets a fireflower or star. I Didn't think of that. :p
Yeah, & the scrolling...
Perhaps when one player reaches the flagpole, the second player will just "lose control" & stand there while the screen focuses on the first player walking into the castle.
And do Mario & Luigi really need hit detection? It'd be fun bouncing on eachother, but it would kind of get annoying as well. How did SMB Deluxe handle this?
By being Gameboy Color and not NES? :p
I'm not familar with the GBC, but I imagine it has a faster CPU than the NES, perhaps a bigger available palette, etc. I think it would be quite a project to try to make it 2 player at once. But if you really wanted to I think you could make it work. But you'll need to expand it with a mapper, maybe get more CPU time by using an IRQ rather than Sprite #0 hit.
I don't think anyone is going to do it though.
MottZilla wrote:
By being Gameboy Color and not NES? :p
Sorry, I was talking about Mario & Luigi's collision detection. How was it handled in SMB Deluxe?
Luigi already uses the exact same colors as the green koopa troopa, but in a different order. Just rearrange mario's colors to match what Luigi's colors would be on a green koopa troopa palette.
Only problem would be that Green turns Gray underwater.
I don't think palettes are such a big issue. Even though the characters might not look exactly the same, I'd say you can definitely squeeze Mario and Luigi there.
It might even be possible to make them look better, if you separated the head from the rest of the body, the head could make use of another palette that has skin tones, while the body uses colors from the palette that is dedicated to the player, where you could fit the colors for the clothes of both characters (which could even be changed individually in the case of fire flowers). That would require some serious modifications to the code, though.
Of course, there is the easy way out: Flickering. You'd show only one of the players each frame, and you'd constantly change the palette between Mario's and Luigi's. It might be acceptable for a 2-player mode.
tokumaru wrote:
Of course, there is the easy way out: Flickering. You'd show only one of the players each frame, and you'd constantly change the palette between Mario's and Luigi's. It might be acceptable for a 2-player mode.
True, however, this is probably the sort of thing that puts the "Warning: This game may cause seizures" thing on games nowadays. This is visually unappealing.
And yeah, You could probably do something about green turning gray underwater. I would probably just edit that part out, and have whatever would use the gray scale palette make do with the green pallet.
tokumaru wrote:
It might even be possible to make them look better, if you separated the head from the rest of the body, the head could make use of another palette that has skin tones, while the body uses colors from the palette that is dedicated to the player, where you could fit the colors for the clothes of both characters (which could even be changed individually in the case of fire flowers). That would require some serious modifications to the code, though.
That worked for Contra, and it worked for Kart Fighter. But Mario and Luigi change the color of their clothes too often for that to work. You
could do something like Super Mario Land 2, where Mario's cap changes to indicate fire status, and something like Super Mario Bros. 3 and Sonic the Hedgehog 2, where more animations change to indicate invincibility.
Quote:
Of course, there is the easy way out: Flickering.
Pac-Man. Atari 2600. Do we want to relive that? I'm with Celius.
Dwedit wrote:
then there's more practical questions...
How the hell would you scroll the screen with two players?
I told you, since it scrolls right whenever the player moves right from a certain point of the screen, it could have some code to detect if both players are going passed that point, then it would start to scroll, and if there's a player behind the point, it wont scroll.
Kind of like Everquest: Champions of Norath, if you've ever played it. You could see if a player was on the very left edge of the screen. If either Mario or Luigi is on the very left edge of the screen, it wouldn't scroll. But each character has the power to advance the scroll by running towards a certain point on the screen (Towards the middle probably). But I suppose it would be nice to have a system where the screen could completely stop scrolling if you wanted it to, and both Mario and Luigi could run around the entire screen if desired.
Battletoads & Double Dragon... plus a few others.
Sure, many games have 2-player scrolling, but this is not a matter of copying those games' systems, it's a matter of modifying the existing SMB code (as little as possible) to do it.
Maybe the camera could be pushed as usual, by either player, but if the other player is far too much to the left, he'd prevent the camera from moving. Something like that.
- Can the palette be virtualized into RAM?
Fx3 wrote:
- Can the palette be virtualized into RAM?
It already is, to an extent. Notice that the game never throws more than two different colors of enemies at the player at once, and if you can run SMB1 in Nintendulator, watch how the palette RAM changes right before the red turtle in 1-2. If you want to put more than four palettes on the screen at the same time, you get even more flicker than what SMB1 already does to fit one 16-pixel-wide player, five 16-pixel-wide enemies, one powerup, two fireballs, and several hammers on the screen at once.
I'm too lazy to read to see if this is already mentioned, but don't forget that you'd have to rewrite the collision subroutine to check if you've hit the other player or not, otherwise you'll die from touching your brother (either appropriately or inappropriately).
Furthermore, how exactly would real-time co-op appeal to someone? It will only slow things down on a game programmed for one player.
tepples wrote:
It already is, to an extent. Notice that the game never throws more than two different colors of enemies at the player at once, and if you can run SMB1 in Nintendulator, watch how the palette RAM changes right before the red turtle in 1-2.
When I tried doing this (with FCEUxD, which also has palette and hex viewers), this doesn't happen at all. However, it
does happen whenever an ax rendered to change one of the palettes to the green palette, used in-game for Bowser. Also, just a little nitpick, but the game can render at most three different palettes for enemies - an actual occuring example in-game would be a Blooper, a Grey Cheep-Cheep, and a Red Cheep-Cheep.
strangenesfreak wrote:
Also, just a little nitpick, but the game can render at most three different palettes for enemies - an actual occuring example in-game would be a Blooper, a Grey Cheep-Cheep, and a Red Cheep-Cheep.
Are there any examples in levels that contain bumpable blocks (that is, not water levels)?
tepples wrote:
Are there any examples in levels that contain bumpable blocks (that is, not water levels)?
Well, you might also need to consider the mushrooms. Specific colors are necessary for them to be differentiated and identifiable - otherwise, it could be confusing to identify what's a Super Mushroom (red) and what's a 1UP mushroom (green or cyan+brown). I wouldn't be surprised if you can encounter a Goomba, Green Koopa, and Red Koopa all at once. Other palette conflicting stuff (jump springs, hammers, fireballs, platforms, beanstalks, coin block hits, flagpoles, and brick animations) could change their palettes during different level/level types, but I think mushrooms (at least 1 kind, the Super Mushroom in this case) need to have specific palettes.
BMF54123 wrote:
You'd have to patch every single routine that handles player/object collisions--including potentially complex things like the flagpole and end-of-world sequences--to handle two different sets of player variables.
It would probably work if there's a double set of player variables and every routine handling the player's collision or physics ran twice with the player id passed as a parameter.
atari2600a wrote:
you'd have to rewrite the collision subroutine to check if you've hit the other player or not, otherwise you'll die from touching your brother (either appropriately or inappropriately).
From going over the collision code in Doppleganger's commented disassembly, it doesn't look like that's an issue as long as both players have their own data separate from the enemy object data. As is, both players and their fireballs should just pass through each other much as the hammers ignore the breakable blocks. And they have to, or a few jumps in the game will be impossible.
Of course, there's some other issues that haven't been mentioned yet:
-what happens when one player cuts the bridge with the other guy far behind? If the hacker lets the poor sap fall in the lava that would be pretty funny.
-what if one player takes the lower path in 4-4 and the other takes the middle path which turns out to be a deadend?
-who gets the power-ups? Maybe a player who already has a fire flower shouldn't be able to get another one.
-will a dead player respawn in the same place ala Contra?
Quote:
-will a dead player respawn in the same place ala Contra?
You could use the same technique they use in Battletoads.
Super Smash Bros. Brawl's co-op adventure mode handles it in the fairest way I've seen: the player can respawn only at certain relatively safe X coordinates, and it seems to wait for one of those to scroll onto the screen before respawning.
This thread is a few months old, but oh well...
I don't want to kill the authenticity of the project, but perhaps we are looking at this all wrong. Maybe the best(and possibly the least daunting) way to achieve 2p Co-op SMB is to make an engine for the PC that closely, if not precisely, recreates the physics and graphics of the original, with the addition of a 2 player mode. I would imagine that it should look something like this:
On a PC, it's 320x240 resolution also is better, because it gives more room for 2 players to move around in, compared to the 256x225 of the NES. Also, the reserve item would have the option of being disabled, for those who are looking for more authentic gameplay.
Someday, I will make this... when I finally get around to becoming a programmer.
PC recreations are just so... uninteresting! Personally, I get a real kick out of the challenge that is making things possible on the NES. With current PC's, almost everything is possible, and, in my opinion, that makes the development of retro games for it pretty dull.
The casual gamer probably doesn't care, as long as he's got a playable game. A lot of people around here, including NES programmers, apparently feel like that too.
Would it even be possible to add code to the SMB ROM without bank switching?
tokumaru wrote:
PC recreations are just so... uninteresting!
But a lot more people have a PC capable of running Allegro games than an NES and a PowerPak or other copier. Heck, there are probably more PCs connected to an SDTV or HDTV than NES systems with an NES copier. As Bananmos might put it, if you are writing a program to be run in RockNES, an emulator written in C with the Allegro library, why not just code for Allegro itself?
tokumaru wrote:
Personally, I get a real kick out of the challenge that is making things possible on the NES.
The first problem with 2-player SMB style game would be palettes:
- $3F11: colors for Mario and red Koopas (peach, red, brown)
- $3F15: colors for Luigi and green Koopas (peach, green, brown)
- $3F19: colors for power-up
- $3F1D: colors for only ONE more type of enemy
It's also part of why there weren't a lot of four-player games for the NES, as everything needed to use one of the players' palettes. There wasn't as much of a problem on the Super NES, which had eight palettes that were commonly divided into 2 sub-palettes each.
The second problem would be horrible sprite flicker when Mario, Luigi, and several Goombas are on platforms of equal height.
strat wrote:
Would it even be possible to add code to the SMB ROM without bank switching?
Probably not. But if I were expanding SMB1, I'd rearrange it into UNROM based on the published disassembly. The problem with expanding an NES rom, of course, is that no commonly used patcher (e.g. IPS, NINJA, UPS) supports the kind of rearranging that would result from disassembling and reassembling a rom.
tokumaru wrote:
PC recreations are just so... uninteresting! Personally, I get a real kick out of the challenge that is making things possible on the NES. With current PC's, almost everything is possible, and, in my opinion, that makes the development of retro games for it pretty dull.
what about recreations like
Metroid Cubed or Bionic Commando Rearmed? recreating the look and feel of an NES game(or any system) on newer hardware has it's own set of challenges. hell i had enough trouble getting my Pitfall clone to feel right, as simple of a game as that is; and i still don't have it as close as i would like.
There is another possibility. One of the demos by Bob Rost showed IRQs can have seperate palettes. So maybe it can be applied to the Player colors, as well as enemies.
10 years later, this dream has become a reality. A ROM hack was recently released that adds the ability to play 2-players simultaneously in Super Mario Bros. You may find it here:
https://www.romhacking.net/hacks/4180/Incredible to see the amount of work that was put into this. I'm not super familiar with NES programming, but I'd for someone to look into this more and see how this feat was pulled off. It appears that it's using Mapper 24, but I'm sure there's a lot more interesting information can be be uncovered here.