+1

+10

+1

Ich habe diesen Code in context_gl_win.cpp geschrieben, aber er stürzt im Allgemeinen aufgrund von ab
Einige nicht implementierte Funktionen in Windows aufgrund eines beschissenen Treibers
Ich wünschte, ich könnte genau herausfinden, warum

Am Samstag, den 17. Januar 2015 um 14:56 Uhr schrieb MSC [email protected] :

+1

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/okamstudio/godot/issues/1162#issuecomment -70376758.

Setzen Sie dies vorerst auf eine so hohe Priorität, wie es eine sehr nützliche Funktion wäre. Wir erhalten unzählige Berichte über Abstürze aufgrund von Leuten mit sehr alten Intel IGPs oder was auch immer, die GLES2 nicht unterstützen.

Ok, ich glaube, ich habe genug Abstürze angegeben, um meine oben genannten "Tonnen" zu unterstreichen. Ich werde aufhören, in den Archiven zu stöbern: D.

+1 Warum funktioniert Godot auf magische Weise unter Ubuntu, aber nicht unter Windows?

Irgendeine Idee, wie dies @reduz implementiert werden könnte?

Ich habe diesen Code in context_gl_win.cpp geschrieben, aber er stürzt im Allgemeinen aufgrund einer nicht implementierten Funktion in Windows ab

Warum dann nicht die dynamische Verknüpfung verwenden? Es wird offensichtlich sein, welche Funktion fehlt. Ich glaube, dass https://github.com/p3/regal dies tut.

Ich habe bereits erkannt und versucht, eine Nachricht anzuzeigen, aber es scheint
immer noch nicht funktionieren.
Da ich keine nicht unterstützte Hardware habe, kann ich nicht verstehen, warum sie abstürzt und
kann es also nicht reparieren.
PRs willkommen.

Am Dienstag, den 2. Februar 2016 um 12:11 Uhr, anatoly techtonik < [email protected]

schrieb:

Ich habe diesen Code in context_gl_win.cpp geschrieben, aber er stürzt im Allgemeinen aufgrund von ab
einige nicht implementierte Funktion in Windows

Warum dann nicht die dynamische Verknüpfung verwenden? Es wird offensichtlich sein, welche Funktion es ist
fehlt. Ich glaube, dass https://github.com/p3/regal dies tut.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -178624438.

Wenn jemand mit einer alten GPU versuchen könnte, Godot unter Linux über gdb auszuführen, könnte dies sehr hilfreich sein. Die Windows-Debug-Informationen zur "Problemsignatur" scheinen ziemlich sinnlos zu sein: /

Ich mache überhaupt kein C ++. Nur Python, also bin ich ein Benutzer. Sagen Sie mir, was ich ausführen soll, und ich kann die Informationen erhalten.

Sagen Sie mir, was ich ausführen soll, und ich kann die Informationen erhalten.

Ich habe keine Ahnung, wie man Sachen unter einem Debugger unter Windows ausführt, aber ich denke, es ist nicht trivial für Leute, die nicht viel Erfahrung mit dem Kompilieren von Sachen unter Windows haben. Aus diesem Grund habe ich jemandem vorgeschlagen, das Debuggen mit GDB unter Linux zu versuchen, da es sehr einfach zu verwenden ist:

$ gdb /path/to/godot/binary // if possible self-compiled in debug mode, to have more info
-> run
// see that it segfaults in the terminal
-> bt

und kopieren Sie die Ausgabe dieses Befehls bt (backtrace) in diesen Fehlerbericht.

Natürlich könnte es sein, dass das Problem Windows-spezifisch ist, so dass das Debuggen unter Linux sinnlos wäre, aber ich glaube, dass Linux-Benutzer auch Fehler hatten, die nicht abgefangen wurden, um dem Benutzer mitzuteilen, dass ihre Hardware OpenGL (ES) 2.1 nicht unterstützt.

Beta 2.0 kann unter Linux nicht ausgeführt werden, scheint jedoch nichts mit der Grafikkarte # 3557 zu tun zu haben

Hehe, du hast Glück, dass du auf alle bekannten Probleme stößt, die wir in Eckfällen haben :)

Ich glaube, ich habe nur ein "klagendes Talent" und einen GitHub-Account. =)

Ich weiß nichts über solche alten Videokarten, die beim Start abstürzen, aber zum Beispiel auf NVIDIA 6800 GT,
es stürzt nur bei wenigen Projekten ab. Es gibt also eine cmd-Ausgabe über Framebuffer-Fehler in allen Projekten und Godot-Modulen. Sie kann vollständig behoben werden, indem Sie die Einstellung "fp16_framebuffer" in den Projekt-Rasterizer-Einstellungen deaktivieren. Ich weiß, dass auf denselben Videokarten (ich weiß nichts über die vollständige Verbindung) falsches Rastering (keine Texturen) vorliegt, was durch Deaktivieren der Einstellung "fragment_lighting" vollständig behoben werden kann.
Ich denke, Godot sollte prüfen, ob diese Funktionen unterstützt werden, und wenn nicht, den Benutzer notieren und deaktivieren.
Vielleicht hilft es auch beim Absturz beim Start.

Sagen Sie mir, was ich ausführen soll, und ich kann die Informationen erhalten.

$ gdb / path / to / godot / binary // wenn möglich im Debug-Modus selbst kompiliert, um weitere Informationen zu erhalten

Godot_v2.0_beta_20160205_x11.64 stürzt auf Fedora 23 nicht mit derselben Hardware ab. Es wird dort als Mobile Intel® GM45 Express Chipset erkannt.

Godot_v2.0_beta_20160205_win32.exe stürzt unter Vista 32 immer noch ab.

@techtonik Ich denke, der Grund dafür ist, dass Linux im Gegensatz zu Windows die Software-Realisierung für OpenGL verwendet, wenn es Probleme mit der Hardware OpenGL gibt, aber es ist natürlich langsamer als die Hardware.

