Video mode set failed: Couldn't find matching GLX visual

[thelusiv]

I have the same bug as Joe using your MENU::Load() patch on Gentoo Linux. sdl-config --version reports 1.2.8. I just upgraded to 1.2.9, I get the same problem.Not every screen mode is listed multiple times for me. Here's what I get:[QUOTE BY=VDrift screen mode listing]1280x10241280x9601024x7681024x7681024x768832x624800x600800x600800x600800x600640x512640x480640x480640x480640x480512x384512x384512x384416x312400x300400x300400x300400x300320x240320x240320x240[/QUOTE]

[abs1nth]

but you DO get all modes even when running in a window?maybe we could combine the dynamic list we get from SDL_ListModes, (stripping duplicates) with the list currently used (the supported ones from the videomodes file)...

[thelusiv]

Yes, I seem to get all the modes, plus some strange dupes. It seems to me like those dupes probably have a purpose, like perhaps there are different refresh rates or color depths available at each mode.It probably would make sense to look at the different sources of video mode lists - SDL, and our text file - and cut out any dupes. As long as we are using the text file, though, we limit users to the modes listed there. If someone has a funky-sized widescreen monitor we will not have their resolution unless they add it themselves. So perhaps we need to figure out exactly what is causing these duplicates and deal with that.

[joevenzon]

Okay, let's combine both approaches and use the text file (minus unsupported modes if in fullscreen mode) plus any modes the SDL stuff turns up. You up for doing that, abs1nth?An easy way to strip out duplicates would be to use built-in STL container functions.

[abs1nth]

yes i will do it

[abs1nth]

yes i will do it

commited.please test if i broke something.

[abs1nth]

btw.: atop MENU::Load() are about 50 lines of code to handle the case that this method is called more than once (which it is). why do we even call this method more than once, and why don't we just return on subsequent calls instead of working around crashes? replacing all this code by:if (loaded) return;works fine here....

[joevenzon]

In windows, a resolution change invalidates all of your opengl data, so you need to re-load it all again. Also, if you change your texture size, you need to unload and re-load your opengl textures. After a resolution change or texture size change, a bunch of Load functions get re-called (such as Menu.Load). Menu::Load() is written as it is to automatically unload and reload any resources that are already loaded. Another way to do this would have been to write a ReLoad function, but since it'd share a lot of code with Load anyway, it made more sense to just make Load smart enough to handle all situations.

[abs1nth]

In windows, a resolution change invalidates all of your opengl data, so you need to re-load it all again. Also, if you change your texture size, you need to unload and re-load your opengl textures. After a resolution change or texture size change, a bunch of Load functions get re-called (such as Menu.Load). Menu::Load() is written as it is to automatically unload and reload any resources that are already loaded. Another way to do this would have been to write a ReLoad function, but since it'd share a lot of code with Load anyway, it made more sense to just make Load smart enough to handle all situations.

ok thanks :wink:but even when just starting up vdrift this method is called twice, obviously without a resolution change involved....one of this surely must be superflicious?

[joevenzon]

Currently, when you start up the game, it sets the display mode to whatever's in your config file... in doing so, the resolution change results in the Menu::Load function getting called. Later on, the game does a bunch of loading (including loading the menu) which is why you're seeing it getting called twice. I've fixed this in SVN (the first resolution change won't reload anything, now).

[joevenzon]

Also, your resolution sizing code is working great for me.