+1

+10

+1

escribí ese código en context_gl_win.cpp pero generalmente falla debido a
alguna función no implementada en Windows debido a un controlador de mierda
Ojalá pudiera averiguar exactamente por qué

El sábado 17 de enero de 2015 a las 2:56 p.m., MSC [email protected] escribió:

+1

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/okamstudio/godot/issues/1162#issuecomment -70376758.

Establecer esto como alta prioridad por ahora, ya que sería una característica muy útil. Recibimos toneladas de informes de fallas debido a que las personas tienen IGP de Intel muy antiguos o cosas por el estilo que no son compatibles con GLES2.

Ok, supongo que hice referencia a suficientes bloqueos para subrayar mis "toneladas" anteriores, dejaré de buscar en los archivos:

+1 ¿Por qué Godot funciona mágicamente en Ubuntu pero no en Windows?

¿Alguna idea de cómo se podría implementar esto @reduz?

escribí ese código en context_gl_win.cpp pero generalmente falla debido a alguna función no implementada en Windows

Entonces, ¿por qué no utilizar enlaces dinámicos? Será obvio qué función falta. Creo que https://github.com/p3/regal hace esto.

Ya hice la detección e intenté mostrar un mensaje, pero parece que
todavía no funciona.
Como no tengo ningún hardware no compatible, no puedo ver por qué falla y
por lo tanto, no puedo arreglarlo.
Relaciones públicas bienvenidas.

El martes 2 de febrero de 2016 a las 12:11 p.m., anatoly techtonik < [email protected]

escribió:

escribí ese código en context_gl_win.cpp pero generalmente falla debido a
alguna función no implementada en Windows

Entonces, ¿por qué no utilizar enlaces dinámicos? Será obvio qué función es
desaparecido. Creo que https://github.com/p3/regal hace esto.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -178624438.

Si alguien con una GPU vieja pudiera intentar ejecutar Godot a través de gdb en Linux, entonces podría ser muy útil. La información de depuración de la "firma del problema" de Windows parece bastante inútil: /

No estoy haciendo C ++ en absoluto. Solo Python, entonces soy un usuario. Dime qué ejecutar y es posible que obtenga la información.

Dime qué ejecutar y es posible que obtenga la información.

No tengo ni idea de cómo ejecutar cosas a través de un depurador en Windows, pero creo que no es trivial para las personas que no tienen mucha experiencia compilando cosas en Windows. Es por eso que sugerí que alguien intentara depurar con GDB en Linux, ya que es muy fácil de usar:

$ 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

y copie la salida de este comando bt (backtrace) a este informe de error.

Por supuesto, podría ser que el problema sea específico de Windows, por lo que la depuración en Linux no tendría sentido, pero creo que los usuarios de Linux también tenían segfaults que no fueron detectados para decirle al usuario que su hardware no es compatible con OpenGL (ES) 2.1.

Beta 2.0 no se ejecuta en mi Linux, pero parece no estar relacionado con la tarjeta gráfica - # 3557

Jeje, tienes suerte de encontrarte con todos los problemas conocidos que tenemos en casos de esquina :)

Supongo que solo tengo un "talento para quejarse" y una cuenta de GitHub. =)

No conozco tarjetas de video tan antiguas que se bloquean al inicio, pero, por ejemplo, en NVIDIA 6800 GT,
se bloquea solo en algunos proyectos. Entonces, hay una salida de cmd sobre errores de framebuffer en todos los proyectos y módulos Godot. Puede solucionarse por completo desactivando la configuración "fp16_framebuffer" en la configuración del rasterizador del proyecto. Lo sé, en las mismas tarjetas de video (no sé acerca de la conexión completa), hay rasterizado incorrecto (sin texturas) lo que se puede arreglar por completo deshabilitando la configuración "fragment_lighting".
Así que creo que Godot debería comprobar si estas funciones son compatibles y, si no, anotar al usuario y desactivarlas.
Quizás también ayude con el bloqueo al inicio.

Dime qué ejecutar y es posible que obtenga la información.

$ gdb / path / to / godot / binary // si es posible autocompilado en modo de depuración, para tener más información

Godot_v2.0_beta_20160205_x11.64 no se bloquea en Fedora 23 con el mismo hardware. Se detecta como Mobile Intel® GM45 Express Chipset allí.

Godot_v2.0_beta_20160205_win32.exe todavía se bloquea en Vista 32.

@techtonik Creo que la razón es que Linux, a diferencia de Windows, usa la realización de software para OpenGL cuando hay problemas con el hardware OpenGL, pero es más lento que el hardware, por supuesto.

@ Algrin6 sería bueno si el motor pudiera proporcionar algo de transparencia sobre ese hecho. En los viejos tiempos, juegos como Baldur's Gate se enviaban con binarios de prueba de gráficos. 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 de memoria! Y ahora tengo 3 GB + 3 GHz y no puedo ejecutar el motor del juego. ¿Cómo?

¡2 MB de memoria! Y ahora tengo 3 GB + 3 GHz y no puedo ejecutar el motor del juego. ¿Cómo?

¿Porque estamos en 2016 y ese motor Bioware es muy antiguo? Y esta prueba fue diseñada para verificar si el controlador de gráficos es lo suficientemente potente, por lo que probablemente la prueba _funcionando_ comenzando con DirectX 3.01a, pero tal vez diciendo "actualice su hardware o controladores" si estaba por debajo de DirectX 7 o algo así. Y el motor Bioware funcionaba únicamente en MS Windows <= XP, mientras que Godot funciona en una docena de plataformas ...

Ahora que parece que sabe exactamente lo que tenemos que hacer, haga una solicitud de extracción.

El principal problema de

La puerta de Baldur no está programada en un motor de juego 2D / 3D de propósito general.
Está programado a medida en C, ensamblador x86, probablemente Watcom
compilador, modo protegido y utiliza una máquina de pila básica para la creación de scripts. también
siéntase libre de hacer todo el código blitting personalizado usted mismo.

El domingo 7 de febrero de 2016 a las 12:36 p. M., George Marques [email protected]
escribió:

@techtonik https://github.com/techtonik El principal problema de esto es
que ninguno de los desarrolladores principales tiene hardware antiguo para probar el problema. Entonces
tiene que proporcionar información de depuración para identificar la causa del problema o
arréglelo usted mismo (que es la belleza del código abierto).

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -181034018.

@reduz ¿ Puede Godot producir una "tabla de compatibilidad de plataformas" para el código producido por el motor (o utilizado por el editor) que enumere todas las funciones que utiliza actualmente el juego (blitting, partículas, objetos 3D, ...)?

Si eso es imposible en este momento, ¿es al menos técnicamente factible?

El caso de uso para la validación es poder producir un juego mínimo (prueba) que pueda ejecutar en cualquier dispositivo blitting y medir el rendimiento.

@reduz ¿Qué hay de https://github.com/godotengine/godot/issues/1162#issuecomment -180466018?

@ Algrin6 No tiene sentido comprobar si esas cosas son compatibles con versiones anteriores de OpenGL. Estas GPU tienen controladores que le dicen a OpenGL que todo es compatible, luego entran en una especie de respaldo de software extraño que es lento, se congela o se bloquea.

Prefiero fingir que un hardware tan antiguo no existe y se ha caído del planeta.

Creo que eso significa que "los parches son bienvenidos". Dudo mucho que alguien los rechace.
apoyo bien hecho para
plataforma más antigua.

El jueves 11 de febrero de 2016 a las 3:41 a.m., Juan Linietsky [email protected]
escribió:

@ Algrin6 https://github.com/Algrin6 No tiene sentido comprobar si eso
cosas es compatible con versiones anteriores de OpenGL. Estas GPU tienen controladores
que le dicen a OpenGL que todo es compatible, luego entra en algún tipo de
software de respaldo extraño que es lento, se congela o se bloquea.

Prefiero fingir que un hardware tan antiguo no existe y ha caído
del planeta.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216.

