8x16 sprites wiki question

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 6:46 am

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)?

Oziphantom
Posts: 774
Joined: Tue Feb 07, 2017 2:03 am

Re: 8x16 sprites wiki question

Post by Oziphantom » Fri Jul 21, 2017 6:49 am

guns imply bullets - and using 8x16 on a bullet is a bit wasteful and will probably increase your flickering, is my guess.

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: 8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 6:50 am

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)

User avatar
DRW
Posts: 1914
Joined: Sat Sep 07, 2013 2:59 pm

Re: 8x16 sprites wiki question

Post by DRW » Fri Jul 21, 2017 6:53 am

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.
Available now: My game "City Trouble".
Sales website: https://megacatstudios.com/products/city-trouble
Gameplay: https://youtu.be/Eee0yurkIW4
Download website: http://www.denny-r-walter.de/city.htm

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: 8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 6:55 am

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.

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2032
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: 8x16 sprites wiki question

Post by FrankenGraphics » Fri Jul 21, 2017 6:57 am

Yeah... Isn't it moving around and animating the sprites that are the hungry part, rather than just having them on screen?
http://www.frankengraphics.com - personal NES blog

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: 8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 7:01 am

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.

User avatar
DRW
Posts: 1914
Joined: Sat Sep 07, 2013 2:59 pm

Re: 8x16 sprites wiki question

Post by DRW » Fri Jul 21, 2017 7:04 am

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?
Available now: My game "City Trouble".
Sales website: https://megacatstudios.com/products/city-trouble
Gameplay: https://youtu.be/Eee0yurkIW4
Download website: http://www.denny-r-walter.de/city.htm

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: 8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 7:17 am

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.

User avatar
DRW
Posts: 1914
Joined: Sat Sep 07, 2013 2:59 pm

Re: 8x16 sprites wiki question

Post by DRW » Fri Jul 21, 2017 7:26 am

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.
Available now: My game "City Trouble".
Sales website: https://megacatstudios.com/products/city-trouble
Gameplay: https://youtu.be/Eee0yurkIW4
Download website: http://www.denny-r-walter.de/city.htm

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: 8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 7:30 am

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.

User avatar
rainwarrior
Posts: 7677
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: 8x16 sprites wiki question

Post by rainwarrior » Fri Jul 21, 2017 8:01 am

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?

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2032
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: 8x16 sprites wiki question

Post by FrankenGraphics » Fri Jul 21, 2017 8:09 am

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
http://www.frankengraphics.com - personal NES blog

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 sprites wiki question

Post by tepples » Fri Jul 21, 2017 9:09 am

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.

User avatar
GradualGames
Posts: 1107
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: 8x16 sprites wiki question

Post by GradualGames » Fri Jul 21, 2017 9:16 am

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.

Post Reply