SDL_Surface dimensions and its efficency

Do you mind explaining the hardware problems that force you to do what
you describe?

Sure. Sprites on the NES have a foreground/background priority bit
that describes whether they appear in front of or behind the playfield
characters. That alone would be trivial to emulate - draw the
background sprites, draw the playfield, draw the foreground sprites -
but there’s a twist to it. Call it a bug, a design flaw, or just the
implementation details showing through. Sprite priority doesn’t apply
between sprites - a “background” sprite can appear in front of a
"foreground" sprite at the same location, if it’s at a lower index in
the sprite table. That is, the sprites are evaluated in order, with no
regard to priority, to produce a color value and priority bit, and
only then is the result of that tested against the background. This
can cause foreground sprites to disappear behind the background. It
sounds like an obscure thing, but quite a few games take advantage of
it for simulating the ability of the playfield objects (such a pipe,
or the ground) to mask a foreground sprite which should
appear/disappear behind it, and where you can’t set the sprite itself
to background priority because that would prevent you from having any
other art in the background where this is going it (you don’t want
mario to disappear behind clouds or a bush as he starts to descend
into a pipe). It’s quite easy to emulate if you write your code to
generate the image in the same way as the hardware, but achieving it
with OpenGL requires some thought (I’m imagining rendering the sprites
in reverse order to an offscreen buffer, abusing stencil or depth or
something as the priority bit, then combining that with the background
in a second pass).

The following thread describes the issue:
http://nesdev.parodius.com/bbs/viewtopic.php?t=4267&sid=c75e720fd7f10d0e8f974b62db98b77dOn Sat, May 29, 2010 at 12:53 AM, Bob Pendleton wrote:

Thanks guys. I see the problem. My view was way over simplified.

Yeah, real nasty. While trying to write this reply I’ve run through
several techniques that I thought would work, but when I tried to
describe it I saw where it would fail.

Thinking about the extreme limits on component counts on chips from
those days I can see how this behaviour could be the result of using
the simplest possible design for the hardware that checks to see if a
pixel should come from the default, the background, or a sprite. Doing
it “right” could have added a few more gates and blown the component
budget.

Thanks for the info. A day when I learn something is a good day!

Bob PendletonOn Fri, May 28, 2010 at 12:53 AM, Bob Pendleton <@Bob_Pendleton> wrote:

Do you mind explaining the hardware problems that force you to do what
you describe?

Sure. Sprites on the NES have a foreground/background priority bit
that describes whether they appear in front of or behind the playfield
characters. That alone would be trivial to emulate - draw the
background sprites, draw the playfield, draw the foreground sprites -
but there’s a twist to it. Call it a bug, a design flaw, or just the
implementation details showing through. Sprite priority doesn’t apply
between sprites - a “background” sprite can appear in front of a
"foreground" sprite at the same location, if it’s at a lower index in
the sprite table. That is, the sprites are evaluated in order, with no
regard to priority, to produce a color value and priority bit, and
only then is the result of that tested against the background. This
can cause foreground sprites to disappear behind the background. It
sounds like an obscure thing, but quite a few games take advantage of
it for simulating the ability of the playfield objects (such a pipe,
or the ground) to mask a foreground sprite which should
appear/disappear behind it, and where you can’t set the sprite itself
to background priority because that would prevent you from having any
other art in the background where this is going it (you don’t want
mario to disappear behind clouds or a bush as he starts to descend
into a pipe). It’s quite easy to emulate if you write your code to
generate the image in the same way as the hardware, but achieving it
with OpenGL requires some thought (I’m imagining rendering the sprites
in reverse order to an offscreen buffer, abusing stencil or depth or
something as the priority bit, then combining that with the background
in a second pass).

The following thread describes the issue:
http://nesdev.parodius.com/bbs/viewtopic.php?t=4267&sid=c75e720fd7f10d0e8f974b62db98b77d


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------