@ Algrin6 Es wäre schön, wenn die Engine nur etwas Transparenz in diese Tatsache bringen könnte. In alten Zeiten wurden Spiele wie Baldur's Gate mit Grafik-Test-Binärdateien ausgeliefert. http://www.fileplanet.com/13582/download/Baldur's-Gate-Graphics-Test

BIOWARE VIDEO DRIVER TEST

PURPOSE
-------
This program tests each of the DirectDraw calls used in the full version of Baldur's
Gate.  The program uses 640x480 mode with 16-bit color, which has proved to be 
problematic with some video drivers.

REQUIREMENTS
------------
This program requires a video card with 2 MB of memory.  This program also expects
to see DirectX 3.01a or greater on your system.
...

2 MB Speicher! Und jetzt habe ich 3 GB + 3 GHz und kann keine Game Engine ausführen. Woher?

2 MB Speicher! Und jetzt habe ich 3 GB + 3 GHz und kann keine Game Engine ausführen. Woher?

Weil wir im Jahr 2016 sind und der Bioware-Motor super alt ist? Und dieser Test wurde entwickelt, um zu überprüfen, ob der Grafiktreiber leistungsfähig genug ist. Daher funktionierte der Test wahrscheinlich ab DirectX 3.01a, sagte aber möglicherweise "Aktualisieren Sie Ihre Hardware oder Treiber", wenn Sie unter DirectX 7 oder so waren. Und die Bioware-Engine funktionierte ausschließlich unter MS Windows <= XP, während Godot auf einem Dutzend Plattformen funktioniert ...

Da Sie nun genau zu wissen scheinen, was wir tun müssen, stellen Sie bitte eine Pull-Anfrage.

@techtonik Hauptproblem dabei ist, dass keiner der Kernentwickler alte Hardware hat, um das Problem zu testen. Sie müssen also entweder Debug-Informationen bereitstellen, um die Ursache des Problems zu ermitteln, oder es selbst beheben (was das Schöne an Open Source ist).

Baldurs Tor ist nicht in einer Allzweck-2D / 3D-Spiel-Engine programmiert.
Es ist maßgeschneidert und in C, x86 Assembler, wahrscheinlich Watcom, programmiert
Compiler, geschützter Modus und verwendet eine grundlegende Stapelmaschine für die Skripterstellung. Ebenfalls
Fühlen Sie sich frei, den gesamten benutzerdefinierten Blitting-Code selbst zu erstellen.

Am Sonntag, den 7. Februar 2016 um 12:36 Uhr, benachrichtigt George [email protected]
schrieb:

@techtonik https://github.com/techtonik Hauptproblem dabei ist
dass keiner der Kernentwickler über alte Hardware verfügt, um das Problem zu testen. Damit
Sie müssen entweder Debug-Informationen bereitstellen, um die Ursache des Problems zu ermitteln, oder
Repariere es selbst (was das Schöne an Open Source ist).

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -181034018.

@reduz Kann Godot eine "Plattformkompatibilitätstabelle" für den Code erstellen, der von der Engine (oder vom Editor) erstellt wurde und alle Funktionen auflistet, die das Spiel derzeit verwendet (Blitting, Partikel, 3D-Objekte, ...)?

Wenn das momentan nicht möglich ist, ist das zumindest technisch machbar?

Der Anwendungsfall für die Validierung besteht darin, ein minimales Spiel (Test) erstellen zu können, das auf jedem Blitting-Gerät ausgeführt werden kann, und die Leistung zu messen.

@reduz Was ist mit https://github.com/godotengine/godot/issues/1162#issuecomment -180466018?

@ Algrin6 Es ist sinnlos zu überprüfen, ob dieses Zeug in älteren Versionen von OpenGL unterstützt wird. Diese GPUs haben Treiber, die OpenGL mitteilen, dass alles unterstützt wird, und dann in eine Art bizarren Software-Fallback gehen, der langsam ist, einfriert oder abstürzt.

Ich möchte lieber so tun, als ob solche alte Hardware nicht existiert und vom Planeten gefallen ist.

Ich denke, das bedeutet "Patches sind willkommen". Ich bezweifle wirklich, dass jemand dies ablehnen wird
gut gemachte Unterstützung für
ältere Plattform.

Am Do, 11. Februar 2016, um 03:41 Uhr, Juan Linietsky [email protected]
schrieb:

@ Algrin6 https://github.com/Algrin6 Es ist sinnlos zu überprüfen, ob das so ist
Sachen werden in älteren Versionen von OpenGL unterstützt. Diese GPUs haben Treiber
die OpenGL mitteilen, dass alles unterstützt wird, und dann in eine Art gehen
bizarrer Software-Fallback, der langsam ist, einfriert oder abstürzt.

Ich möchte lieber so tun, als ob solche alte Hardware nicht existiert und gefallen ist
vom Planeten.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216.

Ich warte immer noch darauf, dass jemand mit einem alten Chipsatz einen besseren Beitrag leistet
Erkennung nicht unterstützter Hardware. Ich habe seitdem keine Hardware mehr
ein Jahrzehnt, also kann ich nicht viel tun.

Am Mittwoch, den 10. Februar 2016 um 23:30 Uhr, Sergey Lapin [email protected]
schrieb:

Ich denke, das bedeutet "Patches sind willkommen". Ich bezweifle wirklich, dass jemand dies ablehnen wird
gut gemachte Unterstützung für
ältere Plattform.

Am Do, 11. Februar 2016, um 03:41 Uhr, Juan Linietsky [email protected]
schrieb:

@ Algrin6 https://github.com/Algrin6 Es ist sinnlos zu überprüfen, ob das so ist
Sachen werden in älteren Versionen von OpenGL unterstützt. Diese GPUs haben Treiber
die OpenGL mitteilen, dass alles unterstützt wird, und dann in eine Art gehen
bizarrer Software-Fallback, der langsam ist, einfriert oder abstürzt.

