[question/bug] OpenGL 2.1 support? #18191
Comments
|
Yes, sorry. That's the file I meant. Even with |
|
The error message is the result of SDL_CreateWindow call failing using only a few common looking SDL GL attributes (set double buffer, set 1 byte for each rgba, set gl version major minor). Perhaps because it tries to create a hidden Window? (SDL_WINDOW_HIDDEN) |
|
Possibly related to #18061. |
|
Can you please test the appimages from https://github.com/pchote/OpenRA/releases/tag/release-20200503-graphicstest1 ? |
|
I'll do that later today |
|
Ok, tried that and this is the result: And .openra/Logs/graphics.log: |
|
And it still works on my OpenGL 3.3 machine. |
|
Ubuntu 20.04 20200503-release - works fine |
|
I just tested with release-20200503 and it works fine! Great! @ingvar-lynn Is |
It's a new launch/config option. From #18061:
|
|
Nice, thanks @bggardner! |
|
Please be aware that the It feels bad to tell people that their computers are no longer welcome to play OpenRA, but this change has been a long time coming. Working around the missing features in GL2.1 has become a major road block to improving the performance and maintainability of our rendering code. This is really important for the Tiberian Sun and C&C Remastered projects, where poor rendering performance is one of the main issues left to solve before a public release. |
|
@pchote I don't want to hijack this thread with the discussion, but could you post some rationale for dropping OpenGL 2.1 support, maybe on the wiki or a new issue to collect comments? Would it make sense to fork before the Remastered release? |
|
In short: GL2.1 has limited support for textures (no texture arrays, can't even query texture size in the shader) and no support at all for non-floating point types. This forces us to maintain an extra layer of manual book-keeping to e.g. split the rendering up into multiple passes that each use no more than 7 textures at a time, emulate our own bitwise operations using floating point maths, and have if-else checks all through the code for GL2 vs modern GL. This adds a lot of overhead in both code complexity and performance. It also means that we have to maintain our own low-level code full of "if gl2 do X else do Y" instead of leveraging a project like veldrid or ANGLE to be able to write code once and rely on the work of GPU experts to translate that to the lower level system APIs in the way that gives best performance and least bugs. |
|
Thanks, that was very helpful. I'd be curious as to the percentage of users still relying on GL2.1 (do you collect hardware data?). It does seem silly to require "newer" hardware for such an "old" game (I know, I know...it's been updated, remastered, etc.). So, how much of a pain would it be to maintain a GL2.1-only branch (get rid of all the if-elses, but keep all the clever render-splitting magic)? I realize older releases can run on GL2.1, but that would prevent multiplayer with the newer releases. Side note: The game performs much better on my GL2.1 machine than an RPi 4 B+, so that's not (yet) a better solution than upgrading to a "newer" video card (GeForce 210 on eBay for ~$20). Also, I imagine many GL2.1 users are on laptops (for which OpenRA is probably the only reason they use the laptop) where upgrading the GPU is not an option. |
More of a pain than keeping the if-elses, I'm fairly sure. It wouldn't really reduce the amount of code to maintain, while doubling the branches we'd have to keep up-to-date.
We're primarily working towards TS nowadays (and support for RA2 and comparable 3rd-party mods), worst-case continuing to support 2.1 would mean continuing to block render performance improvements and additional render effects required for those to look like they're supposed to and run well enough on slower (but OGL 3[+] compatible) hardware. |
|
I plan to respond with some real numbers once I have time to look them up, but in the short term you shouldn't need to worry too much. As things currently stand, I expect that the 2.1 support (gated behind The real breaking change will come if/when we decide to replace the OpenGL bindings completely with a higher level third party library. |
|
For what it's worth, the PinePhone as a rather new device seems to be one of the likely best selling Linux phones right now and sadly only does OpenGL ES 2.x. With support for external screens and peripherals, it might otherwise be an interesting device to try to play OpenRA on. (Although I imagine it might be plenty laggy...) There is however a PinePhone Pro being worked on with ES 3, but it's pricier (so some people won't get it, especially since I think the base PinePhone will continue to be sold) and as far as I know not as ready on the software side either, at least as of right now. |
|
#21143 has deprecated all versions of OpenGL lower than 3.0 |
System Information
Exception log
graphics.log
Additional information
I've searched through the issues and PRs and from what I understand, this release changed the default renderer to OpenGL 3.0. I also found lots of PRs that said OpenGL 2.1 is replaced by 3.0. #17969 says that OpenGL 2.1 will still work (I assume the used OpenGL version is selected with the OpenGL profile setting under video settings). Yet even if I edit
config.yamlby addingGLProfile: Legacyto theGraphics:section, the game still refuses to launch. I'm also attaching the output ofglxinfo. The newest OGL supported by my GPU is 2.1. Previous release worked fine. If 2.1 is still supported with the Legacy OGL profile I think it's a bug in OGL version detection.I would suggest adding something along the lines of minimum requirements. I know it's difficult to estimate requirements of a game that still has such big changes from release to release but at least tell us what OGL version is required. If there are min. requirements somewhere, I couldn't find them.
glxinfo
The text was updated successfully, but these errors were encountered: