RFC: OpenGL x11drv rewrite (WoW fix)

[Roderick Colenbrander]

Hi,

Since the WM rewrite we can only use the visual which was created by x11drv at x11drv initialization. In general this is a simple 32bit RGBA visual or when that's not available it is some 16bit visual.

The problem is that the opengl code advertises more formats than this single format. The problem which this can cause is that a 'bad' format is set by SetPixelFormat. In the end when we create a context using wglCreateContext this 'bad' pixelformat is used. When some time later glXMakeCurrent is called we will get a BadMatch. (Note that in a few cases we catch the 'BadMatch' before it happens and create a new GLX Context; this is when context is NULL)

The proposed patch which I attached to this email rewrites the pixel format code. First I'll give a short introduction and then I will explain my changes.

The functions ChoosePixelFormat/GetPixelFormat/SetPixelFormat/DescribePixelFormat
all work with a parameter 'iPixelFormat'. This variable is an index into the table of supported pixel formats. At the moment the index is a direct mapping to the FB config table exported by GLX.

I have changed ChoosePixelFormat to only return the format of the main visual. Further this function needs to find a 'closest match' to the requested format, before it tried to find an exact match. I changed the function to look for a close match. Further because only 1 format is supported, the max index the function can return is 1. This kills the direct mapping of the index to the index in the GLX FB config table.

All the opengl calls in x11drv got changed to only accept our single format. As I mentioned earlier the opengl calls used the specified iPixelFormat as an index in the GLX FB config table. Because the 1:1 mapping of iPixelFormat to this table got lost I have added a function to retrieve the index of the main visual.

Further I had to change our wglMakeCurrent call to retrieve the pixel format to use from the main visual instead of getting it from a GetPixelFormat call. This was done because wglMakeCurrent needs an index into the GLX FB Config table and not in our 'win32 opengl format table' (which only contains 1 format).

I have tested the patch in several programs. Before Halflife1 didn't work in 16bit because ChoosePixelFormat was too strict, the game works fine now. Further the patch also fixes the BadMatch error Nvidia users received in World Of Warcraft when using the OpenGL renderer.

I think the patch is a correct fix for the BadMatch / ChoosePixelFormat issues. The patch isn't 100% complete yet as I haven't updated the WGL extensions for pbuffer and wglChoosePixelFormat to work with the new pixelformats yet (that's why you see a line WoW hack). I will fix that part when you guys think that the patch is correct.

Regards,
Roderick Colenbrander

[Stefan Dösinger]

Hi,
> I think the patch is a correct fix for the BadMatch / ChoosePixelFormat
> issues. The patch isn't 100% complete yet as I haven't updated the WGL
> extensions for pbuffer and wglChoosePixelFormat to work with the new
> pixelformats yet (that's why you see a line WoW hack). I will fix that part
> when you guys think that the patch is correct.

I can't speak about the technical aspects, but placing wgl commands into 
x11drv sounds like a good idea if we want better platform independence. We 
will need it if we want to port wine 'properly' to macos(without an x server) 
or any other os which does not have x servers.