Ich möchte lieber so tun, als ob solche alte Hardware nicht existiert und gefallen ist
vom Planeten.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
< https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389.

Ich habe Zugang zum Speichern mit PCs von 80 bis Anfang 2000, wenn das hilft,
Aber ich brauche einige Details zum Testen und Debuggen, da ich es nicht bin
Windows-Entwickler in keiner Weise und haben keine Ideen zu Tools, etc.
Haben Sie einen Satz i740s mit win95se2-Boxen, einige sogar Pentim233MMX.
Aus buchhalterischen Gründen wird dies erst 2025 weggeworfen.

Übrigens, Juan, kannst du mich per E-Mail kontaktieren, damit ich deine persönliche Adresse habe?
Bombardiert es nicht mit irgendetwas Dummem.

Am Do, 11. Februar 2016, um 05:48 Uhr, Juan Linietsky [email protected]
schrieb:

Ich warte immer noch darauf, dass jemand mit einem alten Chipsatz einen besseren Beitrag leistet
Erkennung nicht unterstützter Hardware. Ich habe seitdem keine Hardware mehr
ein Jahrzehnt, also kann ich nicht viel tun.

Am Mittwoch, den 10. Februar 2016 um 23:30 Uhr, Sergey Lapin [email protected]
schrieb:

Ich denke, das bedeutet "Patches sind willkommen". Ich bezweifle wirklich, dass es jemand tun wird
ablehnen
gut gemachte Unterstützung für
ältere Plattform.

Am Do, 11. Februar 2016, um 03:41 Uhr, Juan Linietsky <
[email protected]>
schrieb:

@ Algrin6 https://github.com/Algrin6 Es ist sinnlos zu überprüfen, ob das so ist
Sachen werden in älteren Versionen von OpenGL unterstützt. Diese GPUs haben Treiber
die OpenGL mitteilen, dass alles unterstützt wird, und dann in eine Art gehen
von
bizarrer Software-Fallback, der langsam ist, einfriert oder abstürzt.

Ich möchte lieber so tun, als ob solche alte Hardware nicht existiert und existiert
gefallen
vom Planeten.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
< https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -182678470.

Sie müssen nicht weiter zurück gehen. Nur Intel Series 3/4 oder i940 ist
genug, um es zum Absturz zu bringen ...
Kompilieren Sie einfach mit mingw / msvc und versuchen Sie herauszufinden, warum es stattdessen abstürzt
einer MessageBox anzuzeigen, dass Hardware nicht unterstützt wird

Am Do, 11. Februar 2016, um 00:00 Uhr, Sergey Lapin [email protected]
schrieb:

Ich habe Zugang zum Speichern mit PCs von 80 bis Anfang 2000, wenn das hilft,
Aber ich brauche einige Details zum Testen und Debuggen, da ich es nicht bin
Windows-Entwickler in keiner Weise und haben keine Ideen zu Tools, etc.
Haben Sie einen Satz i740s mit win95se2-Boxen, einige sogar Pentim233MMX.
Aus buchhalterischen Gründen wird dies erst 2025 weggeworfen.

Übrigens, Juan, kannst du mich per E-Mail kontaktieren, damit ich deine persönliche Adresse habe?
Bombardiert es nicht mit irgendetwas Dummem.

Am Do, 11. Februar 2016, um 05:48 Uhr, Juan Linietsky [email protected]

schrieb:

Ich warte immer noch darauf, dass jemand mit einem alten Chipsatz einen besseren Beitrag leistet
Erkennung nicht unterstützter Hardware. Ich habe keine Hardware
schon seit
ein Jahrzehnt, also kann ich nicht viel tun.

Am Mittwoch, den 10. Februar 2016 um 23:30 Uhr, Sergey Lapin < [email protected]

schrieb:

Ich denke, das bedeutet "Patches sind willkommen". Ich bezweifle wirklich, dass es jemand tun wird
ablehnen
gut gemachte Unterstützung für
ältere Plattform.

Am Do, 11. Februar 2016, um 03:41 Uhr, Juan Linietsky <
[email protected]>
schrieb:

@ Algrin6 https://github.com/Algrin6 Es ist sinnlos zu überprüfen, ob
Das
Sachen werden in älteren Versionen von OpenGL unterstützt. Diese GPUs haben
Treiber
die OpenGL mitteilen, dass alles unterstützt wird, und dann in eine Art gehen
von
bizarrer Software-Fallback, der langsam ist, einfriert oder abstürzt.

Ich möchte lieber so tun, als ob solche alte Hardware nicht existiert und existiert
gefallen
vom Planeten.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
< https://github.com/godotengine/godot/issues/1162#issuecomment -182678470
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -182679526.

Kompilierte godot.windows.tools.32.exe mit MinGW. Stürzt ab. Was macht man als nächstes?

Das einzige, woran ich denken kann, ist, dass Sie den Absturz debuggen müssen. Ich würde
Beginnen Sie mit der Funktion main () und drucken Sie jeden Funktionsnamen
Es wird ausgeführt, bis derjenige gefunden ist, in dem es abstürzt. Fügen Sie dann einfach Drucken hinzu
jede Funktionszeile, um die genaue Zeile zu finden, in der sie sich befindet
stürzt ab und meldet die Ergebnisse zurück. Auch wenn von mingw kompiliert, wie Sie bekommen
Absturzadresse, die Sie verwenden können
addr2line -e / path / to / debug / exe 0x

Tatsächlich scheint MinGW mit gdb :

E:\r\godot\bin>gdb godot.windows.tools.32.exe
GNU gdb (GDB) 7.8.1
...
This GDB was configured as "i686-w64-mingw32".
...
Reading symbols from godot.windows.tools.32.exe...done.
(gdb) run
Starting program: E:\r\godot\bin\godot.windows.tools.32.exe
[New Thread 384.0xca0]
EXEC PATHP??: E:\r\godot\bin\godot.windows.tools.32.exe
EXEC PATHP??: E:\r\godot\bin\godot.windows.tools.32.exe
EXEC PATHP??: E:\r\godot\bin\godot.windows.tools.32.exe
DETECTED MONITORS: 1

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x004baf5f in RasterizerGLES2::init (this=0xa144dd0) at drivers\gles2\rasterizer_gles2.cpp:10808
#2  0x00db4863 in VisualServerRaster::init (this=0xa1c6a20) at servers\visual\visual_server_raster.cpp:7550
#3  0x00db5cef in VisualServerWrapMT::init (this=0xb3c3e30) at servers\visual\visual_server_wrap_mt.cpp:156
#4  0x004041e6 in OS_Windows::initialize (this=0x22dd20, p_desired=..., p_video_driver=0, p_audio_driver=0) at platform\windows\os_windows.cpp:984
#5  0x004101c6 in Main::setup2 () at main\main.cpp:852
#6  0x0040f504 in Main::setup (execpath=0x8f143a8 "E:\\r\\godot\\bin\\godot.windows.tools.32.exe", argc=0, argv=0x8f1438c, p_second_phase=true)
    at main\main.cpp:796
#7  0x00401935 in widechar_main (argc=1, argv=0x273e58) at platform\windows\godot_win.cpp:138
#8  0x00401a53 in main (_argc=1, _argv=0x8f11c98) at platform\windows\godot_win.cpp:172
(gdb)

Gemäß der obigen Spur stürzt es an der Linie ab:

...
    glGenTextures(1, &white_tex);
    unsigned char whitetexdata[8*8*3];
    for(int i=0;i<8*8*3;i++) {
        whitetexdata[i]=255;
    }
--> glActiveTexture(GL_TEXTURE0);
    glBindTexture(GL_TEXTURE_2D,white_tex);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 8, 8, 0, GL_RGB, GL_UNSIGNED_BYTE,whitetexdata);
    glGenerateMipmap(GL_TEXTURE_2D);
...

https://github.com/godotengine/godot/blame/f6a8a0f51358e42295cc5a049074a59466161ad8/drivers/gles2/rasterizer_gles2.cpp#L10808

Was kommt als nächstes?

Apitrace-Ausgabe

E:\r\godot\bin>apitrace.exe trace godot.windows.tools.32.exe
apitrace: loaded into E:\r\godot\bin\godot.windows.tools.32.exe
EXEC PATHP??: E:\r\godot\bin\godot.windows.tools.32.exe
EXEC PATHP??: E:\r\godot\bin\godot.windows.tools.32.exe
EXEC PATHP??: E:\r\godot\bin\godot.windows.tools.32.exe
DETECTED MONITORS: 1
apitrace: tracing to E:\r\godot\bin\godot.windows.tools.32.1.trace
apitrace: warning: caught exception 0xc0000005
apitrace: flushing trace due to an exception

E:\r\godot\bin>glretrace.exe godot.windows.tools.32.1.trace -v -d
2 <strong i="8">@0</strong> wglCreateContext(hdc = 0xcd01199a) = 0x10000
3 <strong i="9">@0</strong> wglMakeCurrent(hdc = 0xcd01199a, hglrc = 0x10000) = TRUE
warning: ChoosePixelFormat returned a pixel format supported by the GDI software implementation
4 <strong i="10">@0</strong> glViewport(x = 0, y = 0, width = 1024, height = 600)
4: warning: glGetError(glViewport) = GL_INVALID_ENUM
5 <strong i="11">@0</strong> glScissor(x = 0, y = 0, width = 1024, height = 600)
741 <strong i="12">@0</strong> glEnable(cap = GL_DEPTH_TEST)
742 <strong i="13">@0</strong> glDepthFunc(func = GL_LEQUAL)
743 <strong i="14">@0</strong> glFrontFace(mode = GL_CW)
744 <strong i="15">@0</strong> glClearColor(red = 0, green = 0, blue = 0, alpha = 1)
745 <strong i="16">@0</strong> glClear(mask = GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT)
746 <strong i="17">@0</strong> glGenTextures(n = 1, textures = &1)
Rendered 0 frames in 0.268717 secs, average of 0 fps

godot.windows.tools.32.1.trace.zip

Die Funktion ist NULL, weil der Treiber sie nicht bereitstellt, deshalb
stürzt ab.

Am 12. Februar 2016 um 01:21 Uhr, anatoly techtonik [email protected]
schrieb:

godot.windows.tools.32.1.trace.zip
https://github.com/godotengine/godot/files/127485/godot.windows.tools.32.1.trace.zip

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183174112.

@ punto- wo siehst du, dass es NULL ist?

oben auf der Rückverfolgung Frame 0, die Adresse wenn 0x00000, so ist es
sieht aus wie wenn Sie einen Funktionszeiger aufrufen, der null ist

Am 12. Februar 2016 um 06:58 Uhr, anatoly techtonik [email protected]
schrieb:

@ punto- https://github.com/punto- wo sehen Sie, dass es NULL ist?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183257600.

Aber ich verstehe nicht - C ++ ist nicht Python. Wenn also Godot-Binärdateien geladen werden, sollte das System die Treiber-DLL laden und mit der Warnung fehlschlagen, dass das angegebene Symbol nicht vorhanden ist. Warum passiert es nicht?

Oder bedeutet das, dass Godot tatsächlich eine dynamische Laufzeitverknüpfung implementiert, aber nicht vor fehlenden Symbolen warnt?

glew macht die Laufzeitverknüpfung, deshalb existiert die Funktion aber kann
manchmal null sein ..

Am 12. Februar 2016 um 13:41 Uhr, anatoly techtonik [email protected]
schrieb:

Oder bedeutet das, dass Godot tatsächlich eine dynamische Laufzeitverknüpfung implementiert?
aber warnt nicht vor fehlenden Symbolen?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183401773.

@ punto- das scheint nicht richtig. Kann dieses GLEW Ihre eigenen Stubs für diese NULL-Funktionen einfügen, die sich mit Fehlern beschweren, anstatt Fehler zu verursachen?

