4-color Sprite idea without layering sprites
Moderator: Moderators
4-color Sprite idea without layering sprites
This is just a theoretical technique I came up with to allow a special sprite, such as the player, to have 4 colors - presumably black and 3 others - without layering sprites.
The caveat is it requires CHR RAM and a ton of ROM to feasibly do. But I think it should be effective.
It works by creating a rudimentary form fake sprites in realtime. Here are my notes, hopefully they'll be comprehensible:
-------------------------------
extra color / shadow engine (fake sprites)
make background color black
have chr ram and reserve the maximize size of a sprite in the bg's pattern table. this will only work for objects
that are not reused on the same screen.
our mask is size of sprite + 1 in both directions ... so 16x32 becomes 3x5 tiles (15)
have everything ready to go before vblank
prepare an AND mask asset in relation to sprite graphics
it may make sense to store this mask in continuous column strips rather than left-to-right tiles.
now construct a fake sprite out of it
for the y axis,
start on the correct row and "spill" into the next tile the (8-(y mod 8)) row
for the x axis,
so basically rotate each row in an unrolled loop into the next column
after we've constructed a mask, we can AND the underlying tiles with it to create the final tiles
during vblank, place these tiles on the map under a sprite in order to add outlines,
or anywhere (with no sprites at all) to create shadows or other effects.
therefore a sprite can have 4 colors this way.
to speed things up,
the mask creation in the x direction can be precalculated, so for our 16x32 sprite this becomes 3x4 tiles (12) x 8 (- 4) = 92 PER FRAME
if our sprite has detailed animations we could have 50 or so frames for it. this would mean 4600 tiles needed, or 36800 bytes!
the mask application might be able to be done directly from the mask rather than preparing a vertically-scrolled intermediate version
other different effects can be done if the mask is reversed for instance and we use OR or XOR instead. however this might not look nice if the fake sprite crosses attribute zone boundaries.
The caveat is it requires CHR RAM and a ton of ROM to feasibly do. But I think it should be effective.
It works by creating a rudimentary form fake sprites in realtime. Here are my notes, hopefully they'll be comprehensible:
-------------------------------
extra color / shadow engine (fake sprites)
make background color black
have chr ram and reserve the maximize size of a sprite in the bg's pattern table. this will only work for objects
that are not reused on the same screen.
our mask is size of sprite + 1 in both directions ... so 16x32 becomes 3x5 tiles (15)
have everything ready to go before vblank
prepare an AND mask asset in relation to sprite graphics
it may make sense to store this mask in continuous column strips rather than left-to-right tiles.
now construct a fake sprite out of it
for the y axis,
start on the correct row and "spill" into the next tile the (8-(y mod 8)) row
for the x axis,
so basically rotate each row in an unrolled loop into the next column
after we've constructed a mask, we can AND the underlying tiles with it to create the final tiles
during vblank, place these tiles on the map under a sprite in order to add outlines,
or anywhere (with no sprites at all) to create shadows or other effects.
therefore a sprite can have 4 colors this way.
to speed things up,
the mask creation in the x direction can be precalculated, so for our 16x32 sprite this becomes 3x4 tiles (12) x 8 (- 4) = 92 PER FRAME
if our sprite has detailed animations we could have 50 or so frames for it. this would mean 4600 tiles needed, or 36800 bytes!
the mask application might be able to be done directly from the mask rather than preparing a vertically-scrolled intermediate version
other different effects can be done if the mask is reversed for instance and we use OR or XOR instead. however this might not look nice if the fake sprite crosses attribute zone boundaries.
sonder
Re: 4-color Sprite idea without layering sprites
The same technique has been discussed in the forum before, and I think Bregalad make a proof-of-concept ROM as well, but I can't find the thread.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: 4-color Sprite idea without layering sprites
This one? viewtopic.php?f=22&t=9551&hilit=spritethefox wrote:The same technique has been discussed in the forum before, and I think Bregalad make a proof-of-concept ROM as well, but I can't find the thread.
sonder
Re: 4-color Sprite idea without layering sprites
Nope, that's not the one.sonder wrote:This one? viewtopic.php?f=22&t=9551&hilit=spritethefox wrote:The same technique has been discussed in the forum before, and I think Bregalad make a proof-of-concept ROM as well, but I can't find the thread.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: 4-color Sprite idea without layering sprites
Ah - I think I just found it. viewtopic.php?f=2&t=8366&hilit=sprite+colorthefox wrote:Nope, that's not the one.sonder wrote:This one? viewtopic.php?f=22&t=9551&hilit=spritethefox wrote:The same technique has been discussed in the forum before, and I think Bregalad make a proof-of-concept ROM as well, but I can't find the thread.
Guess I'm not original.
sonder
Re: 4-color Sprite idea without layering sprites
Well, if you consider that there's a finite amount of original ideas to be had, every time someone has one that's one less idea to be had in the future, so it's only natural that original ideas are harder and harder to have as time passes... =)sonder wrote:Guess I'm not original.
Re: 4-color Sprite idea without layering sprites
That's true. Well, I think that the precalculation idea could make it viable in software.tokumaru wrote:Well, if you consider that there's a finite amount of original ideas to be had, every time someone has one that's one less idea to be had in the future, so it's only natural that original ideas are harder and harder to have as time passes... =)sonder wrote:Guess I'm not original.
sonder
Re: 4-color Sprite idea without layering sprites
Just for info the thread you should be looking for should be this one :
viewtopic.php?f=22&t=9549
Having no personal site anymore I've chosen to store all my demoes on Nesdev so that whatever happens to me they'll be kept.
viewtopic.php?f=22&t=9549
Having no personal site anymore I've chosen to store all my demoes on Nesdev so that whatever happens to me they'll be kept.
Re: 4-color Sprite idea without layering sprites
Ahhh, I think I've seen this. Must of been that the idea was in the back of my head from seeing this.Bregalad wrote:Just for info the thread you should be looking for should be this one :
viewtopic.php?f=22&t=9549
Having no personal site anymore I've chosen to store all my demoes on Nesdev so that whatever happens to me they'll be kept.
The code from this could DEFINITELY come in hand with trying to implement my take on the technique. The dragon warrior sprite probably wasn't the best example as the flesh tone for the face could easily have been accomplished with a single extra 8x8 sprite (without much flicker impact). I think it'd be interesting to try to optimize the technique so well that a much larger character that moves in any direction could be viable.
I won't attempt it myself until I am deeper into conceiving my game though.
sonder
Re: 4-color Sprite idea without layering sprites
It's not possible at all. This technique is possible only because it's a 16x16 sprite and that it only moves in a non 16-pixel aligned position on either X or Y axis, but never both at a time.I think it'd be interesting to try to optimize the technique so well that a much larger character that moves in any direction could be viable.
Without such a limitation, there would be way too much VRAM update to do on every frame for being viable.
Re: 4-color Sprite idea without layering sprites
hrm. maybe it's possible for just single 8x8 sprites? for eyes or mouths on characters' faces or something.Bregalad wrote:It's not possible at all. This technique is possible only because it's a 16x16 sprite and that it only moves in a non 16-pixel aligned position on either X or Y axis, but never both at a time.I think it'd be interesting to try to optimize the technique so well that a much larger character that moves in any direction could be viable.
Without such a limitation, there would be way too much VRAM update to do on every frame for being viable.
edit: if i make a rule that the 8x8 area where the extra colors are used must be covered by solid sprite pixels, i.e. faces, then no extra mask data is needed except for a set of lookup tables used to construct a solid 8x8 square in a 2x2 bg tile area. The transparent pixels in the sprite would let the black show through.
sonder