unregistered wrote:What are the limits of the meta-sprite system?
That depends on the game. There is no standard for that, and each game has its own implementation of a meta-sprite system designed according to its specs.
For example, some systems might require that all sprites are arranged in a grid and use the same palette, so that the meta-sprite definitions will use less ROM space (no need to store the coordinates and attributes of each sprite). In my game I have a very versatile system, where each sprite's position is relative to the object's coordinates and has its own attributes. As a result, the definitions are larger.
I remember reading about how Punchout!! required special hardware to draw/animate the humungus enemies.
I'm not aware of that. The mapper used in that game doesn't have any features that would increase the sprite capacity of the system. What you can do sometimes is draw game objects using background tiles, if the background is flat enough. The ring is just a solid color, so it's possible that one of the fighters is actually drawn with background tiles rather than sprites, but I didn't check.
Like what is the largest meta-sprite we could use without improving cart hardware? (Question is from my artist!)
You are the programmer, so you're the one that should have the answer!
Truth is that it's impossible for mappers to increase the amount of displayed sprites (at most they can provide you with a larger amount of tiles to pick from), because all the sprite logic and OAM is internal to the PPU, meaning that external hardware can't mess with it. So no matter the kind of system you code, you'll always be limited by the same hardware rules: 8 sprites per scanline, 64 sprites screen.
So the largest meta-sprite is either 64x64 pixels (in 8x8 mode) or 64x128 pixels (in 8x16 mode). I wouldn't make such a huge sprite though, because there wouldn't be any sprites left for other game objects.
Also... about scrolling; what are possible width and height/depth for scrolling... guess she is wondering how much of a level can we do?
Again, this is up to the programmer. Levels can be as large as you want, it all comes down to the memory necessary to store the level maps. Depending on the type of compression you use, your maps will occupy more or less ROM space. If you implement a system where levels are generated randomly, you could have an endless level.
Each game's engine handles the scrolling differently. Some decompress whole levels to RAM (needs too much RAM, not recommended on the NES unless you have extra memory on the cart), some decompress the levels progressively so that only the visible area is in RAM, and some even read map data directly from the ROM, so they don't have to worry about wasting too much RAM, but the compression schemes used for this don't usually compress as well, so the levels need more ROM space.
Mario 3 has the type of scrolling she is wanting.
You have to select the kind of compression that will work best with the kind of levels you want to make, also taking into consideration the decoding process (i.e. how you are going to read the map data, for drawing and for collision with the objects).
SMB3 has some limitations, like the height of the level, which is 2 NES screens tall (minus the status bar), and color glitches at the right of the screen because of the way it uses the name tables (horizontal mirroring). Status bars also affect the way you implement the scrolling if you plan on scrolling vertically (which I assume you do), so I need to know whether you want a status bar in your game and whether your levels can be taller than 2 screens before I suggest the optimal solution for your case.