Transparency on the SNES

I was reading this wiki page about the transparency effects on the SNES: https://wiki.superfamicom.org/
It answered most of my questions, but I'm still left with one: Can the SNES use two different transparency effects at the same time? Like, can I have part of the screen use a subtraction method, and part of the screen use an addition method?
If so, what are the limitations? Can I run both effects on one layer, or would I need to use two layers, one for the addition and one for the subtraction?

And as I write this it occurs to me that I should check about something else. When the SNES is using a transparency effect on a background layer, does the effect need to work across the whole layer? Or could I, say, have layer 3 display my health bar and such at the top of the screen, and then apply a lighting effect in the play area?

I don't have an answer because i know nothing about the SNES. Disregard this post for anything that *must* comply with SNES specifications. but in photoshop (and this'd work in regards to PC 2D game engines), i sometimes do double-layering 50% add over 50% subtract, which you could use if you don't have access to more complex blending modes or percentage options. Double-layering 50% subract over 50% add yields more subtle results, which could be used for fine mists and dust in light ray-type of effects. Then again, on a PC platform you could just set the percentage to taste on a single layer to achieve whatever you want. The 25/50/75 % blending is just an arbitrary restriction i might force on myself. (Double-layering in photoshop with add/sub is kind of pointless, actually. But you get a one-click or one-drag toggle between three useful percentages, vs typing it in).

You can use one blending mode on one range of scanlines and another blending mode on another range, using an hblank IRQ handler or HDMA to make the switch. On any scanline, you can limit the effect of blending to up to two horizontal ranges of pixels (the "window"). The easiest ratio to get is 50%, but 75-25 ratio should be possible using pseudo-hi-res, the 75% layers on the sub screen, and the blending mode set to (main+sub)/2.

Another option available to you is to blink sprites on and off every frame for a 50% opacity effect (this also works on the NES)

Except It doesn't! Maybe on some modern TVs, where you may also get stripes instead of transparency, but on CRT TVs I've never seen flicker look like actual transparency.

I don't think it's as bad as you say.

I'd use it for something like a fog maybe, or transparency as an "effect" (like temporary invincibility), but not like transparent glass, water, a bright light, etc.

Okay, so I couldn't use it in the way that I want for what I'm doing right now. Dang, oh well. Thanks for the info.



Even when I was a kid playing the SNES I noticed the difference, and I thought it looked cheap and crappy. To this day I wonder why they didn't use the hardware transparency effect in Illusion of Gaia for the scene in Mu where everyone was supposed to look like a ghost.

tepples covered part of this, but the other part wasn't covered:


Yes, you can do the the latter with the window mask MMIO registers ($2123-212F).

What is it you're doing right now? You haven't described anything that wouldn't work, at least not in sufficient detail for us to determine that. Certainly if you're talking about a health bar at the top of the screen, you can change just about anything you want in between that and the stuff lower down.


General rule of SNES graphics: you can change settings in between scanlines with HDMA (or an IRQ, but HDMA is usually better). VRAM and OAM are essentially off limits during HBlank (aside from the Uniracers trick), but CGRAM and most of the PPU control registers work fine.

As stated, windowing can be used to shape the blending region, with HDMA used to control the windows.

