Jump to content
svenvandevelde

VERA - alpha channel in palette?

Recommended Posts

 

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?

 

 

Share this post


Link to post
Share on other sites

It would probably be possible, but 16-bit RGBA is more detail than is used for most modern images (most modern images use 8-bit RGBA), so it would definitely compromise the retro aspect of the X16.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
4 minutes ago, Elektron72 said:

It would probably be possible, but 16-bit RGBA is more detail than is used for most modern images (most modern images use 8-bit RGBA), so it would definitely compromise the retro aspect of the X16.

Sorry, I wrote my text wrong I see... I'll need to change it ...

Edited by svenvandevelde

Share this post


Link to post
Share on other sites
3 minutes ago, svenvandevelde said:

I have let your reply sink in. These kind of aggressive replies are confronting and demotivating to continue with the X16.

I wrote my post wrong. I meant 4 bits, not 16 bits ... I should better go back to sleep. I'll just let it.

 

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.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
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.

Bingo. Many vintage systems did transparency effects this way and it’s actually a very charming approach.


Sent from my iPhone using Tapatalk
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
46 minutes ago, 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?

 

 

I think I might understand what you mean. A slight language barrier perhaps is leading to confusion here. Currently, there are 4 bits or 16 values for each color channel:

image.png.8f97e2201cdd3a8771db60e38a7b04d8.png

Are you proposing to use the most significant 4 bits of the second byte (currently unused) to give 16 levels of alpha?

Edited by Wavicle
  • Like 1

Share this post


Link to post
Share on other sites

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.

So, for a 50% transparency, you'd have an original tile as a source and then two tiles with those original pixels but every second pixel mapped to 00 in a checkerboard pattern; these two new tiles would have the opposite checker board, so for 1/60 of a second you'd see half the pixels and then for 1/60 of a second you'd see the other half of the pixels, switching back and forth.  Or for a 1/3 or 2/3 transparency you'd have 3 copies of the original with either 1/3 or 2/3 of the pixels mapped to 00, and then switch between the three tiles every 1/60 of a second.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
8 hours ago, 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?

Man, talk about everything old being new again, there was discussion of adding transparency to color back in the Gameduino days.

If it is four level transparency as a persistence of vision illusion rather than a blend transparency, then there could be a two bit counter incremented every vertical back porch, and when the counter is less than the alpha level for a color, the color is treated as transparent.

But if Frank figures it's pretty much done and dusted, then that would be a question for people playing around with things down the track.

And it's more bragging rights for whomever does it by playing games on the VSYNC interrupt (as described above) if THEY generate the illusion rather than having Vera do it automatically.

Edited by BruceMcF
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
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.

Edited by Elektron72

Share this post


Link to post
Share on other sites
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?

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
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).

Edited by Wavicle
  • Thanks 1

Share this post


Link to post
Share on other sites
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.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

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.

Edited by StephenHorn
  • Sad 1

Share this post


Link to post
Share on other sites
Posted (edited)
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.

Edited by BruceMcF

Share this post


Link to post
Share on other sites
Posted (edited)
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:

image.png.07bf8e146f41e755267069e84217b90d.png
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 ... 

image.thumb.png.c38936ec5a154b036927a3d9f7b1d76d.png

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

Edited by svenvandevelde

Share this post


Link to post
Share on other sites

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.

image.png.b17fa455606179c1395300abb1104946.png

Visually the results looked about right.

AlphaSprite.thumb.jpg.abbd4a375e9e198ed8551ed8e817adbe.jpg

(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.)

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
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.

image.png.b17fa455606179c1395300abb1104946.png

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)

Edited by svenvandevelde

Share this post


Link to post
Share on other sites
Posted (edited)
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):

image.png

Edited by Wavicle

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use