On Mon Sep 22 09:29:28 2025 +0000, Rémi Bernon wrote:
Hmm, so maybe RGB565 would make the trick with alpha bit more difficult. Another option I was thinking about would be to use the FBO-based surface instead of a pbuffer, now that we have it, with a GL_RGB5_A1 renderbuffer.
There's two good reasons to use an RGBA8888 secret buffer (that's what I'm going to be calling the GPU-based buffer from now on): - Support for 16-bit pixel formats is pretty spotty. AMD's open source driver supports rgba5551 and rgb565, Nvidia supports only rgb565 and LLVMpipe does not support any 16-bit pixel formats (only rgba8888 it seems). - Civ 3 actually relies on transparency, although it's subtle. In the screenshot below it's using OpenGL to draw a semi-transparent outline around the settler. Based on that I'm guessing that GDI OpenGL blends its drawings onto the bitmap with full floating point transparency. To support semi-transparent rendering we'll need to preserve the transparency until the secret buffer is drawn onto the bitmap.
<details> <summary>Civilization 3 screenshot</summary>
{width=800 height=600}
</details>
I'll be sure to add a test with transparent rendering to make sure that's actually how GDI OpenGL works.
I'm not sure what you mean by using an FBO-based surface, since we're gonna need a drawable of some kind to bind the OpenGL context (although the drawable could be a 1x1 pbuffer I suppose). In any case GL_RGB5_A1 is not going to work with the semi-transparent line rendering.
I also made a pixel format dumper while working on this. Probably useful to share the print-outs: - [Linux desktop, LLVMpipe, GLX](/uploads/11763ff3ed0d9f48022d5a1b1700a4e7/pf_desktop_llvmpipe) (by far the most restrictive) - [Windows 10 VM, GDI generic, WGL](/uploads/127210e12fea60594423b76b051a4db9/pf_windows_gdigeneric_vm.txt) - [Linux laptop, AMD open source, GLX](/uploads/8de9328ab29f9e0c77e2f8146f4ef6c5/pf_linux_amd_laptop.txt) - [Linux desktop, NVidia, GLX](/uploads/eb7dd6d9ac6febfe78307db966be2181/pf_linux_nvidia.txt)