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.

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.

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.

Hey, thanks.

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 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.

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.

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.