Ich weiß nicht ... vielleicht ... das wäre eine gute Idee

Am 12. Februar 2016 um 15:01 Uhr, anatoly techtonik [email protected]
schrieb:

@ punto- https://github.com/punto- das scheint nicht richtig zu sein. Kann das
GLEW injiziert Ihre eigenen Stubs für diese NULL-Funktionen, die sich beschweren
Fehler statt Segfaulting?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183431329.

C ++ ist nicht Python, aber Python ist C :) glew sucht wahrscheinlich nach den Symbolen
und wenn sie nicht vorhanden sind, weist sie dem Funktionszeiger NULL zu. ich
Ich erinnere mich nicht an alle Details, aber so stürzt es immer ab.
Welche Funktion auch immer von gl ist NULL ..

Am 12. Februar 2016 um 13:40 Uhr, anatoly techtonik [email protected]
schrieb:

Aber ich verstehe nicht - C ++ ist nicht Python, also wenn Godot-Binärdateien geladen werden, die
Das System sollte die Treiber-DLL laden und mit der Warnung fehlschlagen, dass das angegebene Symbol lautet
nicht anwesend. Warum passiert es nicht?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442.

Kann jemand mit einer dieser Intel-Karten diesen Build ausprobieren?

http://op.godotengine.org : 81 / godot.windows.tools.angle.32.exe

Am 12. Februar 2016 um 15:45 schrieb Ariel Manzur [email protected] :

C ++ ist nicht Python, aber Python ist C :) glew sucht wahrscheinlich nach den Symbolen
und wenn sie nicht vorhanden sind, weist sie dem Funktionszeiger NULL zu. ich
Ich erinnere mich nicht an alle Details, aber so stürzt es immer ab.
Welche Funktion auch immer von gl ist NULL ..

Am 12. Februar 2016 um 13:40 Uhr, anatoly techtonik [email protected]
schrieb:

Aber ich verstehe nicht - C ++ ist nicht Python, also wenn Godot-Binärdateien geladen werden, die
Das System sollte die Treiber-DLL laden und mit der Warnung fehlschlagen, dass das angegebene Symbol lautet
nicht anwesend. Warum passiert es nicht?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442
.

Ansicht 32

Es sind 32 Bit. Kann Windows nur 64 Bit akzeptieren?

Am 14. Februar 2016 um 01:29 Uhr, anatoly techtonik [email protected]
schrieb:

[Bild: Bild]
https://cloud.githubusercontent.com/assets/515889/13031852/90815d62-d2ec-11e5-8b8c-ccbc54af1f48.png

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183819635.

Dependency Walker zeigen, dass es sich um ein 64-Bit-Modul handelt, das mit 32-Bit-Bibliotheken verknüpft ist.

Sagt es welches?

Am 14. Februar 2016 um 01:38 Uhr, anatoly techtonik [email protected]
schrieb:

Dependency Walker zeigen, dass es sich um ein 64-Bit-Modul handelt, das mit 32-Bit-Bibliotheken verknüpft ist.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237.

(Auch warum funktioniert es auf meinem Computer? Ist das eine 32-Bit-CPU?)

Am 14. Februar 2016 um 01:52 schrieb Ariel Manzur [email protected] :

Sagt es welches?

Am 14. Februar 2016 um 01:38 Uhr, anatoly techtonik [email protected]
schrieb:

Dependency Walker zeigen, dass es sich um ein 64-Bit-Modul handelt, das mit 32-Bit-Bibliotheken verknüpft ist.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

Kannst du das versuchen?

http://op.godotengine.org : 81 / godot.windows.opt.tools.angle.64.exe

Am 14. Februar 2016 um 01:54 schrieb Ariel Manzur

(Auch warum funktioniert es auf meinem Computer? Ist das eine 32-Bit-CPU?)

Am 14. Februar 2016 um 01:52 schrieb Ariel Manzur [email protected] :

Sagt es welches?

Am 14. Februar 2016 um 01:38 Uhr, anatoly techtonik < [email protected]

schrieb:

Dependency Walker zeigen, dass es sich um ein 64-Bit-Modul handelt, das mit 32-Bit-Bibliotheken verknüpft ist.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

Auf meinem alten Laptop (Intel GMA X3100) stürzt es nicht ab, aber das Fenster bleibt grau mit den folgenden Fehlern:

ERROR: ShaderGLES2::get_current_version: CanvasShaderGLES2: Program LINK FAILED:
Failed to create D3D shaders.
   At: drivers\gles2\shader_gles2.cpp:544
ERROR: ShaderGLES2::get_current_version: Method/Function Failed, returning: 0
   At: drivers\gles2\shader_gles2.cpp:551
ERROR: ShaderGLES2::bind: Condition ' !version ' is true. returned: false
   At: drivers\gles2\shader_gles2.cpp:126
ERROR: ShaderGLES2::_get_uniform: Condition ' !version ' is true. returned: -1
   At: .\drivers/gles2/shader_gles2.h:354

Kann es eine zu alte Shader-Version sein?
Aber es ist seltsam, dass es D3D anstelle von GLSL versucht ...

Am Sonntag, den 14. Februar 2016 um 9:03 Uhr schrieb Hondres [email protected] :

Auf meinem alten Laptop (Intel GMA X3100) stürzt es nicht ab, aber das Fenster bleibt
grau mit folgenden Fehlern:

FEHLER: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: Programm-LINK FEHLGESCHLAGEN:
Fehler beim Erstellen der D3D-Shader.
Unter: drivers \ gles2 \ shader_gles2. cpp: 544
FEHLER: ShaderGLES2 :: get_current_version: Methode / Funktion fehlgeschlagen, Rückgabe: 0
Unter: drivers \ gles2 \ shader_gles2. cpp: 551
FEHLER: ShaderGLES2 :: bind: Bedingung '! Version' ist wahr. zurückgegeben: false
Unter: drivers \ gles2 \ shader_gles2. cpp: 126
FEHLER: ShaderGLES2 :: _ get_uniform: Bedingung '! Version' ist wahr. zurückgegeben: -1
Unter :. \ Drivers / gles2 / shader_gles2.h: 354

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183827627.