Todavía estoy esperando que alguien con un chipset antiguo contribuya mejor
detección de hardware no compatible. No tengo nada de ese hardware desde
una década, así que no hay mucho que pueda hacer.

El miércoles 10 de febrero de 2016 a las 11:30 p.m., Sergey Lapin [email protected]
escribió:

Creo que eso significa que "los parches son bienvenidos". Dudo mucho que alguien los rechace.
apoyo bien hecho para
plataforma más antigua.

El jueves 11 de febrero de 2016 a las 3:41 a.m., Juan Linietsky [email protected]
escribió:

@ Algrin6 https://github.com/Algrin6 No tiene sentido comprobar si eso
cosas es compatible con versiones anteriores de OpenGL. Estas GPU tienen controladores
que le dicen a OpenGL que todo es compatible, luego entra en algún tipo de
software de respaldo extraño que es lento, se congela o se bloquea.

Prefiero fingir que un hardware tan antiguo no existe y ha caído
del planeta.

-
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389.

Tengo acceso a la tienda con PC desde los 80 hasta principios del 2000, si eso ayuda,
pero necesito algunos detalles sobre cómo probar y depurar, ya que no estoy
desarrollador de Windows de ninguna manera y no tengo ideas sobre herramientas, etc.
Tenga un juego de i740s con cajas win95se2, algunos Pentim233MMX incluso.
Debido a la contabilidad, esto no se desechará hasta 2025.

Por cierto, Juan, ¿podrías contactarme por correo electrónico para que tenga tu dirección personal?
No lo bombardearé con nada estúpido.

El jueves 11 de febrero de 2016 a las 5:48 a. M., Juan Linietsky [email protected]
escribió:

Todavía estoy esperando que alguien con un chipset antiguo contribuya mejor
detección de hardware no compatible. No tengo nada de ese hardware desde
una década, así que no hay mucho que pueda hacer.

El miércoles 10 de febrero de 2016 a las 11:30 p.m., Sergey Lapin [email protected]
escribió:

Creo que eso significa "los parches son bienvenidos". Realmente dudo que alguien lo haga
rechazar
apoyo bien hecho para
plataforma más antigua.

El jueves 11 de febrero de 2016 a las 3:41 AM, Juan Linietsky <
[email protected]>
escribió:

@ Algrin6 https://github.com/Algrin6 No tiene sentido comprobar si eso
cosas es compatible con versiones anteriores de OpenGL. Estas GPU tienen controladores
que le dicen a OpenGL que todo es compatible, luego entra en algún tipo
de
software de respaldo extraño que es lento, se congela o se bloquea.

Prefiero fingir que un hardware tan antiguo no existe y tiene
caído
del planeta.

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182678470.

No necesitas ir tan atrás. Solo Intel Series 3/4 o i940 es
lo suficiente para hacer que se estrelle ...
Simplemente compile con mingw / msvc e intente averiguar por qué falla en su lugar
de mostrar un cuadro de mensaje que el hardware no es compatible

El jueves 11 de febrero de 2016 a las 12:00 a. M., Sergey Lapin [email protected]
escribió:

Tengo acceso a la tienda con PC desde los 80 hasta principios del 2000, si eso ayuda,
pero necesito algunos detalles sobre cómo probar y depurar, ya que no estoy
desarrollador de Windows de ninguna manera y no tengo ideas sobre herramientas, etc.
Tenga un juego de i740s con cajas win95se2, algunos Pentim233MMX incluso.
Debido a la contabilidad, esto no se desechará hasta 2025.

Por cierto, Juan, ¿podrías contactarme por correo electrónico para que tenga tu dirección personal?
No lo bombardearé con nada estúpido.

El jueves 11 de febrero de 2016 a las 5:48 a. M., Juan Linietsky [email protected]

escribió:

Todavía estoy esperando que alguien con un chipset antiguo contribuya mejor
detección de hardware no compatible. No tengo nada de ese hardware
ya que
una década, así que no hay mucho que pueda hacer.

