nesdev.com
https://forums.nesdev.com/

8x16 sprites wiki question
https://forums.nesdev.com/viewtopic.php?f=2&t=16235
Page 2 of 2

Author:  Dwedit [ Fri Jul 21, 2017 9:23 am ]
Post subject:  Re: 8x16 sprites wiki question

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.

Author:  DRW [ Fri Jul 21, 2017 10:10 am ]
Post subject:  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:
Attachment:
UpdateAllSprites.png
UpdateAllSprites.png [ 3.89 KiB | Viewed 443 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.

Author:  thefox [ Fri Jul 21, 2017 10:13 am ]
Post subject:  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.

Author:  rainwarrior [ Fri Jul 21, 2017 12:39 pm ]
Post subject:  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:
Attachment:
ex1_blaster.gif
ex1_blaster.gif [ 12.34 KiB | Viewed 412 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.

Author:  GradualGames [ Fri Jul 21, 2017 1:40 pm ]
Post subject:  Re: 8x16 sprites wiki question

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.

Author:  GradualGames [ Fri Jul 21, 2017 1:53 pm ]
Post subject:  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.

Author:  GradualGames [ Sat Aug 26, 2017 1:30 pm ]
Post subject:  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.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/