Gibt es jemals einen Fall, in dem Grafiken mit Winkel und nicht direkt mit Gl arbeiten?

Am 14. Februar 2016 um 03:25 schrieb Sergey Lapin [email protected] :

Kann es eine zu alte Shader-Version sein?
Aber es ist seltsam, dass es D3D anstelle von GLSL versucht ...

Am Sonntag, den 14. Februar 2016 um 9:03 Uhr schrieb Hondres [email protected] :

Auf meinem alten Laptop (Intel GMA X3100) stürzt es nicht ab, aber das Fenster bleibt
grau mit folgenden Fehlern:

FEHLER: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: Programm-LINK
GESCHEITERT:
Fehler beim Erstellen der D3D-Shader.
Unter: drivers \ gles2 \ shader_gles2. cpp: 544
FEHLER: ShaderGLES2 :: get_current_version: Methode / Funktion fehlgeschlagen,
Rückgabe: 0
Unter: drivers \ gles2 \ shader_gles2. cpp: 551
FEHLER: ShaderGLES2 :: bind: Bedingung '! Version' ist wahr. zurückgegeben: false
Unter: drivers \ gles2 \ shader_gles2. cpp: 126
FEHLER: ShaderGLES2 :: _ get_uniform: Bedingung '! Version' ist wahr.
zurückgegeben: -1
Unter :. \ Drivers / gles2 / shader_gles2.h: 354

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
< https://github.com/godotengine/godot/issues/1162#issuecomment -183827627
.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183830014.

@ punto- tools berichten, dass godot.windows.tools.angle.32.exe keine gültige ausführbare PE-Datei ist. Können Sie eine Version veröffentlichen, die von UPX nicht berührt wird?

IMAGE_OPTIONAL_HEADER.Magic entspricht IMAGE_NT_OPTIONAL_HDR64_MAGIC, was falsch ist. Https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

ok versuche das:

http://op.godotengine.org : 81 / godot.windows.opt.tools.angle.32.exe

Es wird nicht von upx komprimiert

Am 14. Februar 2016 um 05:10 Uhr, anatoly techtonik [email protected]
schrieb:

@ punto- https://github.com/punto- seine IMAGE_OPTIONAL_HEADER.Magic ist
gleich IMAGE_NT_OPTIONAL_HDR64_MAGIC, was falsch ist
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -183846301.

Immer noch das gleiche Problem. depends glaubt, es sei eine 64-Bit-Binärdatei und nicht nur depends :

E:\_IDE_\godot>file godot.windows.opt.tools.angle.32.exe
godot.windows.opt.tools.angle.32.exe: PE32+ executable (console) x86-64, for MS Windows

Es ist übrigens ein Unix-Dienstprogramm.

@Hinsbart Können Sie diese http://tof.p1x.in/html5/ auf dem Computer versuchen, auf dem der graue Bildschirm und dieser Fehler angezeigt werden? angeblich verwendet Chrome den gleichen Code für ihren Renderer.

@techtonik Vielleicht habe ich diesen Fehler, bei dem ich Bits = 32 verwende und tatsächlich eine 64-Bit-Binärdatei erhalte.

@ punto- Ich weiß nicht, wie Sie es kompilieren oder auf welchen Fehler Sie sich beziehen. Befehle und Erstellungsprotokolle können dies verdeutlichen. Ich kann es selbst kompilieren, wenn Sie bereit sind, Ihre Änderungen in einem Zweig zu übernehmen.

Ja, ich bin dabei

hier ist es https://github.com/punto-/godot/tree/angle

Am 15. Februar 2016 um 14:53 Uhr, anatoly techtonik [email protected]
schrieb:

@ punto- https://github.com/punto- Ich weiß nicht, wie Sie es kompilieren oder
auf welche Fehler beziehen sich. Befehle und Erstellungsprotokolle können dies verdeutlichen. ich kann
Kompilieren Sie es selbst, wenn Sie bereit sind, Ihre Änderungen in einem Zweig zu übernehmen.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -184323695.

Kompilieren Sie mit Winkel = Ja

Am 15. Februar 2016 um 15:25 Uhr schrieb Ariel Manzur [email protected] :

hier ist es https://github.com/punto-/godot/tree/angle

Am 15. Februar 2016 um 14:53 Uhr, anatoly techtonik [email protected]
schrieb:

@ punto- https://github.com/punto- Ich weiß nicht, wie Sie es kompilieren
oder auf welche Fehler sich beziehen. Befehle und Erstellungsprotokolle können dies verdeutlichen. ich
kann es selbst kompilieren, wenn Sie bereit sind, Ihre Änderungen auf einige zu übertragen
Ast.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -184323695
.

scons: *** [drivers\theora\theora\x86\mmxencfrag.windows.tools.32.o] Source `drivers\theora\theora\x86\mmxencfrag.c' not found, needed by target `drivers\theora\theora\x86\mmxencfrag.windows.tools.32.o'.
scons: building terminated because of errors.

Kein Glück.

versuche es auch mit theora_opt = no

Am 15. Februar 2016 um 18:40 Uhr, anatoly techtonik [email protected]
schrieb:

scons: *** [drivers \ theora \ theora \ x86 \ mmxencfrag.windows.tools.32.o] Quelle drivers\theora\theora\x86\mmxencfrag.c' not found, needed by target drivers \ theora \ theora \ x86 \ mmxencfrag.windows.tools.32.o '.
scons: Gebäude wegen Fehlern abgebrochen.

Kein Glück.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -184405417.

In file included from drivers\angle/common/angleutils.h:12:0,
                 from drivers\angle\common\angleutils.cpp:7:
drivers\angle/common/platform.h:62:28: fatal error: d3d11_1.h: No such file or directory
 #       include <d3d11_1.h>
                            ^

