Commander X16

5 hours ago, Ed Minchau said:

Thinking about this some more, there's a way to have 1/4 transparency, 1/3, 1/2, 2/3 or 3/4 using the VSYNC interrupt.  You could have two, three, even four tiles that all look similar except with different pixels mapped to 00, and alternate between these with every VSYNC, or every second or third one even.  The switch happens too fast for the eye to really register, and instead your mind fills in the gaps and sees it as transparent.

I've already tried this by toggling the text layer on and off every other frame. While it will probably work on the actual hardware, the current version of the emulator does not have a stable enough frame rate to make this effect look good (unless my test code was broken). Hopefully future versions of the emulator will run smoother.

11 hours ago, Ed Minchau said:

I think the best you could do for transparency on VERA would be to make every second pixel on a layer 1 tile or a sprite color 00 in a checkerboard pattern.

This is exactly my plan for fade in/out effects I'm planning on my game... It's how "transparent" water layers were added in Sonic and Mario on Genesis/SNES. I'm not going to use a layer though - I'm just going to use a few 64x64 sprites as a "fade layer" since my effect is to make the screen fade to a solid color (fade to black, fade to white, fade to red, etc).

I've often thought that a 4-bit alpha value could slip right into the VERA palette and the SNES had alpha-like color math capabilities, so it wouldn't be 100% out-of-place, but having a certain set of possibilities to work with is what makes things interesting, right?

13 minutes ago, ZeroByte said:

since my effect is to make the screen fade to a solid color (fade to black, fade to white, fade to red, etc).

I do this in "Invaderz" and "Brixx" by changing the palette. Of course this changes the entire screen, on all layers, including sprites.

4 hours ago, Elektron72 said:

I've already tried this by toggling the text layer on and off every other frame. While it will probably work on the actual hardware, the current version of the emulator does not have a stable enough frame rate to make this effect look good (unless my test code was broken). Hopefully future versions of the emulator will run smoother.

Your test code might be broken. I didn't notice any problems with the frame rate on my video demo.  What does your custom IRQ handler code look like?

15 minutes ago, Ed Minchau said:

Your test code might be broken. I didn't notice any problems with the frame rate on my video demo.  What does your custom IRQ handler code look like?

It was a while ago, and I believe I may have deleted the test program since then. When it ran, there would be flickering between the desired appearance (a darker version of the text layer), the original text layer, and the black background color. I might try and rewrite the test at some  point in the future.

6 minutes ago, Elektron72 said:

It was a while ago, and I believe I may have deleted the test program since then. When it ran, there would be flickering between the desired appearance (a darker version of the text layer), the original text layer, and the black background color. I might try and rewrite the test at some  point in the future.

Well, it is important that the emulator be running at full speed for an effect like that, but even a small timing glitch could cause flickering behavior, such as the thread being put to sleep for too long, or a particular frame taking unexpectedly long to execute.

 

While an alpha channel isn't conceptually impossible to add to the VERA at some point, some of the real question is whether it can be fit into the FPGA's remaining logic units without having to shave functionality from somewhere else. On the technical side, it's worth pointing out, as well, that you probably don't want the alpha to apply to individual colors in the palette. But even if you did, what about layer and sprite alphas for fading out individual elements which may share palette colors with something else on the screen? And how would that potentially interact with an alpha channel on palette entries?

Having alpha in the color channels also places a much greater emphasis on Z-ordering, in particular where sprites are concerned*. I suppose that's not a problem if you're calculating your own Z order and clobbering all sprite data every frame in order to apply it, but that sounds expensive. I haven't timed it out, I'm just saying that my gut instinct is to avoid that practice for more than a handful of sprites, if possible.

 

* The Z-order of transparent objects determines which alpha channels have the greatest contribution to final color, with the smallest contribution coming from the object furthest in back. Transparency is a big deal in graphics programming, there have been a lot of papers written to try and solve various transparency-related problems in 3D graphics. Realistic "smoke" and "fog" effects, in particular, are extremely hard to make look good in a variety of circumstances, and lot of it has to do with Z-ordering issues. Perhaps one of the biggest appeals of realtime RTX on the latest generations of GPUs is that you don't have to worry (as much) about variously-expensive transparency effects, because you can choose to ray-trace instead.

10 hours ago, StephenHorn said:

While an alpha channel isn't conceptually impossible to add to the VERA at some point, some of the real question is whether it can be fit into the FPGA's remaining logic units without having to shave functionality from somewhere else. On the technical side, it's worth pointing out, as well, that you probably don't want the alpha to apply to individual colors in the palette. But even if you did, what about layer and sprite alphas for fading out individual elements which may share palette colors with something else on the screen? And how would that potentially interact with an alpha channel on palette entries?

I think the best way to minimize gates and/or logic elements would be to only allow inverse power of 2 alpha levels (e.g. 1/1, 1/2, 1/4, 1/8, 1/16) and their complements (e.g. 1-1/4, 1-1/8, 1-1/16).

5 hours ago, StephenHorn said:

... While an alpha channel isn't conceptually impossible to add to the VERA at some point, some of the real question is whether it can be fit into the FPGA's remaining logic units without having to shave functionality from somewhere else.

Yes ... if it turns out there are actually spare resources, I would prioritize having some hardware ADSR envelopes that can be attached to PSG channels over hardware transparency. Even four would be handy.

The more I'm thinking about it, the more I think alpha will be a non-starter for the VERA because there's no way around multiplies and division. Even if you're thinking "well, powers of 2, just bit-shift", the problem is that after you multiply the color components by their opacity, you add them to create a weighted value which is then divided to arrive at the final color component. So we're talking about 6 multiplies, 3 adds, and 3 divides, and that's just to calculate opacity between two color values. With three layers of sprites, not even counting the possibility of overlapping sprites within a single Z-layer, that's another 9 multiplies, adds, and divides. Even if the multiplies are converted into bit shifts, that's still 12 divides that can't be avoided with bit-shifty trickery.

I just don't think that's in the cards, and even if it were I really think the math would be better spent on filling out in-demand audio features.

2 hours ago, StephenHorn said:

The more I'm thinking about it, the more I think alpha will be a non-starter for the VERA because there's no way around multiplies and division. Even if you're thinking "well, powers of 2, just bit-shift", the problem is that after you multiply the color components by their opacity, you add them to create a weighted value which is then divided to arrive at the final color component. So we're talking about 6 multiplies, 3 adds, and 3 divides, and that's just to calculate opacity between two color values. With three layers of sprites, not even counting the possibility of overlapping sprites within a single Z-layer, that's another 9 multiplies, adds, and divides. Even if the multiplies are converted into bit shifts, that's still 12 divides that can't be avoided with bit-shifty trickery.



I just don't think that's in the cards, and even if it were I really think the math would be better spent on filling out in-demand audio features.

The alpha channel being discussed back in early 2019 before the Gameduino was abandoned with to use the parity bit, so it was exactly 1/2: add the three values, shift each result right.

Even 1/4, 1/2, 3/4 is six parallel 5bit adds and three 5bit adds of the respective high four result bits, so it extends the pipeline by two steps if the transparency level is decoded (each bit select one of the four operands for the two original adds), maybe three steps if it is a level that requires decoding, depending on whether the decode can operate in parallel to the previous pipeline step. OTOH, I wouldn't know how much in logic resources that would require and whether there is any spare resource.