El miércoles 10 de febrero de 2016 a las 11:30 p.m., Sergey Lapin < [email protected]

escribió:

Creo que eso significa "los parches son bienvenidos". Realmente dudo que alguien lo haga
rechazar
apoyo bien hecho para
plataforma más antigua.

El jueves 11 de febrero de 2016 a las 3:41 AM, Juan Linietsky <
[email protected]>
escribió:

@ Algrin6 https://github.com/Algrin6 No tiene sentido comprobar si
ese
cosas es compatible con versiones anteriores de OpenGL. Estas GPU tienen
conductores
que le dicen a OpenGL que todo es compatible, luego entra en algún tipo
de
software de respaldo extraño que es lento, se congela o se bloquea.

Prefiero fingir que un hardware tan antiguo no existe y tiene
caído
del planeta.

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

-
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182678470
.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182679526.

Compilado godot.windows.tools.32.exe con MinGW. Choques. ¿Qué hacer a continuación?

Lo único que se me ocurre es que necesitas depurar el bloqueo. Carné de identidad
comience con la función main () e imprima el nombre de cada función
se ejecuta hasta que se encuentra el que falla, luego simplemente agregue la impresión a
cada línea de función para encontrar la línea exacta donde
se bloquea e informa los resultados. Además, si lo compila mingw a medida que obtiene
dirección de bloqueo que puede usar
addr2line -e / ruta / a / debug / exe 0x

En realidad, MinGW parece enviarse con 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)

Según el rastro anterior, se bloquea en la línea:

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

¿Qué es lo siguiente?

salida 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 función es NULL porque el controlador no la proporciona, por eso
choques.

El 12 de febrero de 2016 a las 01:21, anatoly techtonik [email protected]
escribió:

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

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183174112.

@ punto- ¿dónde ves que es NULL?

en la parte superior del backtrace, marco 0, la dirección es 0x00000, así es como
se ve como cuando llamas a un puntero de función que es nulo

El 12 de febrero de 2016 a las 06:58, anatoly techtonik [email protected]
escribió:

@ punto- https://github.com/punto- ¿dónde ves que es NULL?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183257600.

Pero no entiendo: C ++ no es Python, por lo que cuando godot carga binaria, el sistema debería cargar la dll del controlador y fallar con la advertencia de que el símbolo dado no está presente. ¿Por qué no sucede?

¿O eso significa que Godot realmente implementa la vinculación dinámica en tiempo de ejecución, pero no advierte sobre símbolos faltantes?

glew hace la vinculación del tiempo de ejecución, por eso la función existe pero puede
a veces ser nulo ..

El 12 de febrero de 2016 a las 13:41, anatoly techtonik [email protected]
escribió:

¿O eso significa que Godot realmente implementa la vinculación dinámica en tiempo de ejecución,
pero no advierte sobre símbolos faltantes?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401773.

@ punto- esto no parece correcto. ¿Puede este GLEW inyectar sus propios stubs para estas funciones NULL que se quejan con error en lugar de segfaulting?

No lo sé ... tal vez ... sería una buena idea

El 12 de febrero de 2016 a las 15:01, anatoly techtonik [email protected]
escribió:

@ punto- https://github.com/punto- esto no parece correcto. Puedo ésto
GLEW inyecta sus propios stubs para estas funciones NULL que se quejan con
error en lugar de segfaulting?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183431329.

C ++ no es python, pero python es C :) glew probablemente busca los símbolos
y cuando no están presentes, asigna NULL al puntero de función. yo
aunque no recuerdo todos los detalles, pero así es como siempre falla,
cualquier función de gl es NULL ..

El 12 de febrero de 2016 a las 13:40, anatoly techtonik [email protected]
escribió:

Pero no entiendo: C ++ no es Python, por lo que cuando se carga el binario de godot, el
el sistema debe cargar el dll del controlador y fallar con la advertencia de que el símbolo dado es
no presente. ¿Por qué no sucede?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442.

¿Alguien con una de estas tarjetas Intel puede probar esta compilación?

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

