Commander X16

4 unused bits in each palette color, why not used for alpha?
at-least make sprites use alpha

*yes I know 0 is "transparent" for layer/sprite...not needed if we used alpha bits!

idk, some way of blending sprites or layers

Alpha,

Is because VERA say so. VERA only supports 1-bit on/off transparency..

The reason why the VERA has such limitations is likely found somewhere in the Git for the FPGA code -
https://github.com/fvdhoef/vera-module

I would hazard that it is due to the desire to use the simplest / cheapest FPGA that could handle the task, as well as this being common among different video chips in the 80s and 90s.

One clue to why there isn't any such alpha in the palette -> the VERA does not have enough memory throughput to as it is to compose a line using too many bytes worth of sprites, bitmap layers, and tiles.

viewtopic.php?p=26089&hilit=sprites+per+line#p26089

The VERA is a lot better at this than say the Sega Mega Drive's VDP... The VP could at _best_ display 1 scanline's worth of sprite data.. so if you had a row of sprites that were overlapping, the last few in the list would not display on that line... common example of this in actual games was when Sonic gets hit and all the rings fly out, especially when you have more than like 70 rings..

It was noted the VERA can process something like ~500 or ~600 pixels of sprites and other data a scanline... if this was using alpha blending rather than on/off transparency, then for each pixel the VERA hit with alpha !=0 or 1 would mean another addition and division to add to the processing, rather than just 'get a pixel into this spot and move on'.


is just my 2 cents on the subject.. If anyone else has more exact info please let me know.

To do "true" alpha blending, you really need a GPU and a framebuffer.

The VERA is line-buffer based, which is very common for 2D arcade and game console hardware, meaning it needs to prepare the next scanline using only the time it takes to output the current scanline to the screen, which doesn't leave room for complicated math.

While I don't think the VERA will ever be able to do "true" alpha blending, I think a feature similar to the SNES's "color math" would be possible. Though limited and restricted to simple addition, subtraction, and optional bit-shifting, it would allow some effects that look like partial-transparency.

So something something do it via software something using a kernel running over a bitmap layer with the multiplier/accumulator???

I dunno, sounds complicated....

Or is the suggestion being to add these features to the FPGA code ?

What's the fastest one could possible transfer data to the VERA? Like if you had an expansion card that took over the 6502 bus and just whacked the heck out of the VERA's DATA0 and DATA1 ports... how fast could you go?

hstubbs3 wrote: ↑Tue Mar 26, 2024 10:36 pm So something something do it via software something using a kernel running over a bitmap layer with the multiplier/accumulator???

I dunno, sounds complicated....

Or is the suggestion being to add these features to the FPGA code ?

What's the fastest one could possible transfer data to the VERA? Like if you had an expansion card that took over the 6502 bus and just whacked the heck out of the VERA's DATA0 and DATA1 ports... how fast could you go?

VERA itself seems to be stable at up to 10MHz or so, but you can't actually push a byte through on every clock cycle. I don't know that anyone has done DMA testing to see whether VERA can handle one byte per clock tick long enough to fill VRAM.