Punkt?

Nun, das ist der Winkelpunkt, es wird direktes 3D anstelle von opengl: p verwendet

Am 15. Februar 2016 um 18:57 Uhr, anatoly techtonik [email protected]
schrieb:

In der Datei enthalten von drivers \ angle / common / angleutils.h: 12: 0,
von drivers \ angle \ common \ angleutils. cpp: 7 :
drivers \ angle / common / platform.h: 62: 28: Schwerwiegender Fehler: d3d11_1.h: Keine solche Datei oder kein solches Verzeichnis
# include
^

Punkt?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -184411949.

ANGLE hat zwei Backends - das ältere verwendet DirectX 9. Ich lade gerade neuere MinGW mit DirectX 11-Headern herunter.

Der Kontext wird in platform / windows / gl_context_egl_angle.cpp, I erstellt
Ich glaube, es gab dort einen Parameter, um das Backend auszuwählen. Ich denke, das
Das Problem liegt in dieser Datei. Möglicherweise gibt es eine Möglichkeit, die Parameter zu ermitteln
am besten für das system ..

Am 16. Februar 2016 um 05:51 Uhr, anatoly techtonik [email protected]
schrieb:

ANGLE hat zwei Backends - das ältere verwendet DirectX 9. Ich lade neuere herunter
MinGW mit DirectX 11-Headern im Moment.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -184580963.

Viele Fehler mit neuerem gcc 5.3.0, zum Beispiel:

In file included from drivers\angle\common\angleutils.cpp:7:0:
drivers\angle/common/angleutils.h:29:21: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11
     NonCopyable() = default;
                     ^
...

Sie müssen -std=c++11 zu den C ++ - Flags hinzufügen, denke ich.
Fügen Sie diese Zeile beispielsweise nach: https://github.com/punto-/godot/blob/angle/drivers/angle/SCsub#L276 hinzu

env_angle.Append(CCFLAGS=['-std=c++11'])

Ich bin mir nicht sicher, ob die Syntax für MSVC funktionieren würde, aber mit MinGW sollte es in Ordnung sein.

drivers\angle\libANGLE\renderer\d3d\d3d11\win32\NativeWindow.cpp:15:19: fatal error:
dcomp.h: No such file or directory
compilation terminated.

Ich muss auf die neue Version von MinGW warten.

Vielleicht sollte die Diskussion über ANGLE auf ein separates Thema verschoben werden, wobei dieses Thema beibehalten wird, um "dem Benutzer mitzuteilen, dass seine Hardware alt ist und vor dem Absturz nicht unterstützt wird"?

Ja ich stimme zu

Am 17. Februar 2016 um 13:25 Uhr meldete Rémi Verschelde [email protected]
schrieb:

Vielleicht sollte die Diskussion über ANGLE auf ein separates Thema verschoben werden.
Halten Sie diese für "sagen Sie dem Benutzer, dass seine Hardware alt ist und
vor dem Absturz nicht unterstützt "?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -185282158.

3634 ist das ANGLE-Problem. # 3694 ist PR, um weitere Informationen beim Laden des Motors zu erhalten.

@ Heybye44

Warum funktioniert Godot auf magische Weise unter Ubuntu, aber nicht unter Windows?

Ja! Ich würde auch gerne den Grund wissen. Es funktioniert, wenn ich mit Xubuntu getestet habe, aber nicht mit einer Windows-Edition.

^^

Es geht nicht um das Betriebssystem, es geht um die Treiber. Im Allgemeinen werden GL-Treiber unter Windows im Vergleich zu Linux dank Direct3D vernachlässigt. Viele ältere GPUs haben unter neueren Windows-Versionen eine minimale GL 1.5-Implementierung.

@adolson

Viele ältere GPUs haben unter neueren Windows-Versionen eine minimale GL 1.5-Implementierung.

Wann werden frühere OpenGL-Versionen in Godot unterstützt? Gibt es eine absolute explizite Notwendigkeit, sich auf 2.0+ zu verlassen? Es ist nicht so, dass es keine Abwärtskompatibilität gibt, sodass ein leistungsfähigeres Gerät beim Rendern einer früheren Iteration von OpenGL nicht versagen wird. Gibt es Funktionen des visuellen Editors selbst, die auf GLES2 basieren und nicht auf die Verwendung von GL1.4 anstelle von GL1.4 reduziert werden konnten? Ich meine, die meisten späteren GL-Funktionen sind sowieso für das 3D-Rendering vorgesehen, was aus der Perspektive der Absicht, mit Godot ein 2D-Spiel zu erstellen, unnötig ist.

@WinnerEX Das wird nicht passieren. Kompatibel mit GL 1.4 zu sein, würde bedeuten, viele interessante Funktionen aufzugeben, die sowohl für 2D als auch für 3D verwendet werden. und am anderen Ende des Spektrums haben wir Leute, die nicht länger auf die Unterstützung von GL 3+ oder sogar Vulkan warten können. Sie können Godot sicher als GL 2.1+ Motor betrachten. Wenn Sie dies nicht möchten, gibt es viele andere Engines mit möglicherweise niedrigeren GL-Einschränkungen (z. B. OGRE 1.9 oder SDL 2.0).

Das Thema hier ist, dass Godot einen korrekten Fehler geben sollte, wenn die erforderlichen GL 2.1+ -Funktionen nicht verfügbar sind, anstatt abzustürzen. Es besteht keine Absicht, einen GLES1-Renderer neu zu schreiben. Für Windows-Benutzer besteht möglicherweise Hoffnung, dass ANGLE für die GL-Emulation über Direct3D integriert ist, der GLES2-Renderer wird jedoch nicht heruntergestuft.

