Issues in OpenGL 16bpp formats support

Hello,

Two years ago I locally fixed some bug with Civilization III game, 
caused by problems with 16bpp format support in OpenGL on joint of Wine 
and Mesa libraries. I described my findings here

https://bugs.winehq.org/show_bug.cgi?id=41930#c60

Now realized that may be bugtracker alone is not enough, and may be 
writing to this e-mail list is better.

I'm wondering if anybody interesting in fixing this issue? I will be 
glad to work with somebody to fix this problem in the main Wine brunch 
(just don't know correct workflow for upstreaming and discussing fixes 
like that).

With best regards,
Vyacheslav Chigrin

[Rémi Bernon]

On 6/20/25 18:45, [e-mail] wrote:
> Hello,
>
> Two years ago I locally fixed some bug with Civilization III game, 
> caused by problems with 16bpp format support in OpenGL on joint of Wine 
> and Mesa libraries. I described my findings here
>
> https://bugs.winehq.org/show_bug.cgi?id=41930#c60
>
> Now realized that may be bugtracker alone is not enough, and may be 
> writing to this e-mail list is better.
>
> I'm wondering if anybody interesting in fixing this issue? I will be 
> glad to work with somebody to fix this problem in the main Wine brunch 
> (just don't know correct workflow for upstreaming and discussing fixes 
> like that).
>
> With best regards,
> Vyacheslav Chigrin

Well that's perfect timing because we've recently dropped OSMesa in 
favor of PBuffer rendering through the GLX/EGL stack.

Turns out that this also broke the game, see 
https://bugs.winehq.org/show_bug.cgi?id=58384, which I was looking into 
earlier, but that should be fixed with 
https://gitlab.winehq.org/wine/wine/-/merge_requests/8384

I think https://gitlab.winehq.org/wine/wine/-/merge_requests/8383 might 
also be useful here.

As far as I can see, with both MR I don't see any terrain turning black 
anymore, because... it turns stripped orange instead (is this progress?).

In short, memory DC are now using the accelerated GL stack to do their 
drawing, with some synchronization points where the bitmap is read into 
the GL front buffer, when a GL context is set current, or the other way 
around from the front buffer to the selected bitmap, when the GL context 
is flushed.

This seems to be how Windows does it too, although we might be missing 
some sync points. It's not entirely clear when the data is being flushed 
in one way or the other on Windows.

We have a couple of tests about it and I would suggest to have a look at 
`test_bitmap_rendering` in `dlls/opengl32/tests/opengl.c`, and maybe see 
if you can reproduce something similar to what the game is doing and 
find behavior differences with Windows.

The pixel formats are enumerated from the Linux GL configs, and it's 
possible that there's some things to tweak there to match what memory 
DCs are supposed to enumerate, but other than that the pbuffer is 
created directly from the pixel format that was selected by the game.

Here too, it should be possible to write tests to compare Windows vs 
Wine, and change our implementation to better match it.

Cheers,