Well, it’s been a heck of a time for the last two weeks for the studio. We’ve had hard drive issues, OS failures, backup failures, backup struggles, corrupted data, corrupted drives, video card failure, and then of course the pandemic which makes replacing vital hardware difficult.
On top of all that it’s, It’s back to school time in the states, so there’s a glut of folks trying to sort out computer issues so all the kids who are virtual schooling have what they need. Then you have the issues that large chunks of our country and more locally our state are now in month 6 of the lockdown (Ohio is sort of open for certain essential services, and business) again but most folks are being encouraged to stay home. Of cource if anyone on your staff has chronic health issues, they really have to stay quarantined until the vaccines are possible. So the work from home market and computer needs have caused prices for second-hand equipment on eBay to go through the roof.
All that being said we managed to cobble together a working desktop temporarily using onboard graphics, then we did what we could to repair the failing drive, and scripted some backup rsync scripts to retrieve as much data as we could. Once that was complete we swapped some drives around and then installed the new OS, and reinstalled and updated all the software.
So some informaiton on what we are working with.
hp-pc:~/$ inxi -c 6
CPU: Dual Core Intel Core2 Duo E8400 (-MCP-) speed/min/max: 2065/1998/3000 MHz Kernel: 5.4.0-42-lowlatency x86_64 Up: 11h 38m
Mem: 3737.3/15885.4 MiB (23.5%) Storage: 931.51 GiB (2.2% used) Procs: 261 Shell: bash 5.0.17 inxi: 3.0.38
hp-pc:~/$ inxi -b
System: Host: kls-hp-pc Kernel: 5.4.0-42-lowlatency x86_64 bits: 64 Desktop: Cinnamon 4.4.8
Distro: Ubuntu 20.04.1 LTS (Focal Fossa)
Machine: Type: Desktop System: Hewlett-Packard product: HP Compaq 8000 Elite CMT PC v: N/A serial: <superuser/root required>
Mobo: Hewlett-Packard model: 3647h serial: <superuser/root required> BIOS: Hewlett-Packard v: 786G7 v01.04
date: 03/04/2010
CPU: Dual Core: Intel Core2 Duo E8400 type: MCP speed: 2312 MHz min/max: 1998/3000 MHz
Graphics: Device-1: Intel 4 Series Integrated Graphics driver: i915 v: kernel
Display: x11 server: X.Org 1.20.8 driver: i915 resolution: 1600x900~60Hz, 1600x900~60Hz
OpenGL: renderer: Mesa DRI Intel Q45/Q43 (ELK) v: 2.1 Mesa 20.0.8
Network: Device-1: Intel 82567LM-3 Gigabit Network driver: e1000e
Device-2: Ralink MT7601U Wireless Adapter type: USB driver: mt7601u
Drives: Local Storage: total: 931.51 GiB used: 20.21 GiB (2.2%)
Info: Processes: 262 Uptime: 11h 39m Memory: 15.51 GiB used: 3.68 GiB (23.7%) Shell: bash inxi: 3.0.38
Then having done all that we discovered that there was a problem with GODOT and the onboard video card not being compatible or so we thought.
By default the install had an older version of OpenGL installed. So we upgraded that.
hp-pc:~/$ glxinfo | grep "OpenGL"
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Q45/Q43 (ELK)
OpenGL version string: 2.1 Mesa 20.0.8
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.0.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:
Then we made sure MESA was the most recent version. note: “Mesa 20.0.8”
hp-pc:~/$ glxinfo | grep "Mesa"
client glx vendor string: Mesa Project and SGI
Device: Mesa DRI Intel(R) Q45/Q43 (ELK) (0x2e12)
OpenGL renderer string: Mesa DRI Intel(R) Q45/Q43 (ELK)
OpenGL version string: 2.1 Mesa 20.0.8
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.0.8
Then made sure the old card had the most recent version of its driver, which turns out is i915.
After all that, Godot was still throwing the same error (when compiling and playing the game). I stumbled on bug report and one of the troubleshooting tips was to run GoDot from the command line and to force it to use the different GL versions and see which one was throwing errors. Turns out it was GLES3.
Godot_v3.2.2-stable_x11.64 --video-driver GLES2 --verbose
Godot_v3.2.2-stable_x11.64 --video-driver GLES3 --verbose
We have version 2 and version 3 installed. In another thread, we saw that there is a default file “default_env.tres” in each project directory that contains system-specific information. Since we copied the content from another computer it was likely part of the problem. Renaming that file, and then running the editor and then the game (GUI) or running the game command line solved the issue. It still displays some errors, but the game runs so I can use the engine on this computer.
./Godot_v3.2.2-stable_x11.64 --video-driver GLES2 --verboseRunning: Godot_v3.2.2-stable_x11.64 --path GitHub/IceHockeySolitare --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 24088 --position 300,50
Godot Engine v3.2.2.stable.official - https://godotengine.org
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 28
Current serial number in output stream: 25
X Error of failed request: GLXBadFBConfig
Major opcode of failed request: 152 (GLX)
Minor opcode of failed request: 34 ()
Serial number of failed request: 28
Current serial number in output stream: 25
ERROR: initialize: Condition "ctxErrorOccurred || !p->glx_context" is true. Returned: ERR_UNCONFIGURED
At: platform/x11/context_gl_x11.cpp:190.
ERROR: is_viable: Error initializing GLAD
At: drivers/gles3/rasterizer_gles3.cpp:141.
GLES2 does work with my older hardware.
Godot_v3.2.2-stable_x11.64 --video-driver GLES2 --verbose --path /home/els/Documents/GitHub/IceHockeySolitare
GLES3 did not work. (edit- to fix this happening on accident while working, see “Fallback” settings discussed next.)
Godot_v3.2.2-stable_x11.64 --video-driver GLES3 --verbose --path /home/els/Documents/GitHub/IceHockeySolitare
The error however continued in the GoDot GUI.
The next step was to search the GUI and we found under “Project – >Project Settings -> Rendering -> Quality”
The option to select the Driver. We set this to GLES2 which works for us.
The opton to “Fallback” to GLES2 which when selected, the editor and command line interaction stopped erroring if GLES3 is used.
I happen to be working on a 2D game for my purposes I also set the Framebuffer Allocation to 2D and mobile to 2D without sampling.
That fixed my issues. Good luck!.
Hits: 611