Anyone Interested in Doing "SMB Special" for NES?

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

Previous topic - Next topic


The labels are defined in "levels.s". The data offset is $6000, the start of SRAM, which is where the data ends up by the time the game engine gets ahold of it.

I've got the doc you mention, but it's too incomplete to be really useful when writing something as complex as a level extractor. In particular, it doesn't cover the pointers or offsets at all.

I've managed to hack in three new block types. They are a qestion block with starman (object ID 0x0C), a hidden block with super mushroom or fire flower (0x0D), and a hidden block with special power up (0x0E).

I've also hacked a little bit on power ups and added a placeholder power up for the new ones. As I haven't implimented a method to select which power up the special block gives, it currently gives a black koopa shell that gives a one up.

You can download the source here.

I've managed to find a level editor that works in Wine (YY Mario Edit), so I may release a patch with the new blocks sometime soon. However, I have to go to work now.
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


ok cool now i get it :)

good job on adding the new block types :D  and i tried to make it easy on you by placing "placeholder" blocks" where the new blocks should be so you could go in and edit them without a level editor:

Most of the hidden mushroom/fireflower boxes are replaced with visble mush/FF blocks.  Most of the other hidden power ups are replaced with hidden 1ups
Most of the ? with starman are replaced with brick blocks with starman

edit:  ok one more thing..  how do you determine when to stop reading "World8Areas"?  It's easy to tell where "World7Areas" ends because you can use the offset for world 8 to know where world 7 ends.  but there is nothing obvious which tells you where World8Areas ends and EnemyAddrHOffsets begins.  this same type of problem looks like it will occur when using the other offsets as well so i must be missing something lol

edit2:  looks like you hardcoded the last "offset" into the code (if world == 8: b = 36).  i guess that works cause there will never be more than 36 rooms in the original rom right?  how many rooms in SMBS?


True, I hard coded the end of world eight in the extraction portion of the code. There is really no concrete way to know where the SMB world map numbers end. As for SMBS, I don't really know. While it's easy to figure out by lookin' at the offsets in "levels.s" (37 with the current level set), I've never had any reason to check. My code simply produces as many as required and, as such, has no hard coded limit. (AFAIKT there is no limit whatsoever in the SMB engine itself, except the (eight bit derived) limit of 255 worlds and 255 levels (including pipe intro sequences) per world. Of course, with a room limit of 128 (32 indices times 4 types), that's way more than anyone needs.)

As for adding the extra blocks, it wasn't as easy as I thougt it'd be due to various complications. If I was willing to alter the IDs of existing objects, it would've reduced the changes by about a third, but would, of course, have broken every level. Adding power ups is actually really easy. (Makin' them do interesting stuff may not be.)

As I'm well on my way to implimenting the special powerups and intent to work on enemies soon as well, we're gonna' need some graphics hacking. (Actually, I'm pretty good with GFX myself, but my low res, limited color, works leave something to be desired.) Frantik, as evidenced by your (exellent, I would venture) work on Ultimate SMB, you've achived total mastery of SMB graphics. It would be great if you could produce what we need. (Provided you have the time, of course.)

While I can provide reference shots from the PC88 game if required, I'll simply refer you to related NES and SNES games for now.

From the original Mario Bros., we need (animated) sprites for the Fighter Flies and Side Steppers.

