VERA - alpha channel in palette?

[svenvandevelde]

On 3/24/2021 at 2:56 AM, svenvandevelde said:

 



Would it be possible in the future releases of the X16 to patch to the VERA with an RGB + alpha channel in the palette definition matrix? Where VERA would support RGBA. So 16 bits for red, 16 bits for green, 16 bits for blue and 16 bits for transparency?



 



 

There are these moments when you wake up in the night, due to a problem, question or topic that was floating in your mind for a while, and you just cannot go back to sleep ... . Well, I had such moment :-).

So to get peace in my mind, I decided to take action, and ask the X16 forum members about that question, but I wrote the post in the middle of the night (like 2am) using my mobile,  and I messed up a bit ...

Svennie! For a 4 bit per pixel VERA configuration, you'll have 16 colors, reflected in the palette as 4 bits per color channel, so it would be 12 bits, making 4096 possible color configurations. I mixed up the colors with the bits (sorry).

What I wanted to indicate that in the palette registers of the VERA, you have essentially 2 bytes per color offset, 1 byte for GREEN and BLUE, and one byte for RED, leaving 4 bits of that last byte unused...

From the VERA manual:



So I was thinking, why didn't Mr. Vanderhoef consider to implement an alpha channel (RGBA)? i guess it's just a valid question to ask, isn't it?

But now ... the more I think about it, the more I think it would be overkill ... When you realistically would want to reflect tiles in 4 BPP mode, then you'll have essentially 16 colors per tile...

If you within this 16 colors would need to reflect color configurations containing an alpha channel, then that would bring an additional dimension to take care off in your color config.

Let me give an example: if you have let's say a shaded tile, that would shade from dark yellow to light yellow, and you would want to add "transparency" to that, then your shading palette would be cut by the amount of transparency layers you would want to implement.

It's impossible for example to implement a tile with 8 different colors, and 4 transparency layers, because these won't fit into the 16 color configurations (8 x 4 = 32!) ... 

So not sure now that my question about the alpha channel was a valid one for a retro configuration like the X16 ... It might just indeed be better to deal with a simple one color transparency (black), leaving 15 colors to model your palette for a tile or sprite in 4 BPP mode.

My question was all about the underlying, which I will explain in a later post in detail ... Because on this background (which is auto generated), "space" stations and fire units and landing zones will be put, that will allow the player to land and recharge, rearm, repair ... Those stataions will be graphically reflected as sprites, that will kind of scroll with the background scrolling speed. and in order to put those decently on top of the background, it would be nice to have "semi-transparency", so through an alpha channel in the palette color config. I'm afraid that the sprites will look heavily pixellated ... 



I  am very much appreciating the ideas brought up in the above posts by all who contributed, highlighting tactical solutions on the topic with the existing hardware.

Sven

[Wavicle]

I hacked together a test to see the impact of sprite-level alpha blending on one of those cheap Cyclone II EP2C5 FPGA boards that I had lying around. The good news is that it didn't it consume any hardware multipliers; the bad news is that the impact to the number of logic elements was much higher than I think is reasonable - ~50 LEs per color channel.



Visually the results looked about right.



(The "sprite" is the square between the yellow and cyan bars. It's 100% white, but here has an alpha of either 75% or 25%, I forget which way I set the logic.)

[svenvandevelde]

On 3/29/2021 at 12:48 AM, Wavicle said:

I hacked together a test to see the impact of sprite-level alpha blending on one of those cheap Cyclone II EP2C5 FPGA boards that I had lying around. The good news is that it didn't it consume any hardware multipliers; the bad news is that the impact to the number of logic elements was much higher than I think is reasonable - ~50 LEs per color channel.







Visually the results looked about right.



 



(The "sprite" is the square between the yellow and cyan bars. It's 100% white, but here has an alpha of either 75% or 25%, I forget which way I set the logic.)

Hi, i'm not a hardware technicial, but does the last sentence mean that the speed of updates was limited? (~50 LEs per color channel)

[Wavicle]

4 hours ago, svenvandevelde said:

Hi, i'm not a hardware technicial, but does the last sentence mean that the speed of updates was limited? (~50 LEs per color channel)

Nope. It means the resource consumption was higher than I expected. A "logic element" is kind of like a unit of work that the FPGA can do. It isn't too picky about whether it is doing that work serially or in parallel, but once you run out of them you cannot add any more functionality to your design. This is what a single LE looks like (though in practice it isn't something you actually think about):

[svenvandevelde]

What would be one of the benefits of transparency is to be able to cast shadows as a layer on top of other objects. It would greatly reduce the amount of tiles you need to setup a shadowy environment. Data would be reduced significantly.