Zurück zum Thema: @reduz , ich dachte, dass es möglich sein könnte, den Absturz auch auf GL 2.1-fähiger Hardware zu reproduzieren, indem versucht wird, Godot in eine virtuelle Maschine ohne 2D- und 3D-Beschleunigung zu laden. Ich werde es so schnell wie möglich versuchen, um zu bestätigen, aber das könnte helfen, herauszufinden, wo es abstürzt und wie man mit einer von Menschen lesbaren Fehlermeldung richtig aussteigt, anstatt Fehler zu machen.

Ich dachte, dass es möglich sein könnte, den Absturz sogar auf GL 2.1-fähiger Hardware zu reproduzieren, indem versucht wird, Godot in eine virtuelle Maschine ohne 2D- und 3D-Beschleunigung zu laden. Ich werde es so schnell wie möglich versuchen, um es zu bestätigen

Okay, es sieht so aus, als ob es mit VirtualBox 5 nicht einfach ist, da es jetzt einen anständigen GL-Treiber hat, der bis zu OpenGL 3.0 xD unterstützt.

opengl 3.0 ist leichter zu erkennen, da Sie einen speziellen Kontext anfordern müssen
(Ich hopt)

Am Montag, 25. Juli 2016 um 12:28 Uhr, Rémi Verschelde [email protected]
schrieb:

Ich dachte, dass es möglich sein könnte, den Absturz sogar auf GL 2.1 zu reproduzieren
fähige Hardware durch den Versuch, Godot in eine virtuelle Maschine ohne 2D zu laden
und 3D-Beschleunigung. Ich werde es so schnell wie möglich versuchen, um es zu bestätigen

Okay, es sieht so aus, als ob es mit VirtualBox 5 nicht einfach ist, da es jetzt einen anständigen hat
GL-Treiber, der bis zu OpenGL 3.0 xD unterstützt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/1162#issuecomment -234987968,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AF-Z2_MK5iQA0RxLwv0FHu6po8ucVE8kks5qZNYlgaJpZM4DQoN3
.

Ich habe gerade einen Test auf meinem alten Netbook mit einem inkompatiblen beschissenen Intel IgP unter Windows durchgeführt.

In Zeile 10791 von rasterizer_gles2.cpp in RasterizerGLES2::init() habe ich diese paar Zeilen hinzugefügt:

    if (!glewIsSupported("GL_VERSION_2_1")) {
        print_line(String("Your graphics card is crappy. It does not support Opengl 2.1. Now Godot is going to crash."));
    }

Godot stürzt immer noch ab, zeigt diese Fehlermeldung jedoch kurz vor der Ohnmacht in der Konsole an.

Ich weiß nicht, wie ich Godot anweisen soll, die Rasterizer-Initialisierung abzubrechen (RasterizerGLES2 :: init () gibt nicht true / false zurück, es ist, als hätte es keine andere Wahl als Erfolg oder Absturz), und ich weiß auch nicht, wie ich Godot anweisen soll, das Programm zu beenden richtig.

Selbst wenn dieser Kompatibilitätstest möglicherweise nicht 100% zuverlässig ist, kann er zumindest die Anzahl der stillen Abstürze verringern und ein kleines Systemdialogfeld anzeigen, das den Benutzer warnt, dass er abstürzen wird und warum.

Genialer Fund @SuperUserNameMan. Ich habe ein bisschen damit herumgespielt und bestätige, dass es funktioniert (zumindest in meinen Tests, in denen ich nach if (glewIsSupported("GL_VERSION_2_1")) gesucht habe, da meine GPU dies unterstützt). Wir können OS::alert() , um ein blockierendes Meldungsfeld anzuzeigen.

Wie Sie bereits erwähnt haben, besteht der einzige fehlende (und schwierigste) Teil darin, Godot ordnungsgemäß verlassen zu lassen. Ich habe einen kurzen Blick darauf geworfen, aber es ist weit über meine Fähigkeiten hinaus, Godot mitten in seiner Betriebssysteminitialisierung zum Beenden zu bringen.

Hier ist ein Unterschied zum Proof of Concept:

diff --git a/drivers/gles2/rasterizer_gles2.cpp b/drivers/gles2/rasterizer_gles2.cpp
index 4cd97a7..910d5bf 100644
--- a/drivers/gles2/rasterizer_gles2.cpp
+++ b/drivers/gles2/rasterizer_gles2.cpp
@@ -10788,8 +10788,14 @@ void RasterizerGLES2::init() {
        if (OS::get_singleton()->is_stdout_verbose()) {
                print_line(String("GLES2: Using GLEW ") + (const char*) glewGetString(GLEW_VERSION));
        }
-#endif

+       // Check for GL 2.1 compatibility, if not bail out
+       if (!glewIsSupported("GL_VERSION_2_1")) {
+               ERR_PRINT("Your system's graphic drivers seem not to support OpenGL 2.1 / GLES 2.0, sorry :(\nTry a drivers update, buy a new GPU or move to Linux; Godot will now exit.");
+               OS::get_singleton()->alert("Your system's graphic drivers seem not to support OpenGL 2.1 / GLES 2.0, sorry :(", "Insufficient OpenGL / GLES drivers");
+               // Now DIE! Or at least stop without segfault and memory leaks :)
+       }
+#endif

Um für Personen mit GL 2.1-Unterstützung testen zu können, entfernen Sie einfach die ! im if-Test.

Es erzeugt dieses (blockierende) Meldungsfeld auf X11:

Nach einer Diskussion mit @reduz scheint mein obiger Patch als erster Schritt gut genug zu sein. Da die Betriebssystemwarnung blockiert, können wir die Leute über das Problem informieren und sie warnen, dass Godot abstürzen wird :) Ein sauberes Beenden wäre natürlich besser, aber diese Zwischenlösung ist bereits schön zu haben.

Um unter Linux zu testen, ohne den Code zu ändern und neu zu kompilieren, können Sie die Umgebungsvariable MESA_GL_VERSION_OVERRIDE auf 2.0 setzen: http://www.mesa3d.org/envvars.html

IIRC, so wird auch vorgegangen, um MESA zu zwingen, die GPU auf der schwarzen Liste mit Godot arbeiten zu lassen.