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.
8x16 sprites wiki question
Moderator: Moderators
Re: 8x16 sprites wiki question
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: 8x16 sprites wiki question
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: 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.
This is the result: 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.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: 8x16 sprites wiki question
Contra uses 8x16 sprites, so the "lots of small bullets" problem may not be as bad is in practice as it would first seem.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: 8x16 sprites wiki question
When I wrote an article about NES sprites, my best example for efficient/effective use of 8x8 sprites was Blaster Master's Sophia III:
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.
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.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: 8x16 sprites wiki question
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.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: 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.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: 8x16 sprites wiki question
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.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: 8x16 sprites wiki question
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.
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.