+1

+10

+1

j'ai écrit ce code dans context_gl_win.cpp mais il plante généralement en raison de
une fonction non implémentée dans Windows en raison d'un pilote de merde
J'aimerais savoir exactement pourquoi

Le samedi 17 janvier 2015 à 14 h 56, MSC [email protected] a écrit:

+1

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/okamstudio/godot/issues/1162#issuecomment -70376758.

Définir cela comme une priorité élevée pour le moment car ce serait une fonctionnalité très utile. Nous recevons des tonnes de rapports de plantages dus à des personnes ayant de très vieux IGP Intel ou autres qui ne prennent pas en charge GLES2.

Ok, je suppose que j'ai référencé suffisamment de plantages pour souligner mes "tonnes" ci-dessus, je vais arrêter de fouiller dans les archives: D

+1 Pourquoi Godot fonctionne-t-il comme par magie sur Ubuntu mais pas sur Windows?

Une idée sur la façon dont cela pourrait être mis en œuvre @reduz?

j'ai écrit ce code dans context_gl_win.cpp mais il plante généralement en raison d'une fonction non implémentée dans Windows

Pourquoi ne pas utiliser la liaison dynamique alors? Il sera évident quelle fonction manque. Je crois que https://github.com/p3/regal fait cela.

J'ai déjà détecté et tenté d'afficher un message, mais il semble
ne fonctionne toujours pas.
Comme je n'ai pas de matériel non pris en charge, je ne vois pas pourquoi il plante et
donc, ne peut pas le réparer.
Les RP sont les bienvenus.

Le mar 2 février 2016 à 12 h 11, anatoly techtonik < [email protected]

a écrit:

j'ai écrit ce code dans context_gl_win.cpp mais il plante généralement en raison de
une fonction non implémentée dans Windows

Pourquoi ne pas utiliser la liaison dynamique alors? Il sera évident quelle fonction est
disparu. Je crois que https://github.com/p3/regal fait cela.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -178624438.

Si quelqu'un avec un ancien GPU pouvait essayer d'exécuter Godot via gdb sous Linux, cela pourrait alors être très utile. Les informations de débogage de Windows "signature de problème" semblent inutiles: /

Je ne fais pas du tout de C ++. Seulement Python, donc je suis un utilisateur. Dites-moi quoi exécuter et je pourrais obtenir les informations.

Dites-moi quoi exécuter et je pourrais obtenir les informations.

Je n'ai aucune idée de la façon d'exécuter des choses via un débogueur sous Windows, mais je pense que ce n'est pas trivial pour les personnes qui n'ont pas beaucoup d'expérience dans la compilation de choses sur Windows. C'est pourquoi j'ai suggéré à quelqu'un d'essayer de déboguer avec GDB sous Linux, car c'est très facile à utiliser:

$ 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

et copiez la sortie de cette commande bt (backtrace) dans ce rapport de bogue.

Bien sûr, il se pourrait que le problème soit spécifique à Windows, donc le débogage sous Linux serait inutile, mais je pense que les utilisateurs de Linux avaient également des erreurs de segmentation qui n'étaient pas détectées pour indiquer à l'utilisateur que leur matériel ne prend pas en charge OpenGL (ES) 2.1.

La bêta 2.0 ne fonctionne pas sur mon Linux, mais cela ne semble pas lié à la carte graphique - # 3557

Héhé, vous êtes chanceux de rencontrer tous les problèmes connus que nous avons dans les cas secondaires :)

Je suppose que j'ai juste un "talent plaintif" et un compte GitHub. =)

Je ne connais pas ces vieilles cartes vidéo qui plantent au démarrage, mais sur, par exemple, sur NVIDIA 6800 GT,
il ne plante que sur quelques projets. Il y a donc une sortie cmd sur les erreurs de framebuffer sur tous les projets et modules Godot. Il peut être entièrement corrigé en désactivant le paramètre "fp16_framebuffer" dans les paramètres du rasterizer du projet. Je sais, sur les mêmes cartes vidéo (je ne sais pas à propos de la connexion complète), il y a un mauvais rastérisation (pas de textures) ce qui peut être entièrement corrigé en désactivant le paramètre "fragment_lighting".
Je pense donc que Godot devrait vérifier si ces fonctions sont prises en charge, et sinon, notez l'utilisateur et désactivez-les.
Peut-être que cela aidera aussi avec le crash au démarrage.

Dites-moi quoi exécuter et je pourrais obtenir les informations.

$ gdb / path / to / godot / binary // si possible auto-compilé en mode débogage, pour avoir plus d'informations

Godot_v2.0_beta_20160205_x11.64 ne plante pas sur Fedora 23 avec le même matériel. Il y est détecté comme Mobile Intel® GM45 Express Chipset .

Godot_v2.0_beta_20160205_win32.exe plante toujours sous Vista 32.

@techtonik Je pense que la raison est que Linux, contrairement à Windows, utilise la réalisation logicielle pour OpenGL quand il y a des problèmes avec le matériel OpenGL, mais c'est plus lent que celui du matériel, bien sûr.

@ Algrin6 ce serait bien si le moteur pouvait simplement fournir une certaine transparence sur ce fait. Dans l'ancien temps, des jeux comme Baldur's Gate étaient livrés avec des binaires de test graphique. 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 Mo de mémoire! Et maintenant, j'ai 3 Go + 3 GHz et je ne peux pas exécuter le moteur de jeu. Comment venir?

2 Mo de mémoire! Et maintenant, j'ai 3 Go + 3 GHz et je ne peux pas exécuter le moteur de jeu. Comment venir?

Parce que nous sommes en 2016 et que le moteur Bioware est super vieux? Et ce test a été conçu pour vérifier si le pilote graphique est assez puissant, donc probablement le test a commencé à fonctionner avec DirectX 3.01a, mais peut-être en disant "mettre à jour votre matériel ou vos pilotes" si vous étiez sous DirectX 7 ou quelque chose. Et le moteur Bioware fonctionnait uniquement sur MS Windows <= XP, tandis que Godot fonctionne sur une dizaine de plateformes ...

Maintenant que vous semblez savoir exactement ce que nous devons faire, veuillez faire une demande d'extraction.

Le problème majeur de

La porte de Baldur n'est pas programmée dans un moteur de jeu 2D / 3D à usage général.
Il est programmé sur mesure en C, assembleur x86, probablement Watcom
compilateur, mode protégé et utilise une machine de pile de base pour les scripts. Également
n'hésitez pas à créer vous-même tout le code blitting personnalisé.

Le dim 7 février 2016 à 12 h 36, George Marques [email protected]
a écrit:

