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

8x16 sprites wiki question

8x16 sprites wiki question
by on (#200573)
The wiki says: "The NES supports 64 8x8 sprites or 64 8x16 sprites. This means 8x16 sprites can cover a larger area of the screen. So games without many objects that are smaller than 12 pixels or 17-24 pixels in height can benefit from 8x16 sprites. These include fighting games, vertical shooters, or platformers without guns."

I'm thinking of using 8x16 sprites in my platformer WITH guns to reduce cpu time in rendering metasprites---which in my experience is always the most cpu hungry part of an NES game engine. Why would having guns make it less beneficial to use 8x16 sprites (according to the wiki)?
Re: 8x16 sprites wiki question
by on (#200574)
guns imply bullets - and using 8x16 on a bullet is a bit wasteful and will probably increase your flickering, is my guess.
Re: 8x16 sprites wiki question
by on (#200575)
Oziphantom wrote:
guns imply bullets - and using 8x16 on a bullet is a bit wasteful and will probably increase your flickering, is my guess.

Ah that makes sense. Luckily my bullets are 16x16 pixels in size ;) (and there's not more than 3 of them at any given time)
Re: 8x16 sprites wiki question
by on (#200576)
Why is rendering the sprites the most CPU-hungry part? I mean, sure, you always benefit from having to do less. But I didn't experience the rendering as very much.
Re: 8x16 sprites wiki question
by on (#200577)
I've simply found when I use the monochrome bit trick to profile different aspects of a frame update in my game, the metasprite rendering routine typically is taking the most time of anything. Or rather it has the most potential for volatile growth at any given time depending on how many enemies/bullets etc. are on the screen, the most potential for causing dropped frames. Map rendering while also expensive is more consistent with how much time it takes. Entity updates are also fairly cheap since they rarely if ever have a loop of any kind on any given frame.
Re: 8x16 sprites wiki question
by on (#200578)
Yeah... Isn't it moving around and animating the sprites that are the hungry part, rather than just having them on screen?
Re: 8x16 sprites wiki question
by on (#200579)
That's what I mean. Every frame I'm copying metasprite data to my sprite page at $0200, in a pseudo random order (for flickering) It's the inner loops of the metasprite rendering routine that have the greatest potential for causing dropped frames, depending on how many enemies are onscreen. So I'm hoping to halve the amount of time this takes by using 8x16 sprites...just trying to consider what trade offs I may be introducing as a result.
Re: 8x16 sprites wiki question
by on (#200580)
Hm. Strange. When I'm home, I can check again how long my sprite rendering routine takes. But I would say that it shouldn't take too long. The actual logic is probably more.

What data does the function have to read for each sprite?
Re: 8x16 sprites wiki question
by on (#200581)
To clarify, I mean the metasprite routine called multiple times. I'm talking about the high level section of my game engine that renders all active entities. Add those all together with all sprite entries and you've got an inner loop that is much larger than anything else going on in the engine. I would imagine this situation would turn up in a lot of action oriented game engines. The metasprite routine itself is very compact, probably the best one I've written over the last 8 years, I think it would be hard or impossible to make it much faster than it is. At the end of the day I have to add an offset to an X and Y coordinate and store them, can't skip that...haha. *edit* So yeah, if it turns out the bulk of the time is in copying sprite entries, I'm hoping 8x16 might be the ticket. I still have to evaluate if it's really worth it from a gameplay perspective however. It's a tradeoff. And the flickering is definitely a concern. Big sprites are tough to pull off without fugliness on NES, if you have more than a few on the screen.
Re: 8x16 sprites wiki question
by on (#200582)
I'm not quite sure if I understand what you mean:

MoveEnemy:
Checks collision, sets x and y position according to A.I. etc. and sets a pointer to an array that has the meta sprite definition for the current animation phase.
Should be independent from the actual size of an on-screen character or at least from the question of how many sprites are used to build this character.

UpdateSprites:
Takes the x and y position and the meta sprites definition pointer and draws each hardware sprite to the screen.
That one would benefit from 8 x 16 sprites since it would have to read less data.

But I think UpdateSprites would be the less problematic function. While MoveEnemy, the bigger function, shouldn't be influenced by 8 x 8 vs. 8 x 16 sprites.
Re: 8x16 sprites wiki question
by on (#200583)
Yeah, entity logic and drawing are separate in my engine as well. But the entity logic is very cheap (relatively speaking) as there's no inner loop in any given entity's update routine. However for each entity that is drawn, you have an inner loop. With large enough sprites there's potential for that making it take longer than the actual entity update logic. Language choice probably also affects this. I write everything in 6502 so it is fairly easy to compare apples to apples. If I wrote my entity update logic in C, I wouldn't be surprised if it suddenly did take longer than metasprite rendering.
Re: 8x16 sprites wiki question
by on (#200585)
I've never noticed this page on the wiki before:
http://wiki.nesdev.com/w/index.php/Sprite_size

"If your game's characters are 21-24 pixels tall, 8x8 pixel sprites may be the best choice. For example, this is true of Mario Bros. (1983), Balloon Fight, the enemies in the original Super Mario Bros., and the hero in the Mega Man series. And in Thwaite, everything is either 8x8 (missiles, smoke, crosshair) or 24x24 (explosions) by nature, so 8x8 is a natural fit."

"So games without many objects that are smaller than 12 pixels or 17-24 pixels in height can benefit from 8x16 sprites. These include fighting games, vertical shooters, or platformers without guns."

I find these statements really confusing. I think they're making a leap in logic that I can't follow, and I don't really agree that either a specific character size or game genre dictates a "natural fit"... In particular I'm kinda baffled by these partial-tile ranges like "21-24 pixels"? Where on earth does that come from?
Re: 8x16 sprites wiki question
by on (#200586)
M-tee's blog writeup is much more to the point IMO and has helped me form an idea of what is good where.
http://www.mteegfx.com/post/12167953203 ... erview/amp
Re: 8x16 sprites wiki question
by on (#200588)
GradualGames wrote:
Luckily my bullets are 16x16 pixels in size ;)

If you have 16-pixel-tall projectiles, then by all means use 8x16. I wrote that to explain why Contra flickers: its bullets don't come close to filling the height of the 8x16 sprite box.
Re: 8x16 sprites wiki question
by on (#200590)
tepples wrote:
GradualGames wrote:
Luckily my bullets are 16x16 pixels in size ;)

If you have 16-pixel-tall projectiles, then by all means use 8x16. I wrote that to explain why Contra flickers: its bullets don't come close to filling the height of the 8x16 sprite box.


Thankfully I'm not going for a huge amount of bullets...so hoping 8x16 will be a nice speed boost. Not to mention versatile say for animating parts of a boss without having to load boss chr data in both patterntables. (or other objects of course but that's the use case I have in mind, potentially) I guess the trade off is with MMC3 I'll likely have to do a bit more bankswapping (which is cheap anyway) do to using the pattern tables less efficiently than with 8x8 sprites.
Re: 8x16 sprites wiki question
by on (#200591)
Using 8x16 sprites to represent a very small object basically wastes a tile in video memory, and wastes vertical screen space for the 8 sprites limit.
If you don't mind the waste, go wild on 8x16 sprites.
Re: 8x16 sprites wiki question
by on (#200595)
Alright, I checked my UpdateAllSprites function, i.e. the function that is used to turn the meta sprites into their actual hardware sprites. I enabled one of the intensity bits from $2001 mid-frame when the function starts and set it back when it stops.

This is the result:
Attachment:
UpdateAllSprites.png
UpdateAllSprites.png [ 3.89 KiB | Viewed 1570 times ]

Rendering everything in this scene takes 48 scanlines. Those are four characters and a sum of 38 hardware sprites.

Does your rendering function take longer? If yes, maybe I should post the source code to my function.
Re: 8x16 sprites wiki question
by on (#200596)
Contra uses 8x16 sprites, so the "lots of small bullets" problem may not be as bad is in practice as it would first seem.
Re: 8x16 sprites wiki question
by on (#200605)
When I wrote an article about NES sprites, my best example for efficient/effective use of 8x8 sprites was Blaster Master's Sophia III:
Attachment:
ex1_blaster.gif
ex1_blaster.gif [ 12.34 KiB | Viewed 1539 times ]


Of course, Blaster Master uses 8x16 for the interior game segments where the characters are bigger.

The only critical issue in my view is that 8x16 becomes necessary once you want a certain amount of screen coverage. Everything else besides that seems a minor/manageable issue, and pretty debatable which is better.

8x8 for the micro managers, detailed control, efficient use of tile space, etc. (with no CHR-banking it seems helpful in that respect).

8x16 for coarse and easy control.
Re: 8x16 sprites wiki question
by on (#200611)
DRW wrote:
Alright, I checked my UpdateAllSprites function, i.e. the function that is used to turn the meta sprites into their actual hardware sprites. I enabled one of the intensity bits from $2001 mid-frame when the function starts and set it back when it stops.

This is the result:
Attachment:
UpdateAllSprites.png

Rendering everything in this scene takes 48 scanlines. Those are four characters and a sum of 38 hardware sprites.

Does your rendering function take longer? If yes, maybe I should post the source code to my function.


Mine takes a little bit longer (I checked for a case of 39 sprites total), but roughly comparable relatively speaking. 48 scanlines is still a lot larger than the other portions of my engine, so it seems that this is where I need to focus optimization effort if I'm going to try to save some time in my engine.
Re: 8x16 sprites wiki question
by on (#200612)
Actually, I just took another look with the monochrome bit. It seems I was wrong. The collision detection (which is a separate step from the update logic) is the most expensive step overall. Maybe that's where I need to focus attention instead.
Re: 8x16 sprites wiki question
by on (#203313)
I just completed refactoring my game to use 8x16 sprites. I got a rather substantial speed boost from doing this, and the flickering and such that had been present previously (not much) really looks just the same.

It occurred to me the approach I've taken to art, in collaborating with my artist pays very very little attention to optimal use of chr space. So we don't bother to try to mirror things in multiple ways horizontally or vertically etc. Almost everything is unique. As a result, deduplicating our graphics as 8x16 took up approximately the same number of tiles (maybe 1 to 3 extra in some cases) in the pattern table.

So echoing one post above, yeah, unless you're planning to make an NROM game or otherwise have a strong desire to optimize the hell out of how many patterns you use per object, 8x16 is probably the best option for an action game.