Can I replace alpha with a non-tranparent color in sprites?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Can I replace alpha with a non-tranparent color in sprites?
by on (#89030)
I am designin graphics with the NES limitations for a PC game.

I am wondering that is it possible on a real NES to use sprites with 4 colors instead of 3 colors + alpha? I know that the first color of all the 4 sprite palettes must be the same color (alpha), but could this be set to some non-transparent color (for example black)?

by on (#89031)
No, you can't turn off the transparent color for a given sprite. You can put a second sprite with a different palette behind a given sprite, but that may use up a palette, and it will likely lead to increased flickering. Could you show a mock screenshot so that we can give suggestions on how best to draw this sprite?

by on (#89032)
Thanks, that was exactly the answer I needed!

Sadly I don't have any example graphics of this particular situation since I decided to ask this before doing anything that would require non-transparent sprites. It was as I expected so I'm not gonna use any sprites without alpha then. And I am familiar with the multiple sprite layers and the OAM cycling :)

Thank you!

by on (#89056)
http://nesdev.com/bbs/viewtopic.php?t=8366

Bregalad did.

by on (#89057)
Even if done, you'd have to have completely square sprites. Not worth it.

by on (#89070)
Although there are complicated ways to simulate this, like Bregalad did, it would be very hard to take all the implications into consideration when making a game that only LOOKS like a NES game but doesn't actually suffer from the same limitations.

With Blagalad's technique, the number of tiles that need to be reserved for the effect and be updated during VBlank quickly increases as the objects/character get larger. If he actually wants to make something that COULD run on the NES, he'd have to take into consideration the amount of tiles the NES can actually use for the background and are realistically updatable during VBlank, otherwise it would be "cheating".

3gengames wrote:
Even if done, you'd have to have completely square sprites. Not worth it.

Not with Bregalad's trick. The main visual limitation there is that the extra color must be present in all background palettes... so it's either color 0 or some other you have intentionally repeated.

by on (#89071)
Yeah, but "my trick" (in reality psycopathicteen's trick - I just coded it) is only applicable for really small sprites, like 16x16. I already have to upload 6 tiles during VBlank plus nametables updates (in a real game you'd also need nametables + color updates relative to scrolling) which is near the limit without using any unrolled loop nor extending VBlank.

If you have larger sprites, for example a 16x24 sprite, then you'd need to update 8 or 9 tiles every frame (depending on scrolling direction). It'd be workable with unrolled loops but it would really reach the limit of updates the NES can do. As the sprites goes larger you'd better have to use different palettes for different parts of the metasprite or use multiple layers.

The only problem with multiple layers is that it really eats some of the 8 sprites per line limitation (it also use more CHR space).

by on (#89074)
3gengames wrote:
Even if done, you'd have to have completely square sprites. Not worth it.

A transparency bit might have been worth it for sprites that are square by nature, such as moving platforms.

tokumaru wrote:
Not with Bregalad's trick. The main visual limitation there is that the extra color must be present in all background palettes... so it's either color 0 or some other you have intentionally repeated.

And as Bregalad pointed out while I was typing this, the main speed limitation is only being able to use it with one sprite at a time if you don't want the game falling to frame rates typical of the Apple II or ZX Spectrum. Calculating and blitting those tiles takes time.

by on (#89075)
tepples wrote:
A transparency bit might have been worth it for sprites that are square by nature, such as moving platforms.

Or the inner parts of meta-sprites.