It seems to be the case, according to your source, that backdrop colours (CGRAM #0 and the constant colour) do not get divided by two regardless of $2131. If so, it is indeed possible to use both addition and 50% blending (or subtraction and superdarkening) on the same scanline, but you can't window them separately because colour math windowing is all-or-nothing.

If I recall correctly, based on some stuff I've done, it may be possible to change the blend settings mid-scanline by writing to the relevant registers during rendering. However, the least insane way to do this is with an H-IRQ, which eats a lot of compute time, and hitting the same pixel every line is virtually impossible so you need a fairly wide buffer region where blend settings don't matter. I wouldn't recommend it unless it's absolutely necessary, especially if you're not using a coprocessor.


Leaving aside pseudo-hires, you can only use one blending effect at a time because it's done using a main screen and a subscreen, so there are only two inputs, and only one operation between them is done (plus optionally dividing the result in half). So mixing two types of blending on the same pixel is not possible in the general case.

Unless I'm much mistaken, pseudo-hires cannot blend three actual graphics layers, because there is only one subscreen. It can blend two layers via analog fuzziness by alternating main and sub half-dots, and then add or subtract the constant colour (which of course is controllable via HDMA).


According to this, if you use layer blending in hires mode, the main screen pixel gets blended with the subscreen pixel, and the subscreen pixel gets blended with the previous main screen pixel. And according to this, pseudo-hires works exactly the same.

I was planning on having a torch light effect that would have addition around the torch (eg Musya) and subtraction further away to create shadows. But that would require a single scanline to use subtraction, then addition, and then subtraction again. Well, unless I designed it so the torches were close enough that you never needed to add shadows between them, so there was addition at the top and subtraction at the bottom... But that would conflict with other designs I have in mind for the level.

Also, bit of curiosity...

I know what IRQ is, but what's HDMA?

HDMA is the thing that automatically writes a small handful of bytes somewhere—almost always to the PPUs—during hblank on an arbitrarily configured set of scanlines.

Used for changing properties on a scanline-by-scanline basis, like updaing the matrix registers for the 3D perspective view in FF6's world map, or top-and-bottom split screen.

Is there a way you could draw the torches in combination with the background so they look additive/glowy, and just use subtraction elsewhere?

One nice part about addition and subtraction, without halving, is that if you use a graphics layer rather than just constant colour, you can do smooth gradients between full effect and zero effect. So if you rig your graphics to work at one extreme without any effect, you may be able to design the effect to give you the other extreme and as much in between as you want.

Also remember that if the effect is static with respect to the background tiles, or displays very limited animation, it may be a better idea to just render it down.

...

I had an idea that may be relevant. In order to do simultaneous glow and darkening effects, I was thinking of having part of the background layer have its colours split between the main screen and subscreen, and part have all its colour on the main screen and none on the subscreen. In the split-colour areas, addition would just produce the normal desired colours, while masking the subscreen (or the main screen, I suppose) with a sprite or a window would produce a darkening effect (and then you could do an additive glow object within the shadow if you wanted). In the all-main-screen colour areas, shadowing would not be possible, but normal additive glow would be. Note that shadow support in this scheme is per-pixel, not per-tile, because what matters is the colour values on main and sub screens, not any tile attribute.

The catch is that it's hard to do glowy bits over the areas that support shadowing, without there actually being a shadow there. You can have glow over the non-shadow-supporting areas, and you can have glow over actual shadows, but you can't easily have glow over an area that can have shadows but doesn't - you'd need to crank the values on the glowy bit so that it still looks okay even blended with only part of the BG colour. Unless you want to do software rendering or sprite mask tricks or some such fiddly edge-case stuff...

The same is true to varying degrees if you try to use a gradient mask (made of actual tiles, obviously; windowing is Boolean), which is possible if the layer you're masking off is a uniform colour and all the detail is on the other layer. As the shadow fades into normal lighting, glow effects will look progressively worse because the glowing object is masking off the subscreen colour and looking more and more like alpha blending or something along those lines. It would look even weirder if the glowing object straddled the boundary between shadow support and non, because there would be an abrupt change to looking correct again (or a gradual change, depending on how you set up shadow support; there's no actual reason it has to be a sharp line).

There's also the fact that this eats a BG layer (unless you use the constant colour, but then it's hard to do non-shadow-supporting areas). I originally thought of it in the context of Mode 7, which gives you two BG layers but they use the same VRAM pixel fetch; the only differences are priority and palette (BG2 uses the top bit of the colour index as a priority bit, so depending on its value the two layers can read different colours from CGRAM). In that context it's not really a waste to use BG2 for this, because it's virtually useless for anything else.

The above is purely a thought experiment; I haven't tried it. If I've had a brain fart, please alert me to the fact...

I just want to point that I've written a FAQ on this subject. You'll find it helpful.

As for answering your questions:

This is not possible, unless of course you split the screen vertically in different areas and change how transparency is used (using HDMA or IRQ or whathever similar).


You could use windowing as Koitsu pointed, but I'll also point that all SNES background layers have a priority bit, which can also be useful in this case. Typically if layer 3 is used for your status bar with the priority bit set, you could have other effects used in background having the priority bit clear, and have them subject to transparency. For instance, assuming you use mode 1 with the special BG3 priority (the most often used mode on the SNES), you'd want to have :

Main screen : BG1, BG2, BG3, SPR
Sub-screen : BG3
Transparency enabled on : BG1, BG2, BG3, SPR with addition and halving.
The level and sprites will be displayed normally. On places with the status bar on BG3 (priority bit set) it will be averaged with itself, which results in it being displayed normally as well. On places with visible image on BG3 with priority bit clear, normally it'd be hidden behind BG1 and BG2 and sprites. However, here it'll be averaged with them instead, having a transparent effect.

This only works with addition and halving mode. If you use simple addition mode, you should then not enable transparency on BG3, or else it'll see it's colours added with themselves, i.e. it'll display twice as bright as you'd expect. So if you want to use addition mode without halving you need the following setup:
Main screen : BG1, BG2, BG3, SPR
Sub-screen : BG3
Transparency enabled on : BG1, BG2, SPR with addition.

Oh and also:

It's as bad as Tokumaru says. Flickering for transparency looks OK on a LCD based modern PC-screen, it looks absolutely flickering on an original cathode ray tube TV used typically with NES or SNES.

It really really really depends on context.

