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...tepples wrote:That, or my old "Obey Your Thirst" (64 sprite cans) demo.Fx3 wrote:- An "interesting" test ROM would be one small ball bouncing across the screen, and +1 when some key is pressed.
Sprites Expansion? - Smurfs ROM related
Moderator: Moderators
Zepper
RockNES author
RockNES author
- egfelixdcg
- Posts: 26
- Joined: Sat Jun 07, 2008 1:50 pm
- Location: Argentina
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm
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''?
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''?
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).Hamtaro126 wrote: In other words: What registers do I need to set and disable to get an 8 scanline setup?
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.
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....)Also: How do I stop the Flickering after removing the code that is used for enabling ''Sprite Zero''?
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)
-
- Posts: 2158
- Joined: Sun Jun 05, 2005 2:04 pm
- Location: Minneapolis, Minnesota, United States
- Contact:
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.
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.
Mega Man. Super Mario Bros. 2. Ikari Warriors. Contra.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)
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:
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:
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 ?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.
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.
Useless, lumbering half-wits don't scare us.
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.Bregalad wrote:What about changing $2000.3 midframe so that the "sprite side of the pattern table" changes ?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.
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.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.
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm
I can use 8x16. I am currently doing that. Also using it to use less spritestepples wrote: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.Bregalad wrote:What about changing $2000.3 midframe so that the "sprite side of the pattern table" changes ?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.
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.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.
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