Would a "Super Mario Bros." hack with a two-player simulatenous mode be possible? Let's assume Luigi shares his palette with the Koopa Troopa, could this actually be done?
It'd increase flicker when the "group of three Goombas" object and "moving platform" objects appear; these are six sprites wide. Whom would the scrolling follow? What palette would Luigi use when he gets the Fire Flower?
And here's the kicker about why it'd be easier to do it in a from-the-ground-up engine using SMB1's level data than in a hack of SMB1: Where in memory would Luigi's position and velocity be stored?
tepples wrote:
It'd increase flicker when the "group of three Goombas" object and "moving platform" objects appear; these are six sprites wide.
Yeah, but that could be an afterthought.
tepples wrote:
Whom would the scrolling follow?
The player who is ahead. Or calculate the middle value of both x values.
tepples wrote:
What palette would Luigi use when he gets the Fire Flower?
Red Koopa Troopa.
tepples wrote:
And here's the kicker about why it'd be easier to do it in a from-the-ground-up engine using SMB1's level data than in a hack of SMB1: Where in memory would Luigi's position and velocity be stored?
I don't know. Some new variable.
Yeah, maybe one would have to disassemble the program and program the changes instead of altering the ROM directly.
But a completely new engine, this means that maybe not everything would necessarily work like in the original, right?
DRW wrote:
tepples wrote:
Where in memory would Luigi's position and velocity be stored?
I don't know. Some new variable.
If RAM is already full, wouldn't adding a new variable require adding an extra 6264 and 7420 to the cartridge board?
Quote:
But a completely new engine, this means that maybe not everything would necessarily work like in the original, right?
Not everything
should work like in the original. Super Mario All-Stars fixes the minus world, for instance. But the jumping physics is documented. (I have to leave for work so I can't search exactly where right now.)
This has been discussed in the past:
thread (spoiler: nothing interesting came out of it)
It's definitely possible to make a two player pretty exact clone of Super Mario Bros. Will it happen? Don't hold your breath.
The kiss of death for a two-player hack would be one player taking the wrong path in 4-4; there's no way to work around that without breaking the game rules. Both players would have to cooperate on every little movement to make the screen scroll properly. What might be interesting is a PC remake where the playfield stretches between both players ala NSMB Wii, but even that could look funky with the pattern castles, or just take the uncreative way out and do a split-screen ala Sonic 2.
strat wrote:
or just take the uncreative way out and do a split-screen ala Sonic 2.
There's at least 1 NES game that does this: Mappy Kids. With 4 screens you could even keep PPU updates mostly untouched, and an IRQ could be used to split the screen. Lowering the height of the viewport shouldn't cause much trouble, seeing as SMB DX did it successfully.
Palettes would still be an issue, and the positions for active sprites would have to be calculated twice, which could result in slowdowns. In fact, slowdowns should be a big concern, since the game already slows down as is.
BTW, I know you probably suggested this for a remake, but I figured it would be fun to consider something like this on the NES.
In a split screen palettes wouldn't be an issue if you split the palette as well and didn't draw both players on both screens.
Slowdown might be obviated by doubling all the movement speeds and targeting a 30fps update, but for this to work you'll probably need that WRAM available as a render data buffer. (Also, having an IRQ available for the split would make it a lot easier on you.)
tokumaru wrote:
strat wrote:
or just take the uncreative way out and do a split-screen ala Sonic 2.
There's at least 1 NES game that does this: Mappy Kids.
Bigfoot, Spy vs. Spy...
Quote:
With 4 screens you could even keep PPU updates mostly untouched, and an IRQ could be used to split the screen.
Which brings the problem of storing the collision map for the part of the screen where Mario is and the part where Luigi is, and remembering what blocks Luigi broke before Mario got there.
Quote:
Lowering the height of the viewport shouldn't cause much trouble, seeing as SMB DX did it successfully.
SMB DX also had 48K of RAM inside the console to work with. And though the 8.5 m tall viewport in Super Mario Land 2 and SMB DX isn't as tall as the roughly 12 m tall usable viewport of SMB1 for NES, it's still a lot better than the 6.5 m you'd get with a split screen. That's not even enough to show the top of Mario's jump curve. Mario jumps 4 m tall from still and about 5 m tall from running; combine that with Mario's 2 m height, and you'd need to scroll on every jump. Sonic 3 solves this by using separate multiplayer maps that are scaled differently, but that would introduce attribute problems unless some simpler-than-MMC5 circuit for ExGrafix can be invented.
rainwarrior wrote:
Also, having an IRQ available for the split would make it a lot easier on you
A simple split halfway down the map is the poster child for a DMC IRQ split.
Now I want to see a remake of SMB that uses 8x8 tiles instead of 16x16. Tiny mario! (I loved the prehistoric section of Earthbound.)
tepples wrote:
Bigfoot, Spy vs. Spy...
I'll give you Bigfoot, but Spy vs. Spy is nothing like Sonic 2... Since the levels don't scroll there isn't even any need to program an actual split.
Quote:
Which brings the problem of storing the collision map for the part of the screen where Mario is and the part where Luigi is, and remembering what blocks Luigi broke before Mario got there.
Yeah, you'll definitely need more memory to keep track of things. As for remembering how the player who's ahead of the other has modified the levels, maybe it would be a good idea to have a single copy of the level in WRAM (I don't know how long SMB levels can be, but it sounds like 8KB might be enough for storing entire levels), that is progressively decompressed by whoever is ahead, without ever being erased.
Quote:
SMB DX also had 48K of RAM inside the console to work with.
And this has anything to do with how a narrowed viewport affects gameplay because...?
Quote:
And though the 8.5 m tall viewport in Super Mario Land 2 and SMB DX isn't as tall as the roughly 12 m tall usable viewport of SMB1 for NES, it's still a lot better than the 6.5 m you'd get with a split screen.
True. We'd have to try and see how that would work out. Maybe if the camera detected jumps and falls it could adjust itself faster than it normally would, giving you more time to react.
Quote:
Sonic 3 solves this by using separate multiplayer maps that are scaled differently, but that would introduce attribute problems unless some simpler-than-MMC5 circuit for ExGrafix can be invented.
Hell no, that would be too much trouble.
Quote:
A simple split halfway down the map is the poster child for a DMC IRQ split.
That or good old MMC3. You can even make use of other MMC3 features, like CHR bankswitching to animate the main characters and have Mario and Luigi look slightly different! Slim Luigi beats fat Luigi any day.
rainwarrior wrote:
Now I want to see a remake of SMB that uses 8x8 tiles instead of 16x16. Tiny mario! (I loved the prehistoric section of Earthbound.)
Then play Super Mario Land on the Game Boy!
tokumaru wrote:
tepples wrote:
remembering what blocks Luigi broke before Mario got there.
Yeah, you'll definitely need more memory to keep track of things. As for remembering how the player who's ahead of the other has modified the levels, maybe it would be a good idea to have a single copy of the level in WRAM (I don't know how long SMB levels can be, but it sounds like 8KB might be enough for storing entire levels)
I'm not aware of any SMB1 level longer than about 32 screens, including all pipe and cloud areas. Each screen is about 16x12 tiles, making the whole map fit in 6 KiB. Or you might be able to get away with storing 192 bits of "has this tile been collected?" per screen for a total of 768 bytes.
Quote:
Quote:
SMB DX also had 48K of RAM inside the console to work with.
And this has anything to do with how a narrowed viewport affects gameplay because...?
It wasn't directly related to the narrowed viewport, just wanted to point out that SMB DX is an example of an engine that uses more memory for some purpose, although a lot of that purpose might relate to how it does The Lost Levels.
Quote:
Quote:
the 6.5 m you'd get with a split screen
True. We'd have to try and see how that would work out. Maybe if the camera detected jumps and falls it could adjust itself faster than it normally would, giving you more time to react.
Mostly it's to be able to see the apex so that the player knows he's not going to jump into a Bullet Bill or Spiny egg or something.
The game I'm doing now has New Super Mario Bros. style co-op. Two players on one screen, they can stomp/shoot/grab each other. Game scrolls like a sonic game (eight way scrolling). The scrolling is an average of their positions, if they get too far apart, neither player can progress further horizontally. (There are more complex rules for when they get vertically far apart, but that wouldn't be an issue in Super Mario Bros.)
Now, you could just keep the players from making the screen go further backwards like the original, which solves the "what has been destroyed issue." You could also just save bits for that stuff in WRAM, it sounds like a total non issue to me.
Far jumps would suck when player 2 is keeping you from scrolling, yes, and the castle mazes would need to be changed or require extreme cooperative maneuvers yes. But nothing about the project seems that far fetched, since I'm already doing most of it in a brand new game. It would just take a lot of time. Really, the only thing that "saves" my game from the far jump issues (and would actually save it from the maze issue too) is that the players can pick each other up. So if your partner can't make a jump, you can just carry him across it. Or carry him across the maze level. Super Mario World added this sort of grabbing for enemies, I'd just add it to SMB for co-op players.
Kasumi wrote:
Far jumps would suck when player 2 is keeping you from scrolling, yes
I think it's less noticeable in NSMB Wii because of how far it's zoomed out and the fact that it's widescreen, so the viewport is more than 16 m wide. It's in fact closer to 32 m wide according to my measurement of a screenshot on Amazon.com, so multiplayer might need to be zoomed out like Super Mario Land. Use Mario's graphic from SML, put him on a diet to get Luigi, and use Toad from Wario's Woods to make Yvan and Wolley. This would require an attribute clash workaround, such as moving pipes to coincide with 2x2 m boundaries. Anyone up for a mockup of a few screens of SMB1 redrawn with 8x8 pixel metatiles?
Quote:
Really, the only thing that "saves" my game from the far jump issues (and would actually save it from the maze issue too) is that the players can pick each other up.
You mean like how Chip carries Dale?
Quote:
So if your partner can't make a jump, you can just carry him across it. Or carry him across the maze level. Super Mario World added this sort of grabbing for enemies
I thought Super Mario Bros. 2: Mario Madness had it first.
Quote:
I think it's less noticeable in NSMB Wii because of how far it's zoomed out and the fact that it's widescreen, so the viewport is more than 16 m wide.
The thing it really depends on is level design. Either way, I doubt anyone's gonna complain if someone makes a CO-OP SUPER MARIO BROS! I'd complain if everything were made smaller! If it doesn't look the same, it doesn't count. May as well be a new game, like mine.
Quote:
I thought Super Mario Bros. 2: Mario Madness had it first.
Okay fine. "At some point Mario games added this ability, so it wouldn't be totally unusual to put it in."
Totally offtopic, long ago I nicknamed you the exception handler, Tepples, because there's never an exception that goes unmentioned.
Quote:
You mean like how Chip carries Dale?
Except with eight directions of throw trajectories.
Meanwhile, in next gen. With... well... ponies...Meanwhile, in next-next gen.It will probably eventually be done. But nothing came in the years since last time it was talked about it, so what are we talking about here? Is anyone picking up the torch of this?
It sounds like the hack method would be flawed and complicated. The new engine from scratch sounds like you may as well make an original game with your own IP. Not tempting.
Maybe DRW should find a similar game with two player simultaneous and hack in SMB sprites and levels.
Kasumi wrote:
Either way, I doubt anyone's gonna complain if someone makes a CO-OP SUPER MARIO BROS!
Related to slobu's point is that Nintendo might complain.
Quote:
Totally offtopic, long ago I nicknamed you the exception handler, Tepples, because there's never an exception that goes unmentioned.
Which I've always thought is a plus for developing reliable software.
How many blocks are onscreen in NSMBW? For NSMB2 on the 3DS, I counted 20x12 blocks of 20x20 pixels. I'm guessing for the Wii there's 20x14 blocks in 3:4 mode, and 27x14 blocks in 9:16 mode, with blocks that are 32x32 pixels.
tepples wrote:
in NSMB Wii [...] the viewport is more than 16 m wide. It's in fact closer to 32 m wide according to my measurement of a screenshot on Amazon.com, so multiplayer might need to be zoomed out like Super Mario Land.
The game is letterboxed when played on a 4:3 screen, so that the players have the same amount of area to move around.
Tonight I got around to making 8x8 pixel reductions of the tiles in SMB1 World 1-1.
I haven't checked the edges of all the background hills, but I don't see any blatant,
hard-to-fix violations of the rule that all tiles in a 2x2 area must have the same attribute.
tepples wrote:
Tonight I got around to making 8x8 pixel reductions of the tiles in SMB1 World 1-1.
That's pretty funny.
Just because I kinda liked the idea of how SMB could look with smaller tiles, I did a small mockup myself.
This uses mostly the same palettes (but a little modified - but the same tiles are still used for the bushes and the clouds) but I took a lot of liberties with the picture. Also the bushes/clouds are not aligned correctly, I noticed this too late and I'm too lazy to fix it
If I wasn't already neck deep in my own NES project I would really, really want to make tiny SMB into an NES game.
tepples wrote:
Tonight I got around to making 8x8 pixel reductions of the tiles in SMB1
This seems familiar.
I'm sorry. I did the obvious riff.
(Tiles added not found in SML: crenellation, castle window, flagpole, flagpole head. The flag is a hill and a ceiling-line, flipped.)
Interestingly, the only tile that seems to use four colors in the original with none supposed to be transparency is the exit door; very few tiles use dark gray along with white.
edit: oops, attribute clash in the bonus room: coins or the ground tile have white, light gray, black; the dead blocks chosen have dark gray.
What happened to Mario?
Anyway, an interesting (and pretty simple) project would be to make reduced SMB tiles and fit them into Super Mario Land.
It appears the SML Mario sprite source had different gray-values than what I used, which then got mashed together when I converted it to indexed because they didn't agree with the other gray values.
He IS normally 10x10(ed:12) pixels though; and even then he doesn't look very Mario-ish. SML had some...odd sprites. The BG was pretty good though.
Perhaps a realization that 10x12 pixel Mario didn't look Mario enough is why Nintendo didn't include a
shrinking mushroom until the NSMB series, which uses a polygonal mesh for Mario.
Just for anyone who comes across this thread in the future, thought I’d mention that a multiplayer mod of Super Mario Bros has been released recently. You may find it here:
https://www.romhacking.net/hacks/4180/As it has been discussed in the previous posts, this is no simple feat, so it’s awesome to see that someone was up to the challenge and create this masterpiece.
DRW wrote:
Would a "Super Mario Bros." hack with a two-player simulatenous mode be possible? Let's assume Luigi shares his palette with the Koopa Troopa, could this actually be done?
It appears that in this hack Luigi does share his palette with a Koopa Troopa, as the the palette does not change for the Koopas while in underground and castle levels.
Really interesting. I wouldn't have thought that anybody actually takes the time and effort to create something like this. That's great work here.
Have not seen any graphic hack to make Luigi has his own sprites. Is it feasibly possible?
Since "Super Mario Bros." is an NROM game, the graphics are fixed. And they are completely full, so there's no room for more. (There are no unused sprite tiles that could be filled.)
If you simply want regular "Super Mario Bros.", but with Luigi's own sprite, one could probably hack the game into a CNROM game where you can replace the whole graphics at once with a second version. In this version, you could draw Luigi's sprite in the place where Mario's is. Then you needed to switch to this alternate graphics bank whenever it's Luigi's turn.
If you want the two player hack with Luigi's own sprite, this would be a bit more complicated:
Since Mario and Luigi are on screen at once, you need both versions of their sprites on the screen, so you would have to use the different graphics banks not for switching between Mario and Luigi, but to switch the enemies in and out.
And this requires an analyzation which enemy combinations will never share a screen with each other, so that you can load the enemies that are visible in this level and omit the ones that aren't.
You could theoretically also convert SMB1 to the MMC5 mapper which gives you double the sprite pages to work with (in 8x16 sprite mode), thus giving room for Luigi. You'd have to rewrite a pretty big part of the game at this point though, it might be easier to just faithfully recreate most of it from scratch instead.
How much vblank time is open in SMB? Given that enemies are never bigger than 6 tiles (96 bytes of tile data) nor player characters bigger than 8, I imagine a lot of the stuff that doesn't fit could be buffered in CHR RAM like how Battletoads does the player characters and Haunted: Halloween '85 does everything.
Going to UNROM would solve so many problems. Imagine a unique design and name for each of the seven Toads. Imagine a 21-world monster incorporating both Super Mario Bros. and The Lost Levels.
This ROM hack already targets the VRC6.
tepples wrote:
Going to UNROM would solve so many problems. Imagine a unique design and name for each of the seven Toads. Imagine a 21-world monster incorporating both Super Mario Bros. and The Lost Levels.
Just like Super Mario Bros. Deluxe on GBC. Except they forgot to put the bounce-off-enemy physics in the Lost Levels, making 7-2 a chore to beat with Mario.
https://youtu.be/3gI6SiaEvKA?t=1572Almost forgot SMB-D omits world 9 and worlds A-D. Though partially complete versions can be played with Gameshark. Blah.
DRW wrote:
If you want the two player hack with Luigi's own sprite, this would be a bit more complicated:
Since Mario and Luigi are on screen at once, you need both versions of their sprites on the screen, so you would have to use the different graphics banks not for switching between Mario and Luigi, but to switch the enemies in and out.
And this requires an analyzation which enemy combinations will never share a screen with each other, so that you can load the enemies that are visible in this level and omit the ones that aren't.
You could also keep track of what enemies are on screen by making a list in RAM and switch out the unused tiles whenever you needed to load a new enemy type. The list could be something simple like one byte for enemy id and one for instances on screen. There aren't too many enemy types in the game so the list should only require a few bytes.
I'm sure this technique is used in lots of games? Playing an MMC5 game like Batman in an emulator will show you tiles being switched every now and then just from walking back and forth in a level. And they don't always load into the same slots as before, so the game must be keeping track of unused tiles and entities in some way.
EDIT: I guess you would also have to have one more byte in the list for what slot the first tile of the enemy is loaded into, so you could use that as an offset for when you load the sprites into OAM.
With some rearranging of tiles, you can take the 2-frame enemies and put each frame in a different bank and animate with switching. The drawback is that all enemies of the same type would animate together.
Combine that with 8x16 sprites and and swapping the font in and out for the status bar will net you some space to squeeze in Luigi's tiles, or other things like a nicer looking castle.