This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Sprites Expansion? - Smurfs ROM related

Sprites Expansion? - Smurfs ROM related
by on (#34074)
I also found out that ''smurfs.nes'' expanded (or put more) sprites @ 0700. How did it do that? Can I have more info for expanding so I can make a new status bar?

by on (#34078)
What are you talking about? The NES hardware is limited to 64 on-screen sprites. You can't just "add more" via software.

by on (#34080)
BMF54123 wrote:
What are you talking about? The NES hardware is limited to 64 on-screen sprites. You can't just "add more" via software.


No, I Looked, Infogrames must have found a way around. I looked at RAM. $700 (Main/Status Bar Sprites?) and $200 (Player) have sprite data.

by on (#34081)
No, I am saying IT IS NOT POSSIBLE. The PPU can only display 64 sprites, no more.

I just checked the game, and the OAM data is at $700. 256 bytes = 64 sprites. I don't know what $200 is, but it's not OAM.

by on (#34082)
BMF54123 wrote:
No, I am saying IT IS NOT POSSIBLE. The PPU can only display 64 sprites, no more.

I just checked the game, and the OAM data is at $700. 256 bytes = 64 sprites. I don't know what $200 is, but it's not OAM.


Ok, I understand.

(This topic is done, Please close it if possible)

by on (#34094)
Yes it is possible to have more than 64 sprites IF AND ONLY IF you turn the PPU off for about 8 scanlines in the middle of the frame in order to re-perform sprite DMA. Then you can use the first sprite area for the part above the bar with 64 sprites and the second sprite area for the bottom part with 64 other sprites. I haven't tried this myself, I don't know if any games use this and I don't see much use for that since you don't usually want a big black bar in the middle of your screen, but this is possible.

by on (#34099)
Stunt Kids by Codemasters does this.

by on (#34102)
It's closer to 5 scanlines, and I think at least Bigfoot uses it.

by on (#34103)
You mean bigfoot's adding sprites in a black area on the status bar? Wizards and Warriors 3 also does that, but that's different from using split screens with two sprite tables.

by on (#34106)
Bregalad wrote:
Yes it is possible to have more than 64 sprites IF AND ONLY IF you turn the PPU off for about 8 scanlines in the middle of the frame in order to re-perform sprite DMA. Then you can use the first sprite area for the part above the bar with 64 sprites and the second sprite area for the bottom part with 64 other sprites. I haven't tried this myself, I don't know if any games use this and I don't see much use for that since you don't usually want a big black bar in the middle of your screen, but this is possible.

This would be great for a 2P game that works like Sonic 2's competition mode, where each player uses half of the screen.

In Sonic 2, both players race in the same level and whoever reaches the end first wins. On the NES, you could explore the idea even further, because with CHR-ROM nothing would stop you from switching new patterns and a new palette for the bottom part of the screen, meaning that the players could even be in different levels, as long as the engine supports this (2 levels loaded at once). Speed would also be an issue, because the NES would be in fact processing 2 separate games at the same time. It could work smoothly in a simpler game.

I think this is just too cool... letting 2 people play the game at the same time, at their own pace, occasionally meeting when necessary, would be fantastic! With 2 different playfields, 8 blanked scanlines in the middle of the screen would not be a problem at all.

EDIT: Back on the topic of "sprite expansion", this seems to be the only way to use more than 64 sprites. This multiplexing only works vertically though, so it probably is impossible to have more than 8 sprites per scanline.

by on (#34108)
Yes, but it would work only if both playfields scrolls horizontally, or if you have a mapper that supports one-screen mirroring.
Quote:
This multiplexing only works vertically though, so it probably is impossible to have more than 8 sprites per scanline.

Why probably ? You are still unsure ?

by on (#34112)
Bregalad wrote:
Yes, but it would work only if both playfields scrolls horizontally, or if you have a mapper that supports one-screen mirroring.

Or you could do that weird trick of drawing each playfield twice while using horizontal mirroring, although that'd make things even harder because there are 2 of them, so you'd actually maintain 4 playfields. But sure, one-screen mirroring would be the best option.

Quote:
Quote:
This multiplexing only works vertically though, so it probably is impossible to have more than 8 sprites per scanline.

Why probably ? You are still unsure ?

People have been proved wrong about hardware limitations before, so I'll not risk saying "it's impossible", that's all. Once in a while someone discovers pretty weird ways of extending the capabilities of old hardware, so who knows?

by on (#34117)
tokumaru wrote:
People have been proved wrong about hardware limitations before, so I'll not risk saying "it's impossible", that's all. Once in a while someone discovers pretty weird ways of extending the capabilities of old hardware

How about "it was impossible while the NES was still putting food on the table"?

by on (#34126)
- An "interesting" test ROM would be one small ball bouncing across the screen, and +1 when some key is pressed. It's *almost* the same idea behind that bio (?) demo.

by on (#34131)
Fx3 wrote:
- An "interesting" test ROM would be one small ball bouncing across the screen, and +1 when some key is pressed.

That, or my old "Obey Your Thirst" (64 sprite cans) demo.

by on (#34143)
tepples wrote:
Fx3 wrote:
- An "interesting" test ROM would be one small ball bouncing across the screen, and +1 when some key is pressed.

That, or my old "Obey Your Thirst" (64 sprite cans) demo.


Yeah, I know that demo, but I meant more than 64 sprites being displayed. Of course, the cache won't be bigger than 64, but the effect would be. It's the same idea of displaying 256 colors in a screen...

by on (#34144)
What about really cheap stuff, like "sprites" which are actually background tiles, and move jerkily?

by on (#34148)
I remember this game: Mappy Kids, for the famicom. Is a game in which you have a split screen for two players, like in Sonic 2.

by on (#34159)
The thing is: I am using the SMB1 source, and I wanted to make (and still doing) a new Status bar engine using sprites, Removing the original Status Bar and it's engine. I am rewriting part of it at the least.

But I do not know how to wait about a certain number of scanlines, So I need some help.

In other words: What registers do I need to set and disable to get an 8 scanline setup?

Also: How do I stop the Flickering after removing the code that is used for enabling ''Sprite Zero''?

by on (#34160)
Hamtaro126 wrote:
In other words: What registers do I need to set and disable to get an 8 scanline setup?


You need to turn the PPU off. This is disabling both BG and Sprite rendering via $2001 (usually accomplished by just writing $00 to $2001).

Once the PPU is off, you can perform the sprite DMA (writing to $4014). Once that is complete you can turn the PPU back on by restoring $2001 to its original value.

It's worth noting that turning on the PPU mid frame like this will bork the scroll. So before you turn it on you'll probably want to write to the scroll regs: $2005 twice, and possibly $2000. But since this will probably muck up the fine V scroll you'll have to get really crafty with alternating $2005/$2006 writes which I don't feel like explaining because in all honestly I think an explanation would be somewhat wasted on you.

Quote:
Also: How do I stop the Flickering after removing the code that is used for enabling ''Sprite Zero''?


Depends what's causing it. Did you just remove the wait loop? I don't see how that'd cause flickering.. it'd just cause the screen to be split early (tearing the status bar so that some of it scrolls and some of it doesn't -- but I guess since the exactly scanline on which the tear happens changes it could look like flicker....)

To fix that -- simply wait until the desired scanline before the split (this waiting is exactly what Sprite-0 hit was for). An alternative way to wait is to have an IRQ fire on the desired scanline.

But if you're replacing the status bar with sprites, then you don't need to split the BG at all and can just set the normal scroll values right away instead of waiting for the split.

but I don't see how an all sprite status bar would work... since you only have 8 sprites per scanline -- you'd either have mad flicker, or a really small status bar, or most of the status bar just not being visible)

by on (#34161)
You could have information vertically displayed, and use 8x16 sprites for that. That's what I do in my game for the large vertical health bar. I suppose it would be a little difficult for SMB, and the information should be displayed horizontally. You COULD reduce the size of each word above each number to take up only a few tiles rather than one for each letter.

You could also stack the information instead of having it laid out horizontally all the way across, and you could shrink the size of the letters and numbers so overall it wouldn't be a really tall status bar.

by on (#34170)
Disch wrote:
but I don't see how an all sprite status bar would work... since you only have 8 sprites per scanline -- you'd either have mad flicker, or a really small status bar, or most of the status bar just not being visible)

Mega Man. Super Mario Bros. 2. Ikari Warriors. Contra.

But you could still shrink the status bar to one row of tiles as was done in SMB1 for Game Boy Color. Compare the top screenshot of stock SMB1 to the bottom screenshot that has been shopped to have an 8-pixel status bar:
Image

In SMB1, the only things you really need to see during gameplay are the coins and time. Those can be shown with 7 sprites, in much the same way Ikari Warriors does it:
Image
But this means you'll have to go away from NROM so that you can have room in the sprite side of the pattern table for the digits and clock icon. And they might make Lakitu flicker.

by on (#34178)
Heh... okay I get it now. For some reason I didn't think of that style as a "status bar". I thought he was going to try and recreate the status bar in full with sprites for whatever reason.

But yeah -- if minimalized like that it could totally work.

by on (#34183)
Quote:
But this means you'll have to go away from NROM so that you can have room in the sprite side of the pattern table for the digits and clock icon. And they might make Lakitu flicker.

What about changing $2000.3 midframe so that the "sprite side of the pattern table" changes ?

Also, "MARIO" and "LUIGI" are both 5 letters, and the scrore is 7 digits : All of them can be put on the status bar. You could even place "MARIO" on the same line as the coin counter if you get rid of the "x" symbol.

by on (#34185)
Bregalad wrote:
Quote:
But this means you'll have to go away from NROM so that you can have room in the sprite side of the pattern table for the digits and clock icon.

What about changing $2000.3 midframe so that the "sprite side of the pattern table" changes ?

SMB1 pulls sprite tiles from $0000-$0FFF and background tiles from $1000-$1FFF. If you switch sprites to $1000-$1FFF until the raster passes the lines containing the status bar, then every player or enemy sprite on the same scanline as the status window becomes corrupt. (Good-bye Lakitu.) And you'd still need to use sprite 0 to find when to perform this change, so it still wouldn't be much of an improvement over the existing status bar.

Quote:
Also, "MARIO" and "LUIGI" are both 5 letters, and the scrore is 7 digits : All of them can be put on the status bar. You could even place "MARIO" on the same line as the coin counter if you get rid of the "x" symbol.

But then you're back to the first post of the topic: you start running out of the 64 sprites. In addition, too many indicators clutter up the play area. There's a reason that Donkey Kong Country games keep indicators out of the way when they aren't changing.

by on (#34190)
tepples wrote:
Bregalad wrote:
Quote:
But this means you'll have to go away from NROM so that you can have room in the sprite side of the pattern table for the digits and clock icon.

What about changing $2000.3 midframe so that the "sprite side of the pattern table" changes ?

SMB1 pulls sprite tiles from $0000-$0FFF and background tiles from $1000-$1FFF. If you switch sprites to $1000-$1FFF until the raster passes the lines containing the status bar, then every player or enemy sprite on the same scanline as the status window becomes corrupt. (Good-bye Lakitu.) And you'd still need to use sprite 0 to find when to perform this change, so it still wouldn't be much of an improvement over the existing status bar.

Quote:
Also, "MARIO" and "LUIGI" are both 5 letters, and the scrore is 7 digits : All of them can be put on the status bar. You could even place "MARIO" on the same line as the coin counter if you get rid of the "x" symbol.

But then you're back to the first post of the topic: you start running out of the 64 sprites. In addition, too many indicators clutter up the play area. There's a reason that Donkey Kong Country games keep indicators out of the way when they aren't changing.


I can use 8x16. I am currently doing that. Also using it to use less sprites

Here is a (Mental) Schematic for the new Status Bar:

Mario's Status Bar:

MARIO x03 @x00 TIME: 000

Luigi's Status Bar:

LUIGI x03 @x00 TIME: 000

It may change, just so you know