For example: such as whether the room is well-lit, how bright the tube itself is, what percentage of your field of view the tube covers, whether it's a 50Hz or 60Hz set, how different the brightness of the two frames are, and so on. A CRT in a really well-lit room won't even look good at 60Hz, nevermind 25Hz. (more reading)

Remember that cinemas ran for the longest time at 24Hz and 50% duty cycle. (The mechanical shutter blocked the light during advance and then let light through. This did cause objectionable flicker, so eventually inventions were made that caused the light to flicker at 48Hz or 72Hz, even though new pictures still only arrived at 24Hz.)

Okay, I've come up with a demo of the idea I detailed above. I used the graphics provided by Marscaleb in the other thread.


This is the main screen. It's mostly set up for shadowing, but the area around the torch isn't. No effects have been applied; those are the colours as read directly from the palette.



This is the subscreen. Areas to be shadowed are masked off, and the torch and staff are given halo highlights. Again, these are direct palette colours with no effects.

Note that it's not necessary to have full texture in the subscreen layer. The classic subtractive shadowing effect would actually be better reproduced by using a uniform boost colour on the subscreen, with all the detail on the main screen. But I figured this looked more realistic...


The result of adding together the previous two images:


Hopefully that helps clarify what I was getting at with my wall of text. Please excuse any incompatibility with what the game is actually trying to do or what the graphics are intended to represent in 3D space*; this is just a demonstration of a concept and should not be taken as a specific suggestion.

Also note that if you're going to attempt something like this, you should make sure you're very familiar with how transparency works on the SNES. There are tons of arcane gotchas that only make sense if you understand the system really well, and it's easy to trip over them when designing a "SNES-like" PC game. Bregalad's writeup is a good start, but you need to understand how backgrounds, windowing and HDMA work too.

Which reminds me - there's a great YouTube series on the SNES that explains the technical details of the console with visual illustrations. I've found it to be very accurate, although unfortunately it's not done yet and doesn't update quickly. This is the one on DMA and HDMA: https://www.youtube.com/watch?v=K7gWmdgXPgk


* For instance, I've assumed the rusty metal-looking things are solid doors rather than support columns, because otherwise the light cast by the torch would fall on the player character and I wouldn't get to demonstrate glow-in-shadow.

Some of what's being depicted and discussed remind me of the effects used in Soul Blazer. See: ref 1 (note lighting effect around orb) and ref 2 (note "slight shift" in the area around the orb (hard to see on the low-quality recording), and the fact that things like stairways and chests become visible when within that area).

I forget exactly how these are implemented, but IIRC, it's a combination of add/sub screen effects + BG3 + priority bits + HDMA (for achieving the circular shape of the orb effects). The latter (use of HDMA) might not work well if you have, say, several torches on the screen at once, but should work if they all were sprites or tiles utilising BG3 in the manner Bregalad described.

Never forget that designing a game and then "trying to make the system comply with your demands" is not always the most feasible approach; the opposite (design a game with the limitations/design of the system in mind) is more practical, IMO. Just something to keep in mind when developing something. (93143 is the one guy who goes to great lengths to do the former, solely for the challenge. Haha :D )

I've seen the YT videos in question. They're "okay". Sometimes video is not the correct medium to use for training material, other times it's better than text; there's some stuff in there that is super helpful, other stuff that just makes my eyes gloss over. Everyone learns differently.

To acomplish what is made on your mockups (light up two different circles), you don't even need any layers. Just use windows clipping (combined with HDMA) and constant colour math. It's possible to do 2 shapes, but not 3 as that's how window clipping works. Since you want to do 2, that's exactly what you want to do.

My point is that the entire background (except for the square around the torch) can also be selectively shadowed at the same time. The shadow cast by the wooden platform, for instance, is achieved by using a window with HDMA to mask off the subscreen layer under it. I don't know if I was adequately clear about this - the "subscreen" I posted is before color math, but after windowing.


Nitpicking for the benefit of others less familiar with this topic:

You can do a more or less arbitrary number of glowy bits (notice that the flame, and not just the circle around it, is additive) as long as you use BG or sprite graphics for them. Except obviously that you can't use a sprite to cast a glow on another sprite.

You can certainly do more than two window shapes at a time. Just no more than two on the same line (barring edge cases). If they're scripted, as with certain types of full-screen effects, or locked to the BG layer, as with that torch, it's just a matter of planning.

...

This idea of mine might make more sense in a game where individual sprites can cast shadows, particularly a Mode 7 game where BG2 is so limited that you might as well use it for tricks like this. I originally came up with it when thinking of an F-Zero game in which the glowing exhaust trail has to show up over the car's shadow, but also over the glowing track edge and distant ground, neither of which should be shadowed by the car.

For a game like this, the method might be needlessly cute. If the torches are the only thing casting light, and sprites don't cast individual shadows, there's not much point in trying to combine glow effects with dynamic shadows, especially at such a cost in resources.