El 12 de febrero de 2016 a las 15:45, Ariel Manzur [email protected] escribió:

C ++ no es python, pero python es C :) glew probablemente busca los símbolos
y cuando no están presentes, asigna NULL al puntero de función. yo
aunque no recuerdo todos los detalles, pero así es como siempre falla,
cualquier función de gl es NULL ..

El 12 de febrero de 2016 a las 13:40, anatoly techtonik [email protected]
escribió:

Pero no entiendo: C ++ no es Python, por lo que cuando se carga el binario de godot, el
el sistema debe cargar el dll del controlador y fallar con la advertencia de que el símbolo dado es
no presente. ¿Por qué no sucede?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442
.

vista 32

Son 32 bits ... ¿es posible que Windows solo acepte 64 bits?

El 14 de febrero de 2016 a las 01:29, anatoly techtonik [email protected]
escribió:

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

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183819635.

Caminantes de dependencia muestra que es un módulo de 64 bits vinculado a bibliotecas de 32 bits.

¿Dice cuál?

El 14 de febrero de 2016 a las 01:38, anatoly techtonik [email protected]
escribió:

Caminantes de dependencia muestra que es un módulo de 64 bits vinculado a bibliotecas de 32 bits.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237.

(también, ¿por qué funciona en mi computadora? ¿Es una cpu de 32 bits?)

El 14 de febrero de 2016 a las 01:52, Ariel Manzur [email protected] escribió:

¿Dice cuál?

El 14 de febrero de 2016 a las 01:38, anatoly techtonik [email protected]
escribió:

Caminantes de dependencia muestra que es un módulo de 64 bits vinculado a bibliotecas de 32 bits.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

¿Puedes probar este?

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

El 14 de febrero de 2016 a las 01:54, Ariel Manzur [email protected] escribió:

(también, ¿por qué funciona en mi computadora? ¿Es una cpu de 32 bits?)

El 14 de febrero de 2016 a las 01:52, Ariel Manzur [email protected] escribió:

¿Dice cuál?

El 14 de febrero de 2016 a las 01:38, anatoly techtonik < [email protected]

escribió:

Caminantes de dependencia muestra que es un módulo de 64 bits vinculado a bibliotecas de 32 bits.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

En mi vieja computadora portátil (intel gma x3100) no se bloquea, pero la ventana permanece gris con los siguientes errores:

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

¿Puede ser una versión de sombreadores demasiado antigua?
Pero es extraño que pruebe con D3D en lugar de GLSL ...

El domingo 14 de febrero de 2016 a las 9:03 a.m., Hondres [email protected] escribió:

En mi vieja computadora portátil (intel gma x3100) no se bloquea, pero la ventana permanece
gris con los siguientes errores:

ERROR: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: Program LINK FAILED:
Error al crear sombreadores D3D.
En: drivers \ gles2 \ shader_gles2. cpp: 544
ERROR: ShaderGLES2 :: get_current_version: Método / Función Falló, devolviendo: 0
En: drivers \ gles2 \ shader_gles2. cpp: 551
ERROR: ShaderGLES2 :: bind: Condition '! Version' es verdadera. devuelto: falso
En: drivers \ gles2 \ shader_gles2. cpp: 126
ERROR: ShaderGLES2 :: _ get_uniform: La condición '! Versión' es verdadera. devuelto: -1
En:. \ Drivers / gles2 / shader_gles2.h: 354

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183827627.

Entonces, ¿ha existido alguna vez un caso en el que los gráficos funcionen usando un ángulo y no gl directamente?

El 14 de febrero de 2016 a las 03:25, Sergey Lapin [email protected] escribió:

¿Puede ser una versión de sombreadores demasiado antigua?
Pero es extraño que pruebe con D3D en lugar de GLSL ...

El domingo 14 de febrero de 2016 a las 9:03 a.m., Hondres [email protected] escribió:

En mi vieja computadora portátil (intel gma x3100) no se bloquea, pero la ventana permanece
gris con los siguientes errores:

ERROR: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: Programa LINK
HA FALLADO:
Error al crear sombreadores D3D.
En: drivers \ gles2 \ shader_gles2. cpp: 544
ERROR: ShaderGLES2 :: get_current_version: Falló el método / función,
regresando: 0
En: drivers \ gles2 \ shader_gles2. cpp: 551
ERROR: ShaderGLES2 :: bind: Condition '! Version' es verdadera. devuelto: falso
En: drivers \ gles2 \ shader_gles2. cpp: 126
ERROR: ShaderGLES2 :: _ get_uniform: La condición '! Versión' es verdadera.
devuelto: -1
En:. \ Drivers / gles2 / shader_gles2.h: 354

-
Responda a este correo electrónico directamente o véalo en GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -183827627
.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183830014.

Las herramientas @ punto- informan que godot.windows.tools.angle.32.exe no es un ejecutable PE válido. ¿Puedes publicar una versión que no haya sido tocada por UPX?

Su IMAGE_OPTIONAL_HEADER.Magic es igual a IMAGE_NT_OPTIONAL_HDR64_MAGIC que es incorrecto https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

ok prueba esto:

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

no está comprimido por upx

El 14 de febrero de 2016 a las 05:10, anatoly techtonik [email protected]
escribió:

@ punto- https://github.com/punto- su IMAGE_OPTIONAL_HEADER.Magic es
igual a IMAGE_NT_OPTIONAL_HDR64_MAGIC que es incorrecto
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183846301.

Sigue siendo el mismo problema. depends piensa que es binario de 64 bits, y no solo 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 una utilidad de Unix, por cierto.

@Hinsbart ¿Puedes probar esto http://tof.p1x.in/html5/ en la computadora donde aparece la pantalla gris y ese error? supuestamente Chrome usa el mismo código para su renderizador ..

@techtonik, ¿ tal vez tengo ese error en el que uso bits = 32 y en realidad obtengo un binario de 64 bits?

@ punto- No sé cómo se compila ni a qué error se refiere. Los comandos y los registros de compilaciones pueden aclararlo. Puedo compilarlo yo mismo si está listo para enviar sus cambios a alguna rama.

si estoy en eso

aquí está https://github.com/punto-/godot/tree/angle

El 15 de febrero de 2016 a las 14:53, anatoly techtonik [email protected]
escribió:

@ punto- https://github.com/punto- No sé cómo lo compilas o
a qué error se refiere. Los comandos y los registros de compilaciones pueden aclararlo. puedo
compílelo yo mismo si está listo para enviar sus cambios a alguna rama.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184323695.

Compilar con ángulo = sí

El 15 de febrero de 2016 a las 15:25, Ariel Manzur [email protected] escribió:

aquí está https://github.com/punto-/godot/tree/angle

El 15 de febrero de 2016 a las 14:53, anatoly techtonik [email protected]
escribió:

@ punto- https://github.com/punto- No se como lo compilas
o a qué error se refiere. Los comandos y los registros de compilaciones pueden aclararlo. yo
puedo compilarlo yo mismo si está listo para confirmar sus cambios en algunos
rama.

-
Responda a este correo electrónico directamente o véalo en 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.

Sin suerte.

prueba también con theora_opt = no

El 15 de febrero de 2016 a las 18:40, anatoly techtonik [email protected]
escribió:

scons: *** [drivers \ theora \ theora \ x86 \ mmxencfrag.windows.tools.32.o] Fuente drivers\theora\theora\x86\mmxencfrag.c' not found, needed by target drivers \ theora \ theora \ x86 \ mmxencfrag.windows.tools.32.o '.
scons: edificio terminado debido a errores.

Sin suerte.

-
Responda a este correo electrónico directamente o véalo en 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>
                            ^

¿Parada completa?

Bueno, ese es el punto de ángulo, usa 3d directo en lugar de opengl: p

El 15 de febrero de 2016 a las 18:57, anatoly techtonik [email protected]
escribió:

En el archivo incluido de drivers \ angle / common / angleutils.h: 12: 0,
desde drivers \ angle \ common \ angleutils. cpp: 7 :
drivers \ angle / common / platform.h: 62: 28: error fatal: d3d11_1.h: no existe tal archivo o directorio
# incluir
^

¿Parada completa?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184411949.

ANGLE tiene dos backends: uno más antiguo usa DirectX 9. Estoy descargando un MinGW más nuevo con encabezados DirectX 11 en este momento.

el contexto se crea en la plataforma / windows / gl_context_egl_angle.cpp, yo
creo que había un parámetro para elegir el backend. Creo que el
problema está en ese archivo, podría haber una manera de detectar qué parámetros están
mejor para el sistema ..

El 16 de febrero de 2016 a las 05:51, anatoly techtonik [email protected]
escribió:

ANGLE tiene dos backends: el más antiguo usa DirectX 9. Estoy descargando el más nuevo
MinGW con encabezados DirectX 11 ahora mismo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184580963.

Muchos errores con gcc 5.3.0 más reciente, por ejemplo:

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

Necesita agregar -std=c++11 a las banderas de C ++, supongo.
por ejemplo, agregue esta línea después de: https://github.com/punto-/godot/blob/angle/drivers/angle/SCsub#L276

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

Sin embargo, no estoy seguro de si la sintaxis funcionaría para MSVC, pero con MinGW debería estar bien.

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

Necesito esperar al nuevo lanzamiento de MinGW .

¿Quizás la discusión sobre ANGLE debería moverse a un tema separado, manteniendo este para "decirle al usuario que su hardware es viejo y no es compatible antes de fallar"?

si estoy de acuerdo

El 17 de febrero de 2016 a las 13:25, Rémi Verschelde [email protected]
escribió:

Quizás la discusión sobre ANGLE debería trasladarse a un tema separado,
manteniendo este para "decirle al usuario que su hardware es antiguo y
sin soporte antes de estrellarse "?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -185282158.

3634 es el problema del ÁNGULO. # 3694 es PR para obtener más información al cargar el motor.

@ Heybye44

¿Por qué Godot funciona mágicamente en Ubuntu pero no en Windows?

¡Si! También me gustaría saber el motivo. Funciona cuando probé con Xubuntu pero no en ninguna de las ediciones de Windows.

^^

No se trata del sistema operativo, se trata de los controladores. En general, los controladores GL se descuidan en Windows en comparación con Linux, gracias a Direct3D. Muchas GPU antiguas terminan con una implementación mínima de GL 1.5 en las versiones más recientes de Windows.

@adolson

Muchas GPU antiguas terminan con una implementación mínima de GL 1.5 en las versiones más recientes de Windows.

Entonces, ¿cuándo serán compatibles las versiones anteriores de OpenGL en Godot? ¿Existe una necesidad explícita absoluta de confiar en 2.0+? No es como si no existiera la compatibilidad con versiones anteriores, por lo que un dispositivo más capaz no fallará en la representación de una iteración anterior de OpenGL. ¿Hay características del editor visual en sí construido alrededor de GLES2 que no se puedan reducir para usar GL1.4 en su lugar? Quiero decir, la mayoría de las funciones de GL posteriores son para renderizado 3D de todos modos, lo que es innecesario cuando se trata de la perspectiva de intentar crear un juego 2D con Godot.

@WinnerEX Eso no sucederá. Ser compatible con GL 1.4 significaría renunciar a muchas características interesantes que se utilizan tanto para 2D como para 3D; y en el otro extremo del espectro tenemos personas que no pueden esperar más por el soporte GL 3+ o incluso Vulkan. Puede considerar con seguridad a Godot como un motor GL 2.1+; si eso no es lo que desea, hay muchos otros motores que pueden tener restricciones GL más bajas (por ejemplo, OGRE 1.9 o SDL 2.0).

