search

renpy / pygame_sdl2

Reimplementation of portions of the pygame API using SDL2.
GNU Lesser General Public License v2.1
326 stars 64 forks source link

'error: GLX is not supported' creating software window on Linux #63

Closed SpikyCaterpillar closed 7 years ago

SpikyCaterpillar commented 7 years ago

src/pygame_sdl2/display.pyx unconditionally adds the SDL_WINDOW_OPENGL flag to SDL_CreateWindow, so pygame_sdl2 programs won't start at all on a Linux system unless OpenGL is working. (Seen breaking things in the wild on a newly-installed Debian machine with a minimalist package set.)

It looks to me from the rest of display.pyx like the SDL_WINDOW_OPENGL flag is meant to be optional - Pygame doesn't actually set up GL contexts unless SDL_WINDOW_OPENGL is set by the caller. Is there any particular reason for all windows to be GL windows? (I'm guessing it's there to work around highdpi-related breakage on Mac/Win)

mclaughlinconnor commented 7 years ago

Use https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ it comes with all the firmwares pre-installed, so it shouldn't break. Hopefully

SpikyCaterpillar commented 7 years ago

My goal here isn't to install GL on one machine; my goal is to write a clean patch so games can run on pygame_sdl2 without requiring all the players everywhere to install GL. (Not everyone wants closed source code in kernel mode, for one thing, and for another a driver upgrade is a great way to wind up breaking unrelated software which may be important to the player.)

I've already got a fix for my own games, but the fix is messy and cleaning it up enough to submit would go better if I actually knew WHY Pygame was doing it this way in the first place.

mclaughlinconnor commented 7 years ago

Ah, sorry.

renpytom commented 7 years ago

The reason is that display.set_mode can switch a window between GL and software modes without having to close and re-open the window. I believe it is also helpful on Window to ensure a DirectX-compatible window is created, at least in practice.

There are open source software GL drivers available for Linux, so I think the right answer is for users to support that. It's 2017, and OpenGL is now a standard part of the Linux graphics stack, so I think it's weird to actively eliminate dependencies on it. I'd be fine with merging in code that uses a hint (something like PYGAME_AVOID_GL) that would turn this off by default, though.

I have systems without libX11 installed, but I don't expect to play games on them. I'm not sure libGL is very different than libX11 in that respect.

SpikyCaterpillar commented 7 years ago

Ah, that makes sense. I've put a pull req in and will be testing the code in production on my end for a while (at least in Linux; I don't have a build chain setup for compiling python modules on Win/Mac at the moment).

In my experience software GL usually wound up being significantly slower than direct software rendering, even on programs that appear to be using a flat matrix - not sure why, since I'd think flat projections should optimize well. Haven't poked at it lately, though, maybe it's improved recently.