Feature request: alpha channel emulation

[XanCraft21]

I would post this in the discussions tab, but it is not available to me. Sorry for posting it here.

Hello, i was wondering if it would be possible to add alpha channel emulation to this library. I am aware that this library has no alpha channel support, but i was thinking if you could fake it with just a single alpha value that is set using glColor4f, and then use the value in blending operations. I am not able to figure out the correct values to create transparency using just purely color, and some kind of randomly created alpha value might be easier for me to work with.

If it is possible for you to add emulated alpha transparency i will gladly appreciate it. If not are you able to tell me how i could add it myself?

If it is completely impossible i could just the stipple effect instead. Thank you for reading, and i hope it’s not too much of a hassle for you and your team.

[tslmy]

Hi @XanCraft21 , I think I got what you want.

Here's a video demo of what I achieved: https://www.youtube.com/watch?v=O7Q57MJNzG0

Or here's a GIF:

The source code of this demo is here.

Three commits patched TinyGL to achieve that --

This commit tslmy@17a6399 added alpha blending:

• Extend glopTexImage2D: support GL_RGBA, GL_LUMINANCE, GL_LUMINANCE_ALPHA with separate alpha extraction, resize, and merge pipeline
• Add GL_SRC_ALPHA / GL_ONE_MINUS_SRC_ALPHA blend factors to TGL_BLEND_FUNC
• Preserve texture alpha through RGB_MIX_FUNC in 32-bit mode

Then another commit, tslmy@081a487, propagated vertex alpha to flat-shaded triangle blending:

ZBufferPoint now carries an 'a' field (0-255) populated from
glColor4ub's alpha via the vertex pipeline. The four flat-shaded
blend rasterizer variants (DT0/1 x DW0/1) pack this alpha into
the pixel's high byte so that TGL_BLEND_FUNC's GL_SRC_ALPHA /
GL_ONE_MINUS_SRC_ALPHA path works correctly.

Previously, RGB_TO_PIXEL left the alpha byte as 0, making all
blended flat-shaded triangles invisible (sa=0 → source=0).

Finally, I had this commit tslmy@1511e45 to fix the hard-coded value:

fix: add alpha interpolation to GL_SMOOTH blend path
Previously, TGL_BLEND_FUNC_RGB hardcoded sa=0xFF, making GL_SRC_ALPHA
a no-op and GL_ONE_MINUS_SRC_ALPHA zero the destination. This forced
all transparent geometry to use GL_FLAT (no color interpolation).

I have to admit that the patches were AI generated, though I tried my best understanding the problem and the decision that my coding agent made. As I am no expert in computer graphics, I want to ask for your and @jserv 's review into these patches, and -- if you think this is the right direction -- you or I can create a PR for this.

Of course, @jserv can tell us if alpha support is in TinyGL's roadmap at all. We can maintain a alpha-enabled fork if it is out of scope for this very repository.

[XanCraft21]

That sounds like a lot of work went into that. Does this also work with 16 bit color mode?

Even though the code was AI generated, as long as it works it should be fine right?

Just in the case this wasn’t possible i did get AI to make me a variable dithering function for the polygon stipple, and that could work for now. I might prefer true transparency over putting holes in my models sometimes though.

To tell you the truth i am really no help on the coding part of making our own maintained fork, since i’m not the best at it even though i’ve been coding for a few years now. I can definitely be your official tester though.

There could also be another thing that can probably be fixed, the far plane texture coords correction doesn’t work like it does for the near plane, which causes texture warping as the triangles get clipped against the far plane. If i wanted to make a low poly horror game with low draw distance i might see some weird texture wiggling in the distance.

If it’s ok with you if i download your modified fork and test it for myself?

[tslmy]

Please do! Let me know how it goes. I have not tested 16 bit mode myself.

If my set of patches would work for both you and me, then I think we are making a stronger case to have this merged to this repo.

Godspeed!

[XanCraft21]

I tested your version and i have to say only part of it works, but the change is pretty impressive. It works pretty well for untextured triangles with vertex colors, and the alpha value seems to be smoothly interpolated between the 3 points.

I have discovered a small bug with that though, when the alpha value is 0 the model is not fully transparent, but a slightly darker version of the colors behind it, basically it’s not fully transparent. So far i only tested with a hello world triangle and a red background using the clear color.

I also tested this on a textured cube, but for some reason the alpha value always appears to be 0 when using textured models, even with an image that contains an alpha channel, so it’s never visible except for the slightly darker version regardless of what the alpha channel in the texture and the color set by glColor3f is.

The picture below shows the hello world triangle (sorry for it being so small) being fully transparent but slightly darker than the background. I’m not posting an image of the textured version since it’s just the same thing.

You may be wondering why it’s a close up of a tiny screen on a base with a bunch of holes in it. I should’ve said i got these libraries working in the arduino ide and a strong microcontroller. I know this library is for pc use but i forced it to work on my chosen hardware with some small modifications. You can keep your modified fork for pc just fine, i’m just testing it on the worst hardware possible because i’m weird.

If it is possible we could just force the texture alpha to be 255 but still use the alpha from glColor3f when using plain RGB textures, and possibly also use the alpha channel in a RGBA texture if alpha channel textures already work with the library.

[tslmy]

