Residual fails to start games with 'Could not initialize video' error

[Ezekiel000]

I build the latest residual on Debian Wheezy/Testing amd64 with official nvidia drivers. It opens fine but when I try to run any games it crashes and leaves this on the terminal: WARNING: SDL mixer output buffer size: 1024 differs from desired: 2048! User picked target 'grim' (gameid 'grim')... Looking for a plugin supporting this gameid... Grim Engine Starting 'Grim Fandango' WARNING: Couldn't create 32-bit visual, trying 16-bit! Could not initialize video: Couldn't find matching GLX visual!

I don't think anything has changed on my system (gfx drivers etc) since Residual last worked, unfortunately I can't remember when that was.

[somaen]

tried with softrenderer?

[Ezekiel000]

softrenderer works fine. Is there anything I can do to get more detailed information from my system to find out why it doesn't work?

[Ezekiel000]

I did a regression test from August 2011 to present to try and find what cause residual hardware rendering to stop working on my system. The result of my regression testing is that this commit is the problem: 56208e0ca03e8f9d127bc7891bdc8f0f886d6469 is the first bad commit commit 56208e0ca03e8f9d127bc7891bdc8f0f886d6469 Author: Robert Biro darthjdg@gmail.com Date: Sat Oct 8 01:14:41 2011 +0100

SDL: Added antialiasing support.

:040000 040000 c562b549c3ef92fd8266613523982772676c61c4 d0f4e67f2ea81ab7369f007aded3e3d16ef8ba4e M backends

After I found the commit that was the problem I built residual without that commit using: git show 56208e0ca03e8f9d127bc7891bdc8f0f886d6469 | patch -p1 -R

And it ran fine in hardware rendering.

[Ezekiel000]

I found that if I had soft_renderer=false in .residualrc under [grim] but no antialiasing=# or antialiasing=8 or above then residual will fail to run grim. I think to fix this residual needs to either:

• add the line antialiasing=0 to .residualrc if it doesn't exist before trying to load an engine.
• assume if it doesn't exist in .residualrc then antialiasing=0

Also if antialiasing is set in .residualrc but residual fails to initialize video (because it's set too high for the hardware) then residual should try lower values rather than crash.

[DarthJDG]

That is exactly what I was afraid of when added the simple antialiasing support, reaction to invalid modes is heavily OpenGL implementation dependant, and there isn't really a quick and easy cross-platform way to detect available antialiasing modes. The only way to do it is to create a dummy OpenGL context without antialiasing, enumerate valid pixelformats then re-create the context with antialiasing if it's available.

A quicker, easier and more cross-platform solution would be to try initialising the 32 bit video with antialiasing if it's set, if it fails try 32 bits without AA, then fall back onto the 16 bit modes.

One interesting thing though... can you confirm the it actually crashes without ever mentioning antialiasing in the config file? If that's the case, maybe someone with more insight on the inner workings of the engine can explain how it gets through this line:

if (ConfMan.hasKey("antialiasing") && ConfMan.getInt("antialiasing")) {

The whole commit is really just a couple of lines guarded by the above.

[Ezekiel000]

Sorry I was wrong in my previous test, I hadn't noticed that I had antialiasing=8 under the residual main section. So the actual test results are: no antialiasing line in the config - works fine. antialiasing=0 - works fine. antialiasing=2 - works fine. antialiasing=4 - works fine. antialiasing=8 - crash with the error above. antialiasing=16 - crash with the error above.

So really this bug report is purely that residual shouldn't crash if antialiasing is set too high.

[DarthJDG]

Just for the record, can I ask what it does if you put a non-power-of-two in there, like 1 or 3? Does it crash? If it doesn't, is there any antialiasing applied?

[Ezekiel000]

I tested it with both antialiasing set to 1 and 3 and it worked fine and antialiasing was applied. I did these tests on a build before the fix above was applied. I didn't think you could have antialiasing of odd numbers.

[DarthJDG]

Thanks. My guess would be that if you put odd numbers on, it would just pick the closest available mode, but the OpenGL driver just fails for too high values.

Hmm... sorry about that, that fix is still WIP, I didn't know it shows up in the main repo if the commit message references it in my private repo without a pull request. That is weird indeed, I'll keep this in mind in the future.

I deleted the branch, but that commit is still there. Do you know if there's any way to get rid of it. I'm still quite new to GitHub as you can tell. ;)

Edit: Ok, I give up, that commit is still around, even after deleting my repo, I guess I'll just have to live with it...

[DarthJDG]

Can you please try a build with the above fix and see if it properly falls back to using no antialiasing instead of crashing if you put in a value too high?

[Ezekiel000]

It works, it turned off antialiasing when I set it too high. Wouldn't it be better to try a lower antialiasing setting than just turn it off straight away?

[DarthJDG]

Yes, I'm planning to add that feature, but it's good to know that the failover works as expected. Although there might be a bit of a problem, on my Windows machine it automatically switches off for high values and returns success.