El tema aquí es que Godot debería dar un error adecuado cuando las características requeridas de GL 2.1+ no están disponibles en lugar de fallar; no hay intención de reescribir un renderizador GLES1. Para los usuarios de Windows, puede haber alguna esperanza si ANGLE se integra para la emulación GL a través de Direct3D, pero no habrá una degradación del renderizador GLES2.

Volviendo al tema: @reduz , pensé que podría ser posible reproducir el bloqueo incluso en hardware compatible con GL 2.1 al intentar cargar Godot en una máquina virtual sin aceleración 2D y 3D. Lo intentaré lo antes posible para confirmarlo, pero eso podría ayudar a descubrir dónde falla y cómo rescatar correctamente con un mensaje de error legible por humanos en lugar de segfaulting.

Pensé que sería posible reproducir el fallo incluso en hardware compatible con GL 2.1 al intentar cargar Godot en una máquina virtual sin aceleración 2D y 3D. Lo intentaré lo antes posible para confirmar

Muy bien, parece que con VirtualBox 5 no es fácil, ya que ahora tiene un controlador GL decente que admite hasta OpenGL 3.0 xD.

opengl 3.0 es más fácil de detectar, porque hay que solicitar un conector especial
(Yo esperaba)

El lunes 25 de julio de 2016 a las 12:28 p.m., Rémi Verschelde [email protected]
escribió:

Pensé que podría ser posible reproducir el bloqueo incluso en GL 2.1
hardware capaz al intentar cargar Godot en una máquina virtual sin 2D
y aceleración 3D. Lo intentaré lo antes posible para confirmar

Muy bien, parece que con VirtualBox 5 no es fácil ya que ahora tiene un buen
Controlador GL que admite hasta OpenGL 3.0 xD.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -234987968,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AF-Z2_MK5iQA0RxLwv0FHu6po8ucVE8kks5qZNYlgaJpZM4DQoN3
.

Acabo de hacer una prueba en mi viejo netbook con un intel igp de mierda incompatible, bajo Windows.

En la línea 10791 de rasterizer_gles2.cpp , en RasterizerGLES2::init() agregué estas pocas líneas:

    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 aún falla, pero muestra este mensaje de error en la consola justo antes de desmayarse.

No sé cómo decirle a Godot que cancele la inicialización del rasterizador (RasterizerGLES2 :: init () no devuelve verdadero / falso, es como si no tuviera más remedio que tener éxito o fallar), ni sé cómo decirle a Godot que salga correctamente.

Incluso si esta prueba de compatibilidad podría no ser 100% confiable, al menos podría reducir el número de bloqueos silenciosos y mostrar un pequeño cuadro de diálogo del sistema advirtiendo al usuario que se bloqueará y por qué.

Increíble encontrar @SuperUserNameMan. Jugué un poco con él y confirmo que funciona (al menos en mis pruebas donde verifiqué if (glewIsSupported("GL_VERSION_2_1")) ya que mi GPU lo admite). Podemos usar OS::alert() para mostrar un cuadro de mensaje de bloqueo.

Como mencionaste, la única parte que falta (y la más difícil) es dejar que Godot salga correctamente. Eché un vistazo rápido, pero está muy por encima de mis habilidades hacer que Godot se cierre en medio de la inicialización del sistema operativo.

Aquí hay una diferencia de la prueba de concepto:

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

Para poder realizar pruebas para personas con soporte GL 2.1, simplemente elimine ! en la prueba if.

Genera este cuadro de mensaje (bloqueo) en X11:

Después de discutir con @reduz , parece que mi parche anterior podría ser lo suficientemente bueno como primer paso; dado que la alerta del sistema operativo está bloqueando, podemos informar a la gente sobre el problema y advertirles que Godot se bloqueará :) Por supuesto, salir limpiamente sería mejor, pero ya es bueno tener esta solución intermedia.

para probar en linux sin cambiar el código y recompilar, creo que puede configurar la variable de entorno MESA_GL_VERSION_OVERRIDE en 2.0: http://www.mesa3d.org/envvars.html

IIRC, así es como se procedió a obligar a MESA a permitir que la GPU de la lista negra funcionara con Godot.