It is currently Sat Nov 25, 2017 2:45 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Jul 21, 2017 6:46 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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)?


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 6:49 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 256
guns imply bullets - and using 8x16 on a bullet is a bit wasteful and will probably increase your flickering, is my guess.


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 6:50 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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)


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 6:53 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1474
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".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 6:55 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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.


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 6:57 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1024
Location: Gothenburg, Sweden
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


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 7:01 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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.


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 7:04 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1474
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".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 7:17 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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.


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 7:26 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1474
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".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 7:30 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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.


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 8:01 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5843
Location: Canada
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?


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 8:09 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1024
Location: Gothenburg, Sweden
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


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 9:09 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19259
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Jul 21, 2017 9:16 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group