General Projects Involving VERA

epsilon537 · Post by **epsilon537** » Wed Jun 01, 2022 8:50 am

On 6/1/2022 at 1:56 AM, Kalvan said:

Oh yeah! This means that you could recreate the waterfall effects of, say, the Sonic games, but make them work with (relatively) sharp A/V Multi-Out or VGA video output.

@epsilon537, if you're reading this, would this addition compromise the geometry of the softcore of the BoxLamda too much?

I don't think so. Either way, I don't necessarily have to track the latest and greatest in the original VERA repo. I have my own fork. I expect I'll be make changes in my fork such as giving the CPU and DMA memory mapped access to VRAM. Also, the whole point of BoxLambda is to create a sandbox for RTL and SW experimentation. That includes VERA.

svenvandevelde · Post by **svenvandevelde** » Wed Jun 01, 2022 5:22 pm

What would be great is to have eventually a capability to launch enhanced/ alternative innovations in the vera and have a chip upgrade made possible. So that those who want can use games using those upgraded features while maintaining backward compatibility ... I mean, the designer could include an alpha channel in the palettes. Those who have the extra transparency feature in vera would notice the transparency and those who don't would see the normal on/off pixel experience... it would be really great to have for various purposes like shadows, layered effects, explosion effects ...

kelli217 · Post by **kelli217** » Wed Jun 01, 2022 7:55 pm

Oh god please no.

Mutually incompatible 'improvements'? This way lies the same kind of issue that David talked about when he was discussing the various 80-column options for the C64.

svenvandevelde · Post by **svenvandevelde** » Wed Jun 01, 2022 8:41 pm

Please note the words backward compatible in the text.

kelli217 · Post by **kelli217** » Wed Jun 01, 2022 11:13 pm

Which requires that every program that makes use of these improvements have the ability to fall back to the default 'standard' VERA setup. Yes?

Scott Robison · Post by **Scott Robison** » Thu Jun 02, 2022 12:43 am

On 6/1/2022 at 5:13 PM, kelli217 said:

Which requires that every program that makes use of these improvements have the ability to fall back to the default 'standard' VERA setup. Yes?

I think the idea is that programs would be free to use advanced features that would simply not be rendered if a particular version didn't support it. If using transparency, for example, and the version didn't support transparency, one would wind up with solid colors rather than alpha blending. I can see how a system could be made backward compatible but it still sounds like a pain. Maybe I'm in the minority, though.

I would never begrudge people running mods on their own hardware if that's what they want to do, but I would not be inclined to support those mods myself. I'd code to the lowest common denominator, which is the base platform usually.

svenvandevelde · Post by **svenvandevelde** » Thu Jun 02, 2022 4:01 am

Tbe designer of the vera had limited time to come up with a version that works and solid in design, which it is.

But should it stop there?

The vera has some fantastic features but also has its limitations. The 128k memory and the lack of transparency are the most important.

The CX16 has a concept of bram memory expansion too. So with this in mind, this might be some kind of a pain also. Imagine a cx16 with 2 megabytes of bram. Which program will actually make use of it? The benefits are clear having a larger memory pool, however it also brings extra complexity.

Not even talking about these expansion slots on the cx16. Great from a hardware perspective but how to make the software work in a generic way with or without those expansion cards. Unlikely.

It's like the games coming out today running on a c64 with expansion cards and CPU accelerators. Neither are backward compatible.

I think that regarding the vera, the alpha channel had some potential.

https://github.com/fvdhoef/vera-module/issues/3

But yes, it will likely be a pain where the designer might need to have 2 versions of graphic engines and/or graphics rendered.

Also the more I think about it, in a palette of 16 colors the alpha is limited because in 16 colors your palette composition has to combine levels of red x green x blue x alpha. So it won't be obvious. Let me try to generate a few examples how transparency could be achieved in 16 colors palettes that I use for my game ... the sprites are rendered in blender and the images are then post processed using Spriter.

Again we are a bit free wheeling here so pls don't take my comments too seriously ?

Wavicle · Post by **Wavicle** » Thu Jun 02, 2022 5:28 am

I looked into adding alpha after VERA was first opened. Unfortunately with the current design, the bits in the line buffer that would be used for sprite transparency are used for sprite collision. Supporting per pixel transparency would mean giving something else up.

svenvandevelde · Post by **svenvandevelde** » Thu Jun 02, 2022 6:25 am

On 6/2/2022 at 7:28 AM, Wavicle said:

I looked into adding alpha after VERA was first opened. Unfortunately with the current design, the bits in the line buffer that would be used for sprite transparency are used for sprite collision. Supporting per pixel transparency would mean giving something else up.

interesting. however, i've found that the vera hardware collision is of doubtable use. Been there, done that ...

I mean, in a complex collision scenario the hardware collision detection has very limited applicability of use and the programmer needs to find its resort to other algorithms in a software approach.

The collision detection does not tell you where actually the collision is occuring, and in a multiple x multiple collision detection scenario, it is even of less use, as it does not tell you which object collides with which object.

Would it be possible to "use" those collision bits for the alpha and kind of "disable" the hardware collision?

Wavicle · Post by **Wavicle** » Thu Jun 02, 2022 7:40 am

On 6/1/2022 at 11:25 PM, svenvandevelde said:

interesting. however, i've found that the vera hardware collision is of doubtable use. Been there, done that ...

I mean, in a complex collision scenario the hardware collision detection has very limited applicability of use and the programmer needs to find its resort to other algorithms in a software approach.

The collision detection does not tell you where actually the collision is occuring, and in a multiple x multiple collision detection scenario, it is even of less use, as it does not tell you which object collides with which object.

Would it be possible to "use" those collision bits for the alpha and kind of "disable" the hardware collision?

I can't think of a reason why repurposing those bits for alpha blending wouldn't work. The only caveat I can think of is that all of the hardware multipliers have been allocated to other functions. With only 16 possible levels of alpha, you can probably do the blending as 16 different logic cases without the need for a multiplier. I seem to recall a little over a year ago I prototyped a 12 bit color alpha blending design on an FPGA using some clever bit shifting. I think it gave me alpha levels of 1/(2**n) and 1 - 1/(2**n) (i.e. it had 50%, 25%, 12.5%, 6.25%, ... as well as 75%, 87.5%, 93.75%, ...). My recollection was that with 12 bit color, only 87.5%, 75%, 50%, 25%, and 12.5% were of any use. My opinion at the time was that hand picking 16 different alpha levels would yield much better results.