@techtonik https://github.com/techtonik Le problème majeur à ce sujet est
qu'aucun des principaux développeurs ne dispose de matériel ancien pour tester le problème. Alors
vous devez soit fournir des informations de débogage pour identifier la cause du problème, soit
corrigez-le vous-même (ce qui est la beauté de l'open source).

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -181034018.

@reduz Godot peut-il produire une "table de compatibilité de plate-forme" pour le code produit par le moteur (ou utilisé par l'éditeur) qui répertorie toutes les fonctionnalités que le jeu utilise actuellement (blitting, particules, objets 3D, ...)?

Si cela est impossible pour le moment, est-ce au moins techniquement faisable?

Le cas d'utilisation de la validation est de pouvoir produire un jeu minimal (test) qu'il peut exécuter sur n'importe quel appareil blitting et mesurer les performances.

@reduz Qu'en est-il de https://github.com/godotengine/godot/issues/1162#issuecomment -180466018?

@ Algrin6 Il est inutile de vérifier si ces éléments sont pris en charge dans les anciennes versions d'OpenGL. Ces GPU ont des pilotes qui indiquent à OpenGL que tout est pris en charge, puis entrent dans une sorte de solution de secours logicielle bizarre qui est lente, se fige ou se bloque.

Je préfère prétendre qu'un tel vieux matériel n'existe pas et est tombé de la planète.

Je pense que cela signifie "les correctifs sont les bienvenus" Je doute vraiment que quiconque rejette
support bien fait pour
ancienne plate-forme.

Le jeu.11 février 2016 à 03:41, Juan Linietsky [email protected]
a écrit:

@ Algrin6 https://github.com/Algrin6 Il est inutile de vérifier si cela
stuff est pris en charge dans les anciennes versions d'OpenGL. Ces GPU ont des pilotes
qui indiquent à OpenGL que tout est pris en charge, puis entrez dans une sorte de
un logiciel de secours bizarre qui est lent, se fige ou plante.

Je préfère faire comme si ce vieux matériel n'existe pas et est tombé
de la planète.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216.

J'attends toujours que quelqu'un avec un vieux chipset contribue mieux
détection de matériel non pris en charge. Je n'ai plus de matériel depuis
une décennie, donc je ne peux rien faire.

Le mercredi 10 février 2016 à 23h30, Sergey Lapin [email protected]
a écrit:

Je pense que cela signifie "les correctifs sont les bienvenus" Je doute vraiment que quiconque rejette
support bien fait pour
ancienne plate-forme.

Le jeu.11 février 2016 à 03:41, Juan Linietsky [email protected]
a écrit:

@ Algrin6 https://github.com/Algrin6 Il est inutile de vérifier si cela
stuff est pris en charge dans les anciennes versions d'OpenGL. Ces GPU ont des pilotes
qui indiquent à OpenGL que tout est pris en charge, puis entrez dans une sorte de
un logiciel de secours bizarre qui est lent, se fige ou plante.

Je préfère faire comme si ce vieux matériel n'existe pas et est tombé
de la planète.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389.

J'ai accès au stockage avec des PC des années 80 au début des années 2000, si cela peut aider,
mais j'ai besoin de quelques détails sur la façon de tester et de déboguer car je ne suis pas
développeur Windows en aucune façon et n'a aucune idée sur les outils, etc.
Avoir un ensemble de i740 avec des boîtiers win95se2, certains Pentim233MMX même.
En raison de la comptabilité, cela ne sera pas jeté avant 2025.

btw, Juan pourriez-vous me contacter par e-mail pour que j'aie votre adresse personnelle?
Je ne le bombarderai pas avec quelque chose de stupide.

Le jeu.11 février 2016 à 05:48, Juan Linietsky [email protected]
a écrit:

J'attends toujours que quelqu'un avec un vieux chipset contribue mieux
détection de matériel non pris en charge. Je n'ai plus de matériel depuis
une décennie, donc je ne peux rien faire.

Le mercredi 10 février 2016 à 23h30, Sergey Lapin [email protected]
a écrit:

Je pense que cela signifie "les correctifs sont les bienvenus" Je doute vraiment que quiconque le fasse
rejeter
support bien fait pour
ancienne plate-forme.

Le jeu.11 février 2016 à 03:41, Juan Linietsky <
[email protected]>
a écrit:

@ Algrin6 https://github.com/Algrin6 Il est inutile de vérifier si cela
stuff est pris en charge dans les anciennes versions d'OpenGL. Ces GPU ont des pilotes
qui disent à OpenGL que tout est pris en charge, puis entrez dans une sorte
de
un logiciel de secours bizarre qui est lent, se fige ou plante.

Je préfère prétendre qu'un tel vieux matériel n'existe pas et
déchue
de la planète.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182678470.

Vous n'avez pas besoin d'aller plus loin en arrière. Just intel Series 3/4 ou i940 est
assez pour le faire planter ...
Compilez simplement avec mingw / msvc et essayez de comprendre pourquoi il plante à la place
d'afficher un MessageBox que le matériel n'est pas pris en charge

Le jeu.11 février 2016 à 00h00, Sergey Lapin [email protected]
a écrit:

J'ai accès au stockage avec des PC des années 80 au début des années 2000, si cela peut aider,
mais j'ai besoin de quelques détails sur la façon de tester et de déboguer car je ne suis pas
développeur Windows en aucune façon et n'a aucune idée sur les outils, etc.
Avoir un ensemble de i740 avec des boîtiers win95se2, certains Pentim233MMX même.
En raison de la comptabilité, cela ne sera pas jeté avant 2025.

btw, Juan pourriez-vous me contacter par e-mail pour que j'aie votre adresse personnelle?
Je ne le bombarderai pas avec quelque chose de stupide.

Le jeu.11 février 2016 à 05:48, Juan Linietsky [email protected]

a écrit:

J'attends toujours que quelqu'un avec un vieux chipset contribue mieux
détection de matériel non pris en charge. Je n'ai aucun de ce matériel
depuis
une décennie, donc je ne peux rien faire.

Le mercredi 10 février 2016 à 23h30, Sergey Lapin < [email protected]

a écrit:

Je pense que cela signifie "les correctifs sont les bienvenus" Je doute vraiment que quiconque le fasse
rejeter
support bien fait pour
ancienne plate-forme.

Le jeu.11 février 2016 à 03:41, Juan Linietsky <
[email protected]>
a écrit:

@ Algrin6 https://github.com/Algrin6 Il est inutile de vérifier si
cette
stuff est pris en charge dans les anciennes versions d'OpenGL. Ces GPU ont
Conducteurs
qui disent à OpenGL que tout est pris en charge, puis entrez dans une sorte
de
un logiciel de secours bizarre qui est lent, se fige ou plante.

Je préfère prétendre qu'un tel vieux matériel n'existe pas et
déchue
de la planète.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182678470
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182679526.

Compilé godot.windows.tools.32.exe avec MinGW. Crashes. Que faire ensuite?

La seule chose à laquelle je peux penser est que vous devez déboguer le crash. Je
démarrer avec la fonction main () et imprimer le nom de chaque fonction
il s'exécute jusqu'à ce que celui dans lequel il plante soit trouvé, puis ajoutez simplement l'impression à
chaque ligne de fonction pour trouver la ligne exacte où elle
plante et rend compte des résultats. Aussi si compilé par mingw comme vous obtenez
adresse de plantage que vous pouvez utiliser
addr2line -e / chemin / vers / debug / exe 0x

En fait, MinGW semble être expédié avec 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)

D'après la trace ci-dessus, il plante à la ligne:

...
    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

Alors, quelle est la prochaine étape?

sortie apitrace

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

La fonction est NULL car le pilote ne la fournit pas, c'est pourquoi elle
plante.

Le 12 février 2016 à 01:21, anatoly techtonik [email protected]
a écrit:

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

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183174112.

@ punto- où voyez-vous que c'est NULL?

en haut de la trace arrière, trame 0, l'adresse si 0x00000, c'est comme ça
ressemble à lorsque vous appelez un pointeur de fonction qui est nul

Le 12 février 2016 à 06:58, anatoly techtonik [email protected]
a écrit:

@ punto- https://github.com/punto- où voyez-vous que c'est NULL?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183257600.

Mais je ne comprends pas - C ++ n'est pas Python, donc lorsque godot binaire se charge, le système doit charger la DLL du pilote et échouer avec l'avertissement que le symbole donné n'est pas présent. Pourquoi ça n'arrive pas?

Ou cela signifie-t-il que Godot implémente réellement une liaison dynamique à l'exécution, mais ne met pas en garde contre les symboles manquants?

glew effectue la liaison au moment de l'exécution, c'est pourquoi la fonction existe mais peut
parfois être nul.

Le 12 février 2016 à 13h41, anatoly techtonik [email protected]
a écrit:

Ou cela signifie-t-il que Godot implémente réellement une liaison dynamique à l'exécution,
mais ne prévient pas des symboles manquants?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401773.

@ punto- cela ne semble pas correct. Ce GLEW peut-il injecter vos propres stubs pour ces fonctions NULL qui se plaignent d'erreur au lieu de segfaulting?

Je ne sais pas ... peut-être ... ce serait une bonne idée

Le 12 février 2016 à 15:01, anatoly techtonik [email protected]
a écrit:

@ punto- https://github.com/punto- cela ne semble pas correct. Cela peut-il
GLEW injecte vos propres stubs pour ces fonctions NULL qui se plaignent
erreur au lieu de segfaulting?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183431329.

C ++ n'est pas python, mais python est C :) glew cherche probablement les symboles
et lorsqu'ils ne sont pas présents, il affecte NULL au pointeur de fonction. je
Je ne me souviens pas de tous les détails, mais c'est comme ça que ça plante toujours,
quelle que soit la fonction de gl est NULL ..

Le 12 février 2016 à 13h40, anatoly techtonik [email protected]
a écrit:

Mais je n'obtiens pas - C ++ n'est pas Python, donc quand godot binaire se charge, le
le système doit charger la DLL du pilote et échouer avec l'avertissement que
pas présent. Pourquoi ça n'arrive pas?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442.

Est-ce que n'importe qui avec l'une de ces cartes Intel peut essayer cette version?

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

Le 12 février 2016 à 15h45, Ariel Manzur [email protected] a écrit:

C ++ n'est pas python, mais python est C :) glew cherche probablement les symboles
et lorsqu'ils ne sont pas présents, il affecte NULL au pointeur de fonction. je
Je ne me souviens pas de tous les détails, mais c'est comme ça que ça plante toujours,
quelle que soit la fonction de gl est NULL ..

Le 12 février 2016 à 13h40, anatoly techtonik [email protected]
a écrit:

Mais je n'obtiens pas - C ++ n'est pas Python, donc quand godot binaire se charge, le
le système doit charger la DLL du pilote et échouer avec l'avertissement que
pas présent. Pourquoi ça n'arrive pas?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442
.

vue 32

C'est 32 bits .. est-il possible que Windows n'accepte que 64 bits?

Le 14 février 2016 à 01:29, anatoly techtonik [email protected]
a écrit:

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

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183819635.

Les explorateurs de dépendances montrent qu'il s'agit d'un module 64 bits lié à des bibliothèques 32 bits.

Dit-il lequel?

Le 14 février 2016 à 01:38, anatoly techtonik [email protected]
a écrit:

Les explorateurs de dépendances montrent qu'il s'agit d'un module 64 bits lié à des bibliothèques 32 bits.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237.

(aussi pourquoi ça marche sur mon ordinateur? Est-ce un processeur 32 bits?)

Le 14 février 2016 à 01h52, Ariel Manzur [email protected] a écrit:

Dit-il lequel?

Le 14 février 2016 à 01:38, anatoly techtonik [email protected]
a écrit:

Les explorateurs de dépendances montrent qu'il s'agit d'un module 64 bits lié à des bibliothèques 32 bits.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

Pouvez-vous essayer celui-ci?

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

Le 14 février 2016 à 01h54, Ariel Manzur [email protected] a écrit:

(aussi pourquoi ça marche sur mon ordinateur? Est-ce un processeur 32 bits?)

Le 14 février 2016 à 01h52, Ariel Manzur [email protected] a écrit:

Dit-il lequel?

Le 14 février 2016 à 01:38, anatoly techtonik < [email protected]

a écrit:

Les explorateurs de dépendances montrent qu'il s'agit d'un module 64 bits lié à des bibliothèques 32 bits.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

Sur mon ancien ordinateur portable (intel gma x3100), il ne plante pas, mais la fenêtre reste grise avec les erreurs suivantes:

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

Peut-il s'agir d'une version de shaders trop ancienne?
Mais c'est étrange qu'il essaie des D3D au lieu de GLSL ...

Le dimanche 14 février 2016 à 9 h 03, Hondres [email protected] a écrit:

Sur mon ancien ordinateur portable (intel gma x3100), il ne plante pas, mais la fenêtre reste
gris avec les erreurs suivantes:

ERREUR: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: ÉCHEC DU LIEN DU PROGRAMME:
Échec de la création des shaders D3D.
À: drivers \ gles2 \ shader_gles2. cpp: 544
ERREUR: ShaderGLES2 :: get_current_version: Échec de la méthode / fonction, retour: 0
À: drivers \ gles2 \ shader_gles2. cpp: 551
ERREUR: ShaderGLES2 :: bind: La condition '! Version' est vraie. renvoyé: faux
À: drivers \ gles2 \ shader_gles2. cpp: 126
ERREUR: ShaderGLES2 :: _ get_uniform: La condition '! Version' est vraie. renvoyé: -1
À:. \ Drivers / gles2 / shader_gles2.h: 354

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183827627.

Y a-t-il donc un cas où les graphiques fonctionnent en utilisant l'angle et non gl directement?

Le 14 février 2016 à 03:25, Sergey Lapin [email protected] a écrit:

Peut-il s'agir d'une version de shaders trop ancienne?
Mais c'est étrange qu'il essaie des D3D au lieu de GLSL ...

Le dimanche 14 février 2016 à 9 h 03, Hondres [email protected] a écrit:

Sur mon ancien ordinateur portable (intel gma x3100), il ne plante pas, mais la fenêtre reste
gris avec les erreurs suivantes:

ERREUR: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: Program LINK
ÉCHOUÉ:
Échec de la création des shaders D3D.
À: drivers \ gles2 \ shader_gles2. cpp: 544
ERREUR: ShaderGLES2 :: get_current_version: échec de la méthode / fonction,
retour: 0
À: drivers \ gles2 \ shader_gles2. cpp: 551
ERREUR: ShaderGLES2 :: bind: La condition '! Version' est vraie. renvoyé: faux
À: drivers \ gles2 \ shader_gles2. cpp: 126
ERREUR: ShaderGLES2 :: _ get_uniform: La condition '! Version' est vraie.
renvoyé: -1
À:. \ Drivers / gles2 / shader_gles2.h: 354

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -183827627
.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183830014.

@ punto- tools rapportent que godot.windows.tools.angle.32.exe n'est pas un exécutable PE valide. Pouvez-vous publier une version qui n'est pas touchée par UPX?

Son IMAGE_OPTIONAL_HEADER.Magic est égal à IMAGE_NT_OPTIONAL_HDR64_MAGIC qui est faux https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

ok essayez ceci:

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

ce n'est pas compressé par upx

Le 14 février 2016 à 05:10, anatoly techtonik [email protected]
a écrit:

@ punto- https://github.com/punto- son IMAGE_OPTIONAL_HEADER.Magic est
égal à IMAGE_NT_OPTIONAL_HDR64_MAGIC qui est faux
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183846301.

Toujours le même problème. depends pense qu'il s'agit d'un binaire 64 bits, et pas seulement 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

C'est un utilitaire unix, btw.

@Hinsbart Pouvez-vous essayer ce http://tof.p1x.in/html5/ sur l'ordinateur où vous obtenez l'écran gris et cette erreur? prétendument chrome utilise le même code pour son moteur de rendu.

@techtonik peut-être que j'ai ce bogue où j'utilise bits = 32 et j'obtiens en fait un binaire 64 bits?

@ punto- Je ne sais pas comment vous le compilez ou à quel bogue fait référence. Les commandes et les journaux de construction peuvent le clarifier. Je peux le compiler moi-même si vous êtes prêt à valider vos modifications dans une branche.

ouais je suis dessus

ici c'est https://github.com/punto-/godot/tree/angle

Le 15 février 2016 à 14h53, anatoly techtonik [email protected]
a écrit:

@ punto- https://github.com/punto- Je ne sais pas comment le compiler ou
à quel bogue se réfère. Les commandes et les journaux de construction peuvent le clarifier. je peux
compilez-le moi-même si vous êtes prêt à valider vos modifications dans une branche.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184323695.

Compiler avec angle = oui

Le 15 février 2016 à 15h25, Ariel Manzur [email protected] a écrit:

ici c'est https://github.com/punto-/godot/tree/angle

Le 15 février 2016 à 14h53, anatoly techtonik [email protected]
a écrit:

@ punto- https://github.com/punto- Je ne sais pas comment le compiler
ou à quel bogue se réfèrent. Les commandes et les journaux de construction peuvent le clarifier. je
pouvez le compiler moi-même si vous êtes prêt à valider vos modifications
branche.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
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.

Pas de chance.

essayez aussi avec theora_opt = no

Le 15 février 2016 à 18h40, anatoly techtonik [email protected]
a écrit:

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: construction terminée en raison d'erreurs.

Pas de chance.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
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>
                            ^

Arrêt complet?

Eh bien c'est le point d'angle, il utilise la 3D directe au lieu de opengl: p

Le 15 février 2016 à 18h57, anatoly techtonik [email protected]
a écrit:

Dans le fichier inclus à partir de drivers \ angle / common / angleutils.h: 12: 0,
à partir des pilotes \ angle \ common \ angleutils. cpp: 7 :
drivers \ angle / common / platform.h: 62: 28: erreur fatale: d3d11_1.h: aucun fichier ou répertoire de ce type
# comprendre
^

Arrêt complet?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184411949.

ANGLE a deux backends - le plus ancien utilise DirectX 9. Je télécharge le nouveau MinGW avec les en-têtes DirectX 11 en ce moment.

le contexte est créé dans platform / windows / gl_context_egl_angle.cpp, I
pense qu'il y avait un paramètre là pour choisir le backend .. je pense que le
problème est dans ce fichier, il pourrait y avoir un moyen de détecter quels paramètres sont
le meilleur pour le système ..

Le 16 février 2016 à 05h51, anatoly techtonik [email protected]
a écrit:

ANGLE a deux backends - le plus ancien utilise DirectX 9. Je télécharge le plus récent
MinGW avec en-têtes DirectX 11 en ce moment.

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184580963.

Beaucoup d'erreurs avec la nouvelle version de gcc 5.3.0, par exemple:

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;
                     ^
...

Vous devez ajouter -std=c++11 aux indicateurs C ++, je suppose.
par exemple, ajoutez cette ligne après: https://github.com/punto-/godot/blob/angle/drivers/angle/SCsub#L276

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

Je ne sais pas si la syntaxe fonctionnerait pour MSVC, mais avec MinGW, cela devrait être correct.

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

Besoin d'attendre la nouvelle version de MinGW .

Peut-être que la discussion sur ANGLE devrait être déplacée vers un autre problème, en gardant celui-ci pour "dire à l'utilisateur que son matériel est ancien et non pris en charge avant de planter"?

Oui je suis d'accord

Le 17 février 2016 à 13h25, Rémi Verschelde [email protected]
a écrit:

Peut-être que la discussion sur ANGLE devrait être déplacée vers une question distincte,
garder celui-ci pour "dire à l'utilisateur que son matériel est ancien et
non pris en charge avant de planter "?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -185282158.

3634 est le problème ANGLE. # 3694 est PR pour obtenir plus d'informations lors du chargement du moteur.

@ Heybye44

Pourquoi Godot fonctionne-t-il comme par magie sur Ubuntu mais pas sur Windows?

Oui! J'aimerais aussi connaître la raison. Cela fonctionne lorsque j'ai testé avec Xubuntu mais pas sur aucune des éditions de Windows.

^^

Il ne s'agit pas du système d'exploitation, mais des pilotes. En général, les pilotes GL sont négligés sous Windows par rapport à Linux, grâce à Direct3D. De nombreux GPU plus anciens se retrouvent avec une implémentation minimale de GL 1.5 sur les nouvelles versions de Windows.

@adolson

De nombreux GPU plus anciens se retrouvent avec une implémentation minimale de GL 1.5 sur les nouvelles versions de Windows.

Alors quand les versions antérieures d'OpenGL seront-elles prises en charge dans Godot? Existe-t-il une nécessité explicite absolue de s'appuyer sur 2.0+? Ce n'est pas comme si la rétrocompatibilité n'existait pas, donc un appareil plus performant n'échouera pas pour rendre une itération antérieure d'OpenGL. Existe-t-il des fonctionnalités de l'éditeur visuel lui-même construites autour de GLES2 qui ne pourraient pas être réduites pour utiliser GL1.4 à la place? Je veux dire, la plupart des dernières fonctionnalités de GL sont de toute façon destinées au rendu 3D, ce qui est inutile si l'on veut créer un jeu 2D avec Godot.

@WinnerEX Cela n'arrivera pas. Être compatible avec GL 1.4 signifierait abandonner de nombreuses fonctionnalités intéressantes qui sont utilisées à la fois pour la 2D et la 3D; et à l'autre bout du spectre, nous avons des gens qui ne peuvent plus attendre le support de GL 3+ ou même Vulkan. Vous pouvez sans risque considérer Godot comme un moteur GL 2.1+; si ce n'est pas ce que vous voulez, il existe de nombreux autres moteurs qui pourraient avoir des restrictions GL plus faibles (par exemple OGRE 1.9 ou SDL 2.0).

Le sujet ici est que Godot devrait donner une erreur appropriée lorsque les fonctionnalités GL 2.1+ requises ne sont pas disponibles au lieu de planter; il n'y a aucune intention de réécrire un moteur de rendu GLES1. Pour les utilisateurs de Windows, il peut y avoir un certain espoir si ANGLE est intégré pour l'émulation GL via Direct3D, mais il n'y aura pas de rétrogradation du moteur de rendu GLES2.

Retour au sujet: @reduz , j'ai pensé qu'il serait possible de reproduire le crash même sur du matériel compatible GL 2.1 en essayant de charger Godot dans une machine virtuelle sans accélération 2D et 3D. Je vais essayer dès que possible pour confirmer, mais cela pourrait aider à savoir où il se bloque et comment renflouer correctement avec un message d'erreur lisible par l'homme au lieu de segfaulting.

J'ai pensé qu'il serait possible de reproduire le crash même sur du matériel compatible GL 2.1 en essayant de charger Godot dans une machine virtuelle sans accélération 2D et 3D. Je vais essayer dès que possible pour confirmer

D'accord, on dirait qu'avec VirtualBox 5, ce n'est pas facile car il dispose maintenant d'un pilote GL décent qui prend en charge jusqu'à OpenGL 3.0 xD.

opengl 3.0 est plus facile à détecter, car vous devez demander un conext spécial
(Je hopt)

Le lun 25 juil.2016 à 12:28 PM, Rémi Verschelde [email protected]
a écrit:

Je pensais qu'il serait peut-être possible de reproduire le crash même sur GL 2.1
matériel capable en essayant de charger Godot dans une machine virtuelle sans 2D
et accélération 3D. Je vais essayer dès que possible pour confirmer

D'accord, on dirait qu'avec VirtualBox 5, ce n'est pas facile car il a maintenant un bon
Pilote GL qui prend en charge jusqu'à OpenGL 3.0 xD.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -234987968,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AF-Z2_MK5iQA0RxLwv0FHu6po8ucVE8kks5qZNYlgaJpZM4DQoN3
.

Je viens de faire un test sur mon ancien netbook avec un igp intel merdique incompatible, sous Windows.

À la ligne 10791 de rasterizer_gles2.cpp , dans RasterizerGLES2::init() j'ai ajouté ces quelques lignes:

    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 plante toujours, mais il affiche ce message d'erreur dans la console juste avant de s'évanouir.

Je ne sais pas comment dire à Godot d'annuler l'initialisation du rasterizer (RasterizerGLES2 :: init () ne retourne pas vrai / faux, c'est comme s'il n'avait d'autre choix que le succès ou le crash), ni je ne sais comment dire à Godot de quitter correctement.

Même si ce test de compatibilité n'est peut-être pas fiable à 100%, il pourrait au moins réduire le nombre de plantages silencieux et afficher une petite boîte de dialogue système avertissant l'utilisateur qu'il va planter et pourquoi.

Super trouvaille @SuperUserNameMan. J'ai joué un peu avec et je confirme que cela fonctionne (au moins dans mes tests où j'ai vérifié if (glewIsSupported("GL_VERSION_2_1")) puisque mon GPU le prend en charge). Nous pouvons utiliser OS::alert() pour afficher une boîte de message de blocage.

Comme vous l'avez mentionné, la seule partie manquante (et la plus difficile) est de laisser Godot sortir correctement. J'ai jeté un coup d'œil rapide, mais mes compétences dépassent largement mes compétences pour que Godot s'arrête au milieu de l'initialisation de son système d'exploitation.

Voici un diff de la preuve de 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

Pour pouvoir tester les personnes avec le support GL 2.1, supprimez simplement le ! dans le test if.

Il génère cette boîte de message (bloquante) sur X11:

Après avoir discuté avec @reduz , il semble que mon correctif ci-dessus pourrait être assez bon comme première étape; puisque l'alerte du système d'exploitation se bloque, nous pouvons informer les gens du problème et les avertir que Godot va planter :) Quitter proprement serait bien sûr mieux, mais cette solution intermédiaire est déjà agréable à avoir.

pour tester sous linux sans changer le code et recompiler, je pense que vous pouvez définir la variable d'environnement MESA_GL_VERSION_OVERRIDE sur 2.0: http://www.mesa3d.org/envvars.html

IIRC, c'est aussi comment procéder pour forcer MESA à autoriser le GPU sur liste noire à fonctionner avec Godot.