From Donkey Kong we need Barrels, Flaming Barrels, the Hammer Power Up and Hammer Mario (Jumpman in original DK) animation sequences. (I belive we need both small and super mario hammer animations, I'll check tommorow.) In regards to the Flaming Barrels, in SMBS, they look a lot like like Sparkies, so I'd suggest SMW as a reference as well.

The falling spikes have no real pre-SMBS precedence. Wikipedia claims they're supposed to be falling iceicles!? However, with the chosen pallet and (indistinct) sprites, they're pretty open to interpretation. They look pretty similar to the (clearly) spikes in SMW, so I'd recommend that as a reference again.

The wing power up looks pretty much exactly like a SMB3 P-Wing sans the P.

I'm tempted to recommend SMB2 (US, Doki Doki Panic) as a reference for the clock, but given the vastly different function of the item, perhaps that's a bad idea. Something distinct, but still clearly a clock, would be better. I'll post the PC88 graphic when I get the chance.

That only leaves the Hudson Soft Honeybee and the Unidentified Power Up. As the PC88 Honeybee looks more like a bad graphic of a treasure chest than a bee, I'm not sure what to recommend as reference. Perhaps I (or you) can find a good rendering of the Hudson logo to base it on. As I have know idea what the Unknown power up is even supposed to be, I've got no suggestions for references. (I'll post some screenies sometime soon.)

Finally (not to step on a fellow artist's toes), a brief bit on style. While the images in USMB are amazing, they're more SMB3 than SMB. I think it'd be better to stick to an (extreemly) old school style to better mesh with SMB. Of course, given your artistic brilliance, I proably didn't have to mention this, but whatever.

While I've specificaly asked frantik's help with graphics, anyone else who can push pixels is welcome to contribute as well. Given the enormity of this undertaking, more than two hackers working on it would be nice.

In regards to the special blocks, etc. I noticed the placeholders and they're pretty handy. On the other tentacle, editing raw SMB level data with a hexeditor isn't very easy. While I had some success with YY-ME, it's not really going to work out. While it can easily enough create 0x0E objects, its strange interpretation of the object IDs makes adding (real) 0x0C and 0x0D objects impossible. It's a pity SMB Utiliy seg faults under Wine as it's raw hex access feature is perfect for this sort of hack.

One way or another, I'll get the new blocks added where they need to go. What this project really needs is an open source (or, at least, source availble) SMB level editor. Unfortunately, AFAIK, there isn't one. I may end up implimenting one of my own. If I do, it wouldn't be like any other level editor out there. Instead, it'd be more like a special use hexeditor.

Anyway, I've got to work in the morning, so good night.
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


ok well i'm not 100% sure we'll be able to fit all of those enemy sprites on the sprite page of the CHR-ROM but i'll see what I can do :D  And of course i'll make them fit stylewise as well :)  thanks for the suggestions on sprite sources too

dont think i'll need any screen shots the level rips should be fine [edit: actually screen shots of the power ups woudl be cool]

and if you want to tell me what hex values represent what objects i'll go thru and put them in with SMButil..

edit:  got 1/2 my level extractor done.. it extracts stuff nicely.. now time to build the new data file with it :)


If you can't manage to get all the sprites into the CHR-ROM, don't worry about it for now. As long as you get the graphics themselves produced, then we can worry about squeezing them all in. I'll try to get some screenshots produced soon.

The hex values for the blocks I added are all listed in the post I made about them on Thursday.
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


ok i see the values and ill add them in. though the one will cause an L pipe or flag (i forget which) in the editor and in the non-expanded rom unless it's disabled

here's some sprites i pulled off various sprite sheets


The hudson bee is used in Milons secret castle. I think it adds a bar of energy to your  max hp. It also refills your health. Maybe you wanna see what it does in other hudson games.

It's gonna be trippy seeing this patch finished. Expanding the rom, object filled levels. New items. Pretty epic.


In regards to the new blocks rendering improperly in the un-expanded ROMs, yes, that will be a result. This is because when the game encounters a small object in the unused range (0xC - 0xF), it simply falls through to the next category of objects in the jump table (special row 13). As I understand it, there will be spurious L Pipes, Flag Poles, and Axes if the blocks I've added are used in an unexpanded ROM.

(I've realized in retrospect that YY-ME could actually be used to add the new blocks. The "strange interpretation of object IDs" I mentioned before is actually a reflection of the game behavior. However, as it doesn't seem to fully handle the offsets and such, it appears that which level is which room is hard coded, which makes finding the levels in your ROMs pretty tricky. Furthermore, the interface is pretty clunky.)

In light of this, it'd proably be best to not release the versions with the new blocks publicly or to release them in such a way that they're clearly labled as not suitable for stand alone play.

Those sprites look like they'll be a pretty good base on which to build the sprites we need. I keep slackin' on getting the screen shots I promised, for which I apologize. I'll get them up today.

On the special power up front, I've managed to impliment the Clock power up. Of course, that's not saying much as the clock is by far the easiest one to do. Of the other two power ups who's function is known, the Wings should be moderately easy, and the Hammer is likely to be pretty difficult.

I still haven't implimented a method to select which special power up is granted by the special power up block yet. However, the investigation I've done so far indicates that hardcoding them based on the level number isn't going to work as level 4-1 has both the Wings and the Unknown power-up. In light of this, I'm going to do something with a special row object. This also has the advantage of allowing control over the special power ups to be entirely contained in the level data, which makes editing them (whether for this project or a derivative one) easier.

In regards to pipe exits that aren't at the usual height, I think we may be able to provide a solution for that as well. As the  X coordinate of a pipe pointer is largely irrelevant, it could be used instead to store the height at which you come out of the pipe. As I understand it (and Dahrk Daiz's doc states), the X position isn't used because pipe pointers are active on a per page basis, so where on the page they appear doesn't matter. Is this correct?

