Anyone Interested in Doing "SMB Special" for NES?

Started by SMB2J-2Q, February 06, 2008, 11:26:50 AM

Previous topic - Next topic

KingMike

SMB Table:
0..9 = numbers 0xA-0x23=A-Z 0x24=space
"My watch says 30 chickens" Google, 2018

Karatorian

Current ProjectsFinal Fantasy EngineSMB Special for NESStudio Karatorian
@loop: lda (src),y — sta (dst),y — iny — bne @loop — inc src+1 — inc dst+1 — dex — bne @loop

SMB2J-2Q

Some flaws, mostly pipe related in this latest patch:

*Pipe entries missing are in:
**World 2-2 bonus room
**World 2-3, part 2
**World 8-3, start

Please fix these.

~Ben

frantik

what are "pipe entries"  enterable pipes?  is there a problem with the unexpanded roms or does this only occur in the expanded ones?  cause they look right on the unexpanded ones.  the entry in 8-3 start  should be an automatic walk anyways so im not sure

SMB2J-2Q

Quote from: frantik on April 27, 2008, 10:07:29 AM
what are "pipe entries"  enterable pipes?  is there a problem with the unexpanded roms or does this only occur in the expanded ones?  cause they look right on the unexpanded ones.  the entry in 8-3 start  should be an automatic walk anyways so im not sure

I am talking about the fact that some of these pipe entries were replaced by question blocks, if that should help the both of you involved in this project.

Karatorian

#325
I think I know what's going on with the problematic pipes. In an unmodified SMB, you can create IntroPipe objects using object ID 0x0C, although they're normally created with a special row 13 object instead. Apparently, some of Frantik's pipe objects where using the 0x0C method instead. As the new blocks use object IDs 0x0C through 0x0E, they've become question blocks instead.

I belive the 0x0C method may allow more control over the location of the pipe object, but I'm not sure. If that is the case and the extra control is needed, object 0xF can be used. It's unused and will fall through to the special row 13 objects like 0xC used to.

Actually in the unmodified SMB engine, IntroPipe, FlagpoleObject, AxeObj, and ChainObj can all be created using normal objects, rather than the row 13 objects they've been assigned to. Therefore, when additional normal objects are added (like I've done), all of those object types are potential bugs if they where created using normal objects.

I've gone through the sprite data with a fine toothed comb and have figured out what we need in the way of space. The new sprites Frantik has made use up a total of 40 tiles. The sprites used only in castles take up a total of 28 tiles. There is 1 tile that is unused. Therefore, we're 11 sprite tiles shy. I'm not entirely sure how to handle this.

I've been thinking of dividing the CHR-ROM banks up along the lines of Castle levels and everything else. The reason for this is that the ground type uses so many sprites that the other types are nearly subsets of the Ground type. However, there are some gains to be had by spliting the Underground and Water levels out. The Falling Spike isn't using in ground levels, so we could gain 4 tiles there. There are three sprites used in water levels that are not used in ground levels, they are the bubble and two tiles of Mario animations for swimming. This could save us 7 more tiles, leaving us only 3 shy.

The other option I considered is using seperate banks for large and small mario. I've yet to investigate exactly how many sprites we could free up this way. It would definetly be enough to free up the 11 tiles needed for the Castle vs Everything Else divsions. Of course, that'd still require 4 CHR-ROM banks. It may even be enough to get down to only 2 CHR-ROM banks (small and super).

I'd prefer to keep it down to 2 CHR-ROM banks unless absolutely required. To do that, we have to either eliminate 11 tiles or (provided there's space) use small and large mario banks. If we do end up going with 4 banks, there are two options. First, we could ditch 3 tiles and make a bank for each level type (we could use three in this case, but I don't think that's actually possible). Or, have small and super banks for each of the castle and everything else levels.

Frantik, as you've been the guy handling the graphics so far, what do you think? Would it be possible to eliminate 3 (or even better, 11) tiles somehow and still have everything look good?

Anyway, I'm going to investigate the Mario tiles more closely and see what kind of space we can gain by swapping CHR-ROM banks based on size. If I can get all 40 new tiles in that way, that's what I'll do. Otherwise, we'll have to discuss what option to go with.

Edit:

I looked through the Mario sprites and here's what I found. Mario uses 91 sprite tiles, of which 61 are Super Mario, 29 are Small Mario, and 1 is used only when in between sizes. Small mario is the limiting factor here, adding the 29 Small Mario tiles, the 1 intermediate tile, and the 1 unused tile gives us a total of 31 tiles. This would leave us 9 sprite tiles shy if we decided to bank switch only on Mario size changes.

I've been thinking about how we could free up some tiles. Simply looking at new sprites, I've found a few places where symetry could be increased (at the expense of accuracy) to free some tiles. If the hammer where made symetrical, we could elimate 2 tiles. If we used the Hammer Bro hammer instead, we could eliminate 4 tiles. The "atom" power up could be reduced to 2 tiles with basically no change, or to 1 if the little highlight was removed. By redesigning the wing to look more like the SMB3 one, I belive it could be done in 3 tiles. By making the spike symetrical, we could reduce it to 2 tiles.

But would such changes be a good idea? Discuss it and tell me what you think. I'm off to write some CHR-ROM switching routines to add to my MMC1 driver code.
Current ProjectsFinal Fantasy EngineSMB Special for NESStudio Karatorian
@loop: lda (src),y — sta (dst),y — iny — bne @loop — inc src+1 — inc dst+1 — dex — bne @loop

frantik

QuoteI think I know what's going on with the problematic pipes. In an unmodified SMB, you can create IntroPipe objects using object ID 0x0C, although they're normally created with a special row 13 object instead. Apparently, some of Frantik's pipe objects where using the 0x0C method instead. As the new blocks use object IDs 0x0C through 0x0E, they've become question blocks instead.

yeah i realized this must be what was happening :)

Karatorian

As I started implimenting CHR-ROM switching, I realized something, the MMC1 can split the CHR-ROM into two 4k banks. I had originally thought it only did the full 8k. As we'll be required to double the size of the bank anyway to respect the powers of two, we actually can have three banks. Well, not actually three banks, but rather three banks of sprites and one bank of tiles.

Knowing this, I've decided that the cleanest way to impliment the CHR switching whould be to have one sprite bank for ground levels, one for castle levels, and one shared between underground and water levels. As mentioned above, this still leaves us 3 sprite tiles over our limit, but I think that's something we can deal with.

Somehow it's ironic that once I actually started coding, most of the (obnoxiously long, I appologize) post I made above was rendered irrelevant. Hindsight's 20/20 and all that. He he.
Current ProjectsFinal Fantasy EngineSMB Special for NESStudio Karatorian
@loop: lda (src),y — sta (dst),y — iny — bne @loop — inc src+1 — inc dst+1 — dex — bne @loop

strfr

#328
Looking at Frantik's sprites, I personally think that they need a little extra work before they are inserted.  A minor issue I saw was the coloration in the Hudson bee's insides - they are supposed to be 2 combined dithered colors -> 1 color based on how Hudson drew it.  Two colors appear to switch with each other between the two Fighter Fly frames.  As for animating the flaming barrels, I think the barrels could flicker as quickly as possible between the normal barrel frames and the fire enemy frame - though that could be uncomfortable to watch.  IMO a different frame for the Side Stepper could also be used for reflection animation (ala Goombas) to show the illusion of motion better than the existing frame for it.

Also, sorry if I sound lazy to find out myself, but is the fire enemy (not the fiery barrel) used in Super Mario Bros. Special?  Or is that fire enemy frame only used for the flaming barrels?

Side Steppers have "angry" frames in the original Mario Bros. games.  Do Side Steppers also get angry in SMB Special?

Karatorian

I somewhat agree with those critiques of the sprites. However, I'll leave it up to him to decide if they should be changed or not. In general, I think they tend to follow Hudson's sprites pretty exactly, which is unfortunate, because Hudson's sprites aren't really that good looking.

What do you mean by "fire enemy". The only fire enemies besides the flaming barrels that I can think of are the Firebars and the Podobos, both of which SMBS uses.
Current ProjectsFinal Fantasy EngineSMB Special for NESStudio Karatorian
@loop: lda (src),y — sta (dst),y — iny — bne @loop — inc src+1 — inc dst+1 — dex — bne @loop

MathUser2929

He means that flame graphic in that blank rom is actually a enemy found in Donkey Kong.

frantik

QuoteI think they tend to follow Hudson's sprites pretty exactly, which is unfortunate, because Hudson's sprites aren't really that good looking.

i agree they are fugly but it's not like the rest of the SMB1 graphics aint fugly lol.  i just took the existing graphics and converted them to nes as directly as possible.  we can go with modified graphics though i dont mind


rbudrick

I too am in favor of doing the graphics as exactly as possible, only it seems SMBS had some color limitations.  It may be good to consider what colors the items would have been if they could have used SMB NES's pallette.

As far as adding something to the ending, I think it would be better to add to the title screen like all hackers, heh heh.  I dunno, just an accuracy thing.

-Rob

Karatorian

#333
So I went through the sprite data and figured out exactly what every tile was, how many tiles each sprite took up, what was really needed in each level type, etc. and found something out. Apparently, my earlier numbers where a little bit off. We've got enough room to fit all the graphics in without a hitch, even on the heavly occupied ground type levels.

I constructed the following chart to guide myself as I move forward with the sprite bank assignments. However, as I've looked into the matter, I keep having obnoxious math errors creep in, so I figured I'd share my results and let anyone who's interested proof them, in case I missed something. Am I missing any sprites? Are any of the level types missing sprites? Is my math wrong anywhere? (Note, I already reduced the Atom to two tiles simply by moving it up one pixel. Also, the Other type is both Underground and Water areas.)


Base 179 (77 free)

91  Mario
9  Floaty Numbers
2  Platform
4  Coin
2  Fireballs
3  Explosions
4  Blocks
1  Blank

4  Mushroom
2  Fire Flower
4  Starman

4  [Honeybee]
4  [Hammer]
3  [Clock]
4  [Wings]
2  [Atom]

5  Goomba
13  Koopa
4  Parakoopa
10  Buzzy Beetle
6  Piranha Plant

Ground 76 (1 free)

18  Hammer Bro
18  Latiku and Spiny
6  Cheep Cheep
4  Bullet Bill

4  Castle Flag
2  Flagpole Flag
2  Vine
4  Jump Spring

4  [Side Stepper]
6  [Fighter Fly]
4  [Barrel]
4  [Flaming Barrel]

Castle 38 (39 free)

18  Bowser
5  Peach
3  Toad
2  Podobo

2  [Falling Spike]
4  [Barrel]
4  [Flaming Barrel]

Other 18 (59 free)

6  Cheep Cheep
3  Blooper
1  Bubble
2  Mario Swim

4  [Side Stepper]
2  [Falling Spike]


As for the graphics, I'll be fine with whatever direction we decide to take them. While I've strived for accuracy in many parts of this project, I don't belive we have to have everything exactly as the PC88 version. Rather, I think the goal of this project is (or should be) to create SMBS as it would be on the NES. If the graphics could use a little tweaking to better match the rest of SMB's art (which may not be great, but it's not as bad as SMBS's), then I'm for it.

As for adding a custom ending screen, it's not true that all ROM hackers edit only the title screen. Larger projects often alter the credits sequence as well. Of course, SMB has no credits sequence, but I think adding one would be a good idea. I rather like how the current title screen only has the one subtle line at the bottom. Adding full credits to the title, even if it just said "Karatorian and Frantik" or some such would clutter it up. (I've seen many title screens that where destroyed by that sort of thing.)

Also I've been thinking, we could do a little research and credit the teams at Nintendo and Hudson. They are the giants on who's shoulders we stand.

Edit:

Doh! I just realized that one we get the wing power up implimented, we'll need the swim animation tiles in ground levels too. Damn, were're still one tile over. (I knew it was to good to be true.)
Current ProjectsFinal Fantasy EngineSMB Special for NESStudio Karatorian
@loop: lda (src),y — sta (dst),y — iny — bne @loop — inc src+1 — inc dst+1 — dex — bne @loop

strfr

Quote from: Karatorian on April 28, 2008, 12:21:36 PMWhile I've strived for accuracy in many parts of this project, I don't belive we have to have everything exactly as the PC88 version. Rather, I think the goal of this project is (or should be) to create SMBS as it would be on the NES. If the graphics could use a little tweaking to better match the rest of SMB's art (which may not be great, but it's not as bad as SMBS's), then I'm for it.
With what you said in mind (specifically what I made in bold), there are certain level designs in SMBS with puzzles that took advantage of the PC88's lack of scroll.  One in particular is a puzzle where if small, Mario needs to get a mushroom to enlarge and break a brick to escape.  Now with this goal in mind, I think the level designs may need to be considered for change to make them practical on the NES.

frantik

Quote from: strfr on April 28, 2008, 07:55:50 PM
One in particular is a puzzle where if small, Mario needs to get a mushroom to enlarge and break a brick to escape.  Now with this goal in mind, I think the level designs may need to be considered for change to make them practical on the NES.

if you're talking about the puzzle in world 2 with the hidden coin block.. that puzzle still works with the scroll :)  I tried to ensure the level designs retained the game play aspect as much as possible to the point accurate gameplay trumped accurate level design.  please let me know if there are any parts which could be changed to be more accurate to the game play

Karatorian, regarding sprites, if we just need 1 more i'd suggest perhaps using only one tile for the vine and or redesigning some of the new sprites.  I went and got the hudson bee from Adventure Island and it looks way better than the SMBS one lol..

strfr

Quote from: frantik on April 28, 2008, 08:12:33 PM
if you're talking about the puzzle in world 2 with the hidden coin block.. that puzzle still works with the scroll :)  I tried to ensure the level designs retained the game play aspect as much as possible to the point accurate gameplay trumped accurate level design.  please let me know if there are any parts which could be changed to be more accurate to the game play
Huh...I remembered something else that could get you stuck in that screen if you scrolled too much...I have a feeling that it was hitting the mushroom block when the screen scrolled way too far.  But I could be wrong.  :P

frantik

#337
Quote from: strfr on April 28, 2008, 09:55:35 PM

Huh...I remembered something else that could get you stuck in that screen if you scrolled too much...I have a feeling that it was hitting the mushroom block when the screen scrolled way too far.  But I could be wrong.  :P

i thought i tested it and the mushroom would still bounce off the wall even if it was off screen but perhaps you can get the screen to scroll too far .. if anything it just makes it a tougher puzzle lol ;) [edit: i tested it and couldn't get the screen to scroll too far.. the mushroom is always possible to get (assuming you don't block it in with the coin block).  i guess though you're less likely to block it in cause the hidden coin is off the screen once you can hit the mushroom block

i updated some of the sprites including the hudson bee from adventure island, two versions of the modified atom and two versions of a modified p-wing.  i think the atom with the one dot in the center is better than the atom without the dot, but if we're in a bind for one tile it's a good candidate for timming imo.  The wing w/o the outline matches the rest of the game graphics better than the one with the outline, even though the outlined one is better overall

new smbs sprites


another option for gaining one more tile would be to use tile 0x27 as 0x07 cause they are very very similar.  You would just need to modify tile 0x05 to match 0x027 better.  I included the modified tile 0x05 in with the sprites.

Karatorian

#338
I just found a mistake in my table, which explains why everything suddenly fit when it didn't before. The Blooper is missing from the ground enemies list. That's another three tiles. Arg, it's enough to make me pull my hair out.

Edit: I just realized that the blooper is actually four tiles. Things just keep getting worse. Five tiles, damn.

Ok, I think we can make it work.

I just noticed that the top of the Barrel enemy is symetrical, so it's actually only three tiles. I made a version of the Honeybee (the Adventure Island one) with a symetrical head that still looks pretty good. The Mario alteration suggested by frantik makes three, which only leaves two to go. The atom could be reduced to one, but the one with the highlight does look much better. It might be possible to make the left half of the wing symetrical, although, none of my attempts to do so have looked any good. I think I've found a way to reduce Lakitu by one tile.

What else can we do?
Current ProjectsFinal Fantasy EngineSMB Special for NESStudio Karatorian
@loop: lda (src),y — sta (dst),y — iny — bne @loop — inc src+1 — inc dst+1 — dex — bne @loop

BRPXQZME

"What? Whatta you doin' there? You belong in the water! There's no water here!"
we are in a horrible and deadly danger