Giving Claude Opus 4.6 another run on this right now. I don't believe my patches have been generic enough, so I'm telling it to start from scratch. I've also asked it to generate some tests for how colors should mix properly with alpha channels, for both untextured & textured models.

[tslmy]

@XanCraft21 Try this? ⤴️

[XanCraft21]

I have completed my testing of your alpha branch, and i have some good news and bad news.

The good news, the bug in the attached image in my previous reply is fixed, no more semi transparent triangle when alpha is set to 0. The bad news, transparent textured triangles are still bugged and reading alpha as 0.

I see you got it working with 32 bit color though, so we are definitely getting somewhere with this, but it still doesn’t work for 16 bit color and ZB_MODE_R5G6B5 when creating the frame buffer.

The reason i want 16 bit working is because i plan to make a handheld game console on a device with limited memory, like about 16 mB of ram or less. This library works mostly fine for this, and it didn’t take that many modifications to make it work.

I am assuming the part of the code where the alpha bug is is where the color bit width conversions and some other odd conversion stuff might be, but i’m not too sure. I really like what we have so far though. Thank you for your hard work.

[tslmy]

it still doesn’t work for 16 bit color and ZB_MODE_R5G6B5

Hmm, so, you see, "R5G6B5" literally means "red 5 bits + green 6 bits + blue 5 bits". That's 16 bits already, so there's no more bit positions to store an alpha channel. You'd have to use an alternative format, perhaps ARGB4444, which squeezes some bits out of the RGB channels to make space for the alpha channel.

I searched in the codebase for ARGB4444, and I had just realized that TinyGL only supported one color format (RGB565) for 16-bit mode.

tinygl/README.md

Line 181 in c2e4859

#define TGL_FEATURE_16_BITS 0 /* 5R6G5B format */

I can think of 2 ways of doing this:

1. Start supporting alternative color formats, or
2. Send a separate "alpha" variable along with the pixel data everywhere

Option 1 seems to be a major design philosophy shift, as TinyGL was supposed to be, well, tiny. Option 2 is a very ugly hack that I have never seen any graphics code did.

At this point, I'd encourage you to explore alternatives to the TinyGL library. I mean, I can literally give you a branch of TinyGL with one of the options above vibe-coded and help you get what you want, but I doubt you would like it.

[XanCraft21]

I mean the alpha channel stuff works perfectly fine for regular triangles with texturing disabled while still using a 16 bit setup. I am wondering if some code from the plain triangle drawing algorithm could be copied into the textured drawing code, but i’m not sure how possible that is.

There are some rgb mixing functions in zbuffer h and cpp files iirc, maybe i can tinker with those myself and see what happens.

Sorry if it seems like i’m giving you a hard time with this, i don’t mean to do that. I can always use polygon stipple and a dithering algorithm to achieve what i am looking for. I don’t want to make you do too much work, but thank you for what you have done so far.

In the worst case scenario i have been writing my own renderer with working alpha blending, but it’s not like tinygl, and the triangle rasterizer is a bit slower than the one used in tinygl. I will need to see how things go over time.

[tslmy]

No it's not too much at all. It's an interesting problem to solve. I happen to have managed to add alpha support for 32bit, and I am really eager to see how far it is generalizable to 16bit mode. So far that's what I can think of; I'll be keen to hear from you later about how you achieve a satisfactory solution later.

[XanCraft21]

I am not able to make it work how i picture it myself, so i will see what else you can do. I have another idea to get 16 bit alpha textures working, there is a function in zgl.h and image_util.c called gl_convertRGBA_to_8A8R8G8B. What if we make a function called gl_convertRGBA_to_5R6G5B? Just a random idea that may or may not work. Are you able to implement this on your side?

[tslmy]

I must be missing some point from your message... How would [...]to_5R6G5B give us alpha? The moment you convert RGBA to RGB565, we lose transparency, don't we?

[XanCraft21]

Sorry for the late reply, i didn’t get your reply until last week, like it got delayed or something, and i was a big busy.

Sorry if my last message was hard to understand, i was basically trying to say what if we just fake it with some extra math?

I have been working on my own 3D renderer and i managed to get textured alpha working perfectly fine with 16 bit 5r6g5b color. All i really did was split the color up into 3 separate channels and did some simple multiplication with the color and alpha values, then put the channels back together, a bit of fakery was my plan. I am currently working on interpolating the alpha across the 3 triangle points, and so far it’s working good.

I am wondering if we could do something similar with this library by splitting the colors apart, doing the alpha transparency math, then merge them back together. Although since this library works mostly in the rgb888 or rgba8888 style setup with optional 16 bit color, and alpha transparency is already working for solid color or vertex color untextured triangles in 16 bit, then something different might need to be done to the textured triangles, which might not even require splitting the colors apart at all. It’s just an idea, and it might not work fully. But in my mind it is definitely possible to achieve alpha transparent textures in 16 bit if the right math was done. I’m not an expert in the required math so i can’t really give any good hints, but i have a lot of faith in this project and i hope to achieve our goal in the end.

[tslmy]

splitting the colors apart

I think that's what I meant earlier by

Send a separate "alpha" variable along with the pixel data everywhere

I vibe-coded an implementation for this idea: tslmy@61b0f00

Is this what you had in mind? Does it meet your needs?