Anyway, I'm off to produce some screen shots.

Edit 1: Screen Shots as Promised

First up, all the new power ups:

Secondly, the hammer in action:

(Man, I didn't realize how lame that looks. Hmm.)

Edit 2:

I've managed to impliment a selector object for the type of power up granted by the hidden special power up block. Using special object 0x4C on row 13 (0x0D) will now select which power up is granted by special power up blocks on that or any following page. The horizontal coordinate is used to select the power up type:

0x0D    Super Mushroom
0x1D    Fire Flower
0x2D    Starman
0x3D    One Up Mushroom
0x4D    Honeybee
0x5D    Hammer
0x6D    Unknown
0x7D    Clock
0x8D    Wings

The existing power ups are included because it's actually simpler to code that way. However, actually using them is a waste because they have thier own dedicated blocks, which takes up less space than a special block and a power up type selector. Due to the way the game is coded, selecting either the Super Mushroom or Fire Flower will still give results that depend on whether you're big or small. Also due the the way the game is coded, any unassigned number will get you an object with junk graphics that acts like a Starman.

Of the new power ups, only the Clock (as mentioned above) works at this time.
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


cool nice job with the selector blocks.  i will get the sprites created.  looks like the hammer mario is just regular mario with a hammer so no extra sprites needed cept the hammer which is good

and you can implement swimming with a single game genie code so it can't be too hard :) PIGOAP


The unknown power up looks like an atom, with nucleus and orbiting electrons.  It's an a-bomb!

Who knew the Mushroom Kingdom was in the nuclear club, just like N Korea!  :laugh:

No wonder no one's found their WMDs and NOJ was able to deny their existance.  They were hidden for 20 years in an obscure game!  ;)

So basically, the bee and the atom thingy still have unknown function.  In Milon's Secret Castle and Hudson's adventure Island, it allowed you to continue.  In Milon you had to hold left and start at the title screen, once the bee was found.  In HAI, you had to hold left and start.  I don't recall if the bee was in other games.  Would the PC 88 code give any clues to their use?

EDIT:  the bee had the same functionand was used the same way in all three HAI games.  Perhaps I had Milon wrong.  On looking online, the bee gives Milon a shield of some sort, but I coulda sworn it allowed the continue option.  It turns out you can do the left and start thing after getting the first crystal.



Yeah, I don't think implimenting the wings will be too difficult. Basically, it'll just require adding one more timer to the game and a few conditionals. However, what makes that qualify as moderately difficult is the shear ease of implimenting the clock. The content of it's collision handler is literally one "inc" instruction. Anything is hard compared to that, ha ha.

As for the Hammer, that really will be hard. It's going to require a timer, new animation, and collision detection. I'll proably have to dig throught the bowels of the fireball code to figure out how to handle the animation and collisions.

The power ups with unknown functions are a bit irksome. Does anyone here have z80 skills they'd be willing to contribute? I have a pretty good idea where the code is located on the disk image. (Actually, I know where it's not, which is almost as good.) I do agree that the unknown one kinda looks like an atom. The comparison is even more apt when you know (which I forgot to mention) that it's pallet cycling animated.

frantik, once you get the sprites hacked in, please let me know what their tile numbers are so that I can replace the current placeholder graphics (inverted black koopa shells) with them. I'll also need to know which pallet (attributes) they should use. BTW, my build system rips the CHR-ROM from the latest world 1-4 patch.

I was wondering. Should I release the current code with the new blocks now or wait until we have a level data set that'll actually use them before I do so? Further, given that you're currently working on both editing the levels for new blocks and the graphics additions, are you planning releasing one or the other as soon as it's done, or are you going to wait until both are finished. Likewise, if you do release seperate updates, should I? Or should I wait until we have both for the next expanded ROM and source release?
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


ok well I was looking at the CHR-ROM and there's no way to add ANY sprite tiles (or any tiles for that matter)  I was thinking I was going to be able to do it the same way I did in SMU which is to get rid of the duplicate mario tiles.  but that only works if we're using the SMB3 mario tiles, no SMB1 tiles. :(  I'm not sure at all how to get the extra sprites in.. you have any ideas?  if it were on the background object layer i'd say move the title screen info but it's not..


here's Worlds 1-4 with the new block data

World 1-4 not suitable for play as a stand alone rom


You could modify the level data format (or create a new section of level data so as not to break compatibility with the editor you're using) to have it swap CHR pages as the player scrolls.

Example, if there are never any goombas and hammer bros on the same screen at the same time, you could put them at the same spot in the pattern tables, but have them on different CHR pages.  Then in your map data, have an indicator that the game should swap CHR when the user gets to certain points.  I believe SMB3 does something like this, but that's a total guess.

Getting it to swap wouldn't be that hard.  Your level format could be something like:


Where 'XX XX' would be a scroll position, and 'PP' would be a page number assigned to that position.  Once the in-game scroll exceeds XX XX, you simply swap in the next page on the list.


Hmm, not having any room for sprites in the CHR-ROM is going to be a bit of a problem. I'll have to see what I can come up with for a solution. Something along the lines of what Disch has suggested is proably the best option were're going to get. I suppose I'll have to analyze the level's sprite contents and see what sort of division we could make.

Quick work on revamping worlds one through four, nice. Does this include the special powerup type selectors as well?

Perhasp we can put some sprites on the object layer instead. None of the new power ups are mobile and neither is the Fire Flower. We might be able to move them and some other non-mobile sprites (like Peach and Toad) to the object page, which would free up space on the sprite page. I'm not sure how involved such a hack would be, but I'll look into it.

I'm curious, how does using SMB3's Mario graphics free up space? Could the SMB graphics be slightly altered to do the same thing? (I.e. could the less space using SMB3 layout be done using SMB derived sprites?) And, if so, how many sprite tiles would it free up and how would it look?
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


QuoteDoes this include the special powerup type selectors as well?

yep :)

the way the SMB3 sprites freed up space is due the the fact there are fewer unique tiles.. in smb1 almost every frame has completely unique tiles.

actually I was thinking about what Disch said and perhaps the bowser graphics can be switched out because they are only used in the end castles.  also there is already code for a palette switch when the axe is loaded to make sure Bowser has the right palette.  this could ammended with a CHR-ROM page switch as well. :)  there are at least 16 bowser tiles so that could give us 4 whole sprites.  still not enough though for everything.  perhaps those object selector switches will also have to switch chr-rom pages?


I may have found a solution to the sprite space shortage that is complatible with the current level format and won't require manual adjustment of CHR-ROM swap points to properly impliment.

I started simply looking at the levels to see what sort of partitioning of sprites we could do, when I had a realization, Bower is only in the castles. (While I was typing this, frantik mentioned the same idea.) Then I also added Toad and Peach to the "castle only" list. Inspired, I went through the renders of all eight castles and found that not very many enemy types show up in the castles. Which meant, that we could use a second CHR-ROM bank to store Bowser, Peach, etc. in the space normally used by the enemies that don't appear in castles.

As I seemed to be on to something, I went through the rest of the levels and compiled the following table:

            Ground   Under   Water   Castle    2   3

Goomba          x      x      .      x         x   x
Koopa           x      x      .      x         x   x
Parakoopa       x      .      .      x         x   .
Piranha Plant   x      x      .      x         x   x
Buzzy Beetle    x      x      .      x         x   x
Firebar         x      x      x      x         x   x
Cheep Cheep     x      .      x      .         x   .
Blooper         x      .      x      .         x   .
Bullet Bill     x      .      .      .         .   .
Latiku          x      .      .      .         .   .
Spiny Egg       x      .      .      .         .   .
Spiny           x      .      .      .         .   .
Hammer Bro      x      .      .      .         .   .

Bowser          .      .      .      x         .   .
Bowser Flame    .      .      .      x         .   .
Toad            .      .      .      x         .   .
Peach           .      .      .      x         .   .
Podobo          .      .      .      x         .   .

Side Stepper    x      x      .      .         x   .
Fighter Fly     x      .      .      .         .   .
Falling Spike   .      x      .      x         x   .
Barrel          x      .      .      x         x   .
Flaming Barrel  x      .      .      x         x   .

Based on this, I belive we can free up a signifigant portion of the sprites we need, even if we can't manage to fit all of them and have to adopt another solution for some of them. My next step is going to be to go through the CHR-ROM's sprite data and see exactly how much space would be availble if we implimented switching based on these results.
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


so what are the 2 and 3 collumns for?

here's the sprites.. they're just in their own blank rom.  you'll want to copy them over with TLP or similar.  first is the sprites laid out so you can see how they should look.  second is the sprites laid out so all the of the repeat (mirrored) tiles are removed.

for animation, the side steppers need to be flipped like goombas.  fighter flies have two sprite frames.  barrels need to be flipped multiple ways to give the appearance of rolling.  not sure how to animate the fire and the spikes dont need animation

palette data:

red = red/white/yellow (green koopa palette)
green = green/white/yellow (red koppa palette)
black = black/tan/brown (buzzy beetle palette)

side stepper, barell, flaming barrel, spike, bee, atom, clock = red
fighter fly = green
hammer, wings = black

karatorian can you post the game with the new block stuff from worlds 1-4 so i can verify i'm doing it right before i go ahead with 5-8?


some addition sprite tile info:

bubble tile only used in water level
mario climbing  (big and small), flag graphics (flag pole and star flag) and vine graphics not used in water or castle levels
springboard - only used in overworld?

you also didn't mention the power up sprites in your table


Yeah, there's a number of different sprites I left out, power ups, elevators, ropes, flags, etc. Thanks for the hints as to additional stuff that could be rearranged.

Columns "2" and "3" are just listings of which sprites showed up in two and three types of levels. Basically the point was to (mostly as a note to myself) to give some suggestions on which sprites are the most used.

In regards to a build using the new blocks, I'll get one up tomorrow. I would've done it tonight, but I just worked a twelve hour shift and then had to replace the motherboard in my computer, so I'm going to bed.

I'll do some experimenting and see what suggestions I can come up with for the flaming barrel animation.

Good night and happy hacking.
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


hey i was thinking maybe we should put the SMBS ending "You have cleared all the worlds" or whatever it is (it's even more anticlimactic than the original ending haha) and then add a custom ending with credits for us.. or i could just shorten the credits message at the end

also bowser acts differently in SMBS he doesnt jump high enough to run under as much iirc


I've released the latest expanded ROM patch here. New in this release are the recently added additional blocks (implimented in worlds 1 through 4), a working clock power up, and placeholders for all the new power ups.

Due to a bunch of real life stuff I needed to deal with, I've yet to add any of the new graphics yet. However, to assist with testing, each of the added power-ups has an idividual placeholder graphic for now. They are as follows:

0x04   Honeybee              Black Spiny
0x05   Hammer                Hammer Bro. Hammer
0x06   Unknown Power Up      Black Spiny Egg
0x07   Clock                 Black Podobo
0x08   Wings                 Black Koopa Shell

Using the Hammer Bro.'s hammer got me thinking. Should we simply use it for the hammer? It would save some space. However, it's only two tiles, so it might be kinda off.

Frantik, I did a little testing and the additional blocks in level 1-1 worked correctly, so it seems you've got them figured out. In regards to the end message, I'd be in favor of the SMBS original. Implimenting a custom end screen of our own would be really cool as well. If you could point me to a SMB TBL file and a screenshot of the SMBS ending, I can hack it in myself.
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