+1

+10

+1

escrevi esse código em context_gl_win.cpp, mas geralmente trava devido a
alguma função não implementada no Windows devido a um driver de merda
Eu gostaria de poder descobrir exatamente o porquê

No sábado, 17 de janeiro de 2015 às 14h56, MSC [email protected] escreveu:

+1

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1162#issuecomment -70376758.

Definir isso como alta prioridade por enquanto, pois seria um recurso muito útil. Recebemos toneladas de relatórios de travamentos devido a pessoas que têm IGPs Intel muito antigos ou outros enfeites que não suportam GLES2.

Ok, acho que já referenciei travamentos suficientes para sublinhar minhas "toneladas" acima, vou parar de vasculhar os arquivos: D

+1 Por que Godot funciona magicamente no Ubuntu, mas não no Windows?

Alguma ideia de como isso poderia ser implementado @reduz?

Eu escrevi esse código em context_gl_win.cpp, mas ele geralmente trava devido a alguma função não implementada no Windows

Por que não usar links dinâmicos então? Será óbvio qual função está faltando. Eu acredito que https://github.com/p3/regal faz isso.

Já fiz detecção e tentei mostrar uma mensagem, mas parece que
ainda não funciona.
Como eu não tenho nenhum hardware sem suporte, não consigo ver porque ele trava e
portanto, não é possível consertá-lo.
PRs bem-vindos.

Na terça-feira, 2 de fevereiro de 2016 às 12h11, anatoly techtonik < [email protected]

escrevi:

escrevi esse código em context_gl_win.cpp, mas geralmente trava devido a
alguma função não implementada no Windows

Por que não usar links dinâmicos então? Será óbvio qual função é
ausência de. Eu acredito que https://github.com/p3/regal faz isso.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -178624438.

Se alguém com uma GPU antiga pudesse tentar executar Godot por meio do gdb no Linux, isso seria bastante útil. As informações de depuração de "assinatura de problema" do Windows parecem bastante inúteis: /

Não estou fazendo C ++ de jeito nenhum. Apenas Python, então sou um usuário. Diga-me o que executar e posso obter as informações.

Diga-me o que executar e posso obter as informações.

Não tenho ideia de como executar coisas por meio de um depurador no Windows, mas acho que não é trivial para pessoas que não têm muita experiência em compilar coisas no Windows. É por isso que sugeri que alguém tentasse depurar com GDB no Linux, pois é muito 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

e copie a saída deste comando bt (backtrace) para este relatório de bug.

Claro que pode ser que o problema seja específico do Windows, portanto, a depuração no Linux seria inútil, mas acredito que os usuários do Linux também tinham segfaults que não foram detectados para informar ao usuário que seu hardware não suporta OpenGL (ES) 2.1.

O Beta 2.0 não funciona no meu Linux, mas parece não ter relação com a placa de vídeo - # 3557

Hehe você é um sortudo por se deparar com todos os problemas conhecidos que temos em casos secundários :)

Acho que só tenho um "talento para reclamar" e uma conta no GitHub. =)

Não sei sobre essas placas de vídeo antigas que travam na inicialização, mas em, por exemplo, no NVIDIA 6800 GT,
ele trava apenas em alguns projetos. Portanto, há uma saída cmd sobre erros de framebuffer em todos os projetos e módulos Godot. Ele pode ser totalmente corrigido desativando a configuração "fp16_framebuffer" nas configurações do rasterizador do projeto. Eu sei, nas mesmas placas de vídeo (não sei sobre conexão completa), há rasterização errada (sem texturas) o que pode ser totalmente corrigido desabilitando a configuração "fragment_lighting".
Então eu acho que Godot deveria verificar se essas funções são suportadas, e se não, observe o usuário e desabilite-as.
Talvez ajude com o travamento na inicialização também.

Diga-me o que executar e posso obter as informações.

$ gdb / path / to / godot / binary // se possível, auto-compilado no modo de depuração, para ter mais informações

Godot_v2.0_beta_20160205_x11.64 não trava no Fedora 23 com o mesmo hardware. Foi detectado como Mobile Intel® GM45 Express Chipset lá.

Godot_v2.0_beta_20160205_win32.exe ainda trava no Vista 32.

@techtonik Acho que o motivo é que o Linux, ao contrário do Windows, usa a realização de software para OpenGL quando há problemas com o OpenGL de hardware, mas é mais lento do que o de hardware, é claro.

@ Algrin6 seria bom se o motor pudesse fornecer alguma transparência sobre esse fato. Nos velhos tempos, jogos como Baldur's Gate eram enviados com binários de teste 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 memória! E agora tenho 3 GB + 3 GHz e não consigo executar o mecanismo de jogo. Por quê?

2 MB de memória! E agora tenho 3 GB + 3 GHz e não consigo executar o mecanismo de jogo. Por quê?

Porque estamos em 2016 e aquele motor Bioware é super antigo? E este teste foi projetado para verificar se o driver gráfico é poderoso o suficiente, então provavelmente o teste estava _funcionando_ começando com DirectX 3.01a, mas talvez dizendo "atualize seu hardware ou drivers" se você estava abaixo do DirectX 7 ou algo assim. E o motor Bioware funcionava exclusivamente em MS Windows <= XP, enquanto Godot trabalha em uma dúzia de plataformas ...

Agora, como você parece saber exatamente o que precisamos fazer, faça uma solicitação de pull.

O maior problema do

O portão de Baldur não é programado em um mecanismo de jogo 2D / 3D de propósito geral.
É programado sob medida em C, x86 assembler, provavelmente Watcom
compilador, modo protegido e usa uma máquina de pilha básica para scripts. Além disso
sinta-se à vontade para fazer todo o código de blitting personalizado sozinho.

No domingo, 7 de fevereiro de 2016 às 12h36, George Marques [email protected]
escrevi:

O principal problema de https://github.com/techtonik sobre isso é
que nenhum dos desenvolvedores principais tem hardware antigo para testar o problema. então
você deve fornecer informações de depuração para identificar a causa do problema ou
conserte você mesmo (que é a beleza do código aberto).

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -181034018.

@reduz pode Godot produzir uma "tabela de compatibilidade de plataforma" para o código produzido pelo motor (ou usado pelo editor) que lista todos os recursos que o jogo usa atualmente (blitting, partículas, objetos 3D, ...)?

Se isso é impossível no momento, é pelo menos tecnicamente viável?

O caso de uso para validação é ser capaz de produzir um jogo (teste) mínimo que possa ser executado em qualquer dispositivo de blitting e medir o desempenho.

@reduz E quanto a https://github.com/godotengine/godot/issues/1162#issuecomment -180466018?

@ Algrin6 É inútil verificar se esse material é compatível com versões anteriores do OpenGL. Essas GPUs têm drivers que informam ao OpenGL que tudo é compatível e, em seguida, entram em algum tipo de fallback de software bizarro que é lento, congela ou falha.

Prefiro fingir que esse hardware antigo não existe e caiu do planeta.

Acho que significa "patches são bem-vindos", duvido que alguém rejeite
suporte bem feito para
plataforma mais antiga.

Em quinta-feira, 11 de fevereiro de 2016 às 03h41, Juan Linietsky [email protected]
escrevi:

@ Algrin6 https://github.com/Algrin6 Não adianta verificar se isso
coisas são suportadas em versões mais antigas do OpenGL. Essas GPUs têm drivers
que dizem ao OpenGL que tudo é suportado, então vá para algum tipo de
fallback de software bizarro que é lento, congela ou falha.

Eu prefiro fingir que tal hardware antigo não existe e caiu
do planeta.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216.

Ainda estou esperando por alguém com um chipset antigo para contribuir melhor
detecção de hardware não suportado. Eu não tenho nenhum desse hardware desde
uma década, então não há muito que eu possa fazer.

Na quarta-feira, 10 de fevereiro de 2016 às 23h30, Sergey Lapin [email protected]
escrevi:

Acho que significa "patches são bem-vindos", duvido que alguém rejeite
suporte bem feito para
plataforma mais antiga.

Em quinta-feira, 11 de fevereiro de 2016 às 03h41, Juan Linietsky [email protected]
escrevi:

@ Algrin6 https://github.com/Algrin6 Não adianta verificar se isso
coisas são suportadas em versões mais antigas do OpenGL. Essas GPUs têm drivers
que dizem ao OpenGL que tudo é suportado, então vá para algum tipo de
fallback de software bizarro que é lento, congela ou falha.

Eu prefiro fingir que tal hardware antigo não existe e caiu
do planeta.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389.

Eu tenho acesso à loja com PCs dos anos 80 ao início de 2000, se isso ajudar,
mas preciso de alguns detalhes sobre como testar e depurar, pois não
desenvolvedor windows de qualquer forma e não tenho ideias sobre ferramentas, etc.
Tenho um conjunto de i740s com caixas win95se2, alguns Pentim233MMX até.
Devido à contabilidade, isso não será jogado fora até 2025.

btw, Juan você poderia entrar em contato comigo por e-mail para que eu tenha seu endereço pessoal?
Não vou bombardear com nada estúpido.

Na quinta-feira, 11 de fevereiro de 2016 às 5h48, Juan Linietsky [email protected]
escrevi:

Ainda estou esperando por alguém com um chipset antigo para contribuir melhor
detecção de hardware não suportado. Eu não tenho nenhum desse hardware desde
uma década, então não há muito que eu possa fazer.

Na quarta-feira, 10 de fevereiro de 2016 às 23h30, Sergey Lapin [email protected]
escrevi:

Acho que significa "patches são bem-vindos", duvido que alguém vá
rejeitar
suporte bem feito para
plataforma mais antiga.

Na quinta-feira, 11 de fevereiro de 2016 às 03h41, Juan Linietsky <
notificaçõ[email protected]>
escrevi:

@ Algrin6 https://github.com/Algrin6 Não adianta verificar se isso
coisas são suportadas em versões mais antigas do OpenGL. Essas GPUs têm drivers
que dizem ao OpenGL que tudo é suportado, então vá para algum tipo
do
fallback de software bizarro que é lento, congela ou falha.

Eu prefiro fingir que tal hardware antigo não existe e tem
caído
do planeta.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182678470.

Você não precisa voltar tão longe. Apenas intel Series 3/4 ou i940 é
o suficiente para fazê-lo falhar ...
Basta compilar com mingw / msvc e tentar descobrir porque ele trava
de mostrar uma MessageBox que o hardware não é compatível

Na quinta-feira, 11 de fevereiro de 2016 às 12h, Sergey Lapin [email protected]
escrevi:

Eu tenho acesso à loja com PCs dos anos 80 ao início de 2000, se isso ajudar,
mas preciso de alguns detalhes sobre como testar e depurar, pois não
desenvolvedor windows de qualquer forma e não tenho ideias sobre ferramentas, etc.
Tenho um conjunto de i740s com caixas win95se2, alguns Pentim233MMX até.
Devido à contabilidade, isso não será jogado fora até 2025.

btw, Juan você poderia entrar em contato comigo por e-mail para que eu tenha seu endereço pessoal?
Não vou bombardear com nada estúpido.

Na quinta-feira, 11 de fevereiro de 2016 às 5h48, Juan Linietsky [email protected]

escrevi:

Ainda estou esperando por alguém com um chipset antigo para contribuir melhor
detecção de hardware não suportado. Eu não tenho nenhum desse hardware
Desde a
uma década, então não há muito que eu possa fazer.

Na quarta-feira, 10 de fevereiro de 2016 às 23h30, Sergey Lapin < [email protected]

escrevi:

Acho que significa "patches são bem-vindos", duvido que alguém vá
rejeitar
suporte bem feito para
plataforma mais antiga.

Na quinta-feira, 11 de fevereiro de 2016 às 03h41, Juan Linietsky <
notificaçõ[email protected]>
escrevi:

@ Algrin6 https://github.com/Algrin6 Não adianta verificar se
este
coisas são suportadas em versões mais antigas do OpenGL. Essas GPUs têm
motoristas
que dizem ao OpenGL que tudo é suportado, então vá para algum tipo
do
fallback de software bizarro que é lento, congela ou falha.

Eu prefiro fingir que tal hardware antigo não existe e tem
caído
do planeta.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182658216
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment -182676389
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -182678470
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -182679526.

Godot.windows.tools.32.exe compilado com MinGW. Crashes. o que fazer a seguir?

A única coisa em que consigo pensar é que você precisa depurar a falha. Eu iria
comece com a função main () e imprima o nome de cada função
ele corre até que aquele em que ele trava seja encontrado, então basta adicionar impressão
cada linha de função para encontrar a linha exata onde
travar e relatar os resultados. Além disso, se compilado pelo mingw conforme você obtém
endereço de acidente que você pode usar
addr2line -e / path / to / debug / exe 0x

Na verdade, MinGW parece ser enviado com 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)

De acordo com o rastreamento acima, ele trava na linha:

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

Então o que vem depois?

saída 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

A função é NULL porque o driver não a fornece, por isso
trava.

Em 12 de fevereiro de 2016 às 01:21, anatoly techtonik [email protected]
escrevi:

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

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183174112.

@ punto- onde você vê que é NULL?

no topo do backtrace, frame 0, o endereço se 0x00000, é assim
parece quando você chama um ponteiro de função que é nulo

Em 12 de fevereiro de 2016 às 06:58, anatoly techtonik [email protected]
escrevi:

@ punto- https://github.com/punto- onde você vê que é NULL?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183257600.

Mas eu não entendo - C ++ não é Python, então quando o binário godot é carregado, o sistema deve carregar a dll do driver e falhar com um aviso de que o símbolo fornecido não está presente. Por que isso não acontece?

Ou isso significa que Godot realmente implementa vinculação dinâmica em tempo de execução, mas não avisa sobre a falta de símbolos?

glew faz a vinculação do tempo de execução, é por isso que a função existe, mas pode
às vezes ser nulo ..

Em 12 de fevereiro de 2016 às 13:41, anatoly techtonik [email protected]
escrevi:

Ou isso significa que Godot realmente implementa links dinâmicos em tempo de execução,
mas não avisa sobre símbolos ausentes?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401773.

@ punto- isso não parece certo. Este GLEW pode injetar seus próprios stubs para essas funções NULL que reclamam de erro em vez de segfaulting?

Eu não sei .. talvez .. isso seria uma boa ideia

Em 12 de fevereiro de 2016 às 15:01, anatoly techtonik [email protected]
escrevi:

@ punto- https://github.com/punto- isso não parece certo. Pode isso
GLEW injeta seus próprios stubs para essas funções NULL que se queixam de
erro em vez de segfaulting?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183431329.

C ++ não é python, mas python é C :) glew provavelmente procura os símbolos
e quando eles não estão presentes, ele atribui NULL ao ponteiro de função. Eu
não lembro de todos os detalhes, mas é assim que sempre trava,
qualquer função de gl é NULL ..

Em 12 de fevereiro de 2016 às 13:40, anatoly techtonik [email protected]
escrevi:

Mas eu não entendo - C ++ não é Python, então quando o binário godot é carregado, o
o sistema deve carregar o driver dll e falhar com o aviso de que o símbolo fornecido é
não presente. Por que isso não acontece?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442.

Qualquer pessoa com uma dessas placas Intel pode experimentar esta compilação?

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

Em 12 de fevereiro de 2016 às 15:45, Ariel Manzur [email protected] escreveu:

C ++ não é python, mas python é C :) glew provavelmente procura os símbolos
e quando eles não estão presentes, ele atribui NULL ao ponteiro de função. Eu
não lembro de todos os detalhes, mas é assim que sempre trava,
qualquer função de gl é NULL ..

Em 12 de fevereiro de 2016 às 13:40, anatoly techtonik [email protected]
escrevi:

Mas eu não entendo - C ++ não é Python, então quando o binário godot é carregado, o
o sistema deve carregar o driver dll e falhar com o aviso de que o símbolo fornecido é
não presente. Por que isso não acontece?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183401442
.

ver 32

É 32 bits .. é possível para o Windows aceitar apenas 64 bits?

Em 14 de fevereiro de 2016 às 01:29, anatoly techtonik [email protected]
escrevi:

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

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183819635.

Os rastreadores de dependência mostram que é um módulo de 64 bits vinculado a bibliotecas de 32 bits.

Diz qual?

Em 14 de fevereiro de 2016 às 01:38, anatoly techtonik [email protected]
escrevi:

Os rastreadores de dependência mostram que é um módulo de 64 bits vinculado a bibliotecas de 32 bits.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237.

(também por que funciona no meu computador? é uma CPU de 32 bits?)

Em 14 de fevereiro de 2016 às 01:52, Ariel Manzur [email protected] escreveu:

Diz qual?

Em 14 de fevereiro de 2016 às 01:38, anatoly techtonik [email protected]
escrevi:

Os rastreadores de dependência mostram que é um módulo de 64 bits vinculado a bibliotecas de 32 bits.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

Você pode tentar este?

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

Em 14 de fevereiro de 2016 às 01h54, Ariel Manzur [email protected] escreveu:

(também por que funciona no meu computador? é uma CPU de 32 bits?)

Em 14 de fevereiro de 2016 às 01:52, Ariel Manzur [email protected] escreveu:

Diz qual?

Em 14 de fevereiro de 2016 às 01:38, anatoly techtonik < [email protected]

escrevi:

Os rastreadores de dependência mostram que é um módulo de 64 bits vinculado a bibliotecas de 32 bits.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183820237
.

No meu antigo laptop (intel gma x3100) ele não trava, mas a janela permanece cinza com os seguintes erros:

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

Pode ser uma versão de shaders muito antiga?
Mas é estranho que tente D3D em vez de GLSL ...

No domingo, 14 de fevereiro de 2016 às 9h03, Hondres notificaçõ[email protected] escreveu:

No meu antigo laptop (intel gma x3100) ele não trava, mas a janela permanece
cinza com os seguintes erros:

ERRO: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: FALHA no LINK do programa:
Falha ao criar sombreadores D3D.
Em: drivers \ gles2 \ shader_gles2. cpp: 544
ERRO: ShaderGLES2 :: get_current_version: Método / Função falhou, retornando: 0
Em: drivers \ gles2 \ shader_gles2. cpp: 551
ERROR: ShaderGLES2 :: bind: Condition '! Version' is true. retornou: falso
Em: drivers \ gles2 \ shader_gles2. cpp: 126
ERRO: ShaderGLES2 :: _ get_uniform: A condição '! Version' é verdadeira. retornou: -1
Em:. \ Drivers / gles2 / shader_gles2.h: 354

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183827627.

Então, já houve um caso em que os gráficos funcionam usando ângulo e não gl diretamente?

Em 14 de fevereiro de 2016 às 03:25, Sergey Lapin [email protected] escreveu:

Pode ser uma versão de shaders muito antiga?
Mas é estranho que tente D3D em vez de GLSL ...

No domingo, 14 de fevereiro de 2016 às 9h03, Hondres notificaçõ[email protected] escreveu:

No meu antigo laptop (intel gma x3100) ele não trava, mas a janela permanece
cinza com os seguintes erros:

ERRO: ShaderGLES2 :: get_current_version: CanvasShaderGLES2: Programa LINK
FALHOU:
Falha ao criar sombreadores D3D.
Em: drivers \ gles2 \ shader_gles2. cpp: 544
ERRO: ShaderGLES2 :: get_current_version: Método / Função falhou,
retornando: 0
Em: drivers \ gles2 \ shader_gles2. cpp: 551
ERROR: ShaderGLES2 :: bind: Condition '! Version' is true. retornou: falso
Em: drivers \ gles2 \ shader_gles2. cpp: 126
ERRO: ShaderGLES2 :: _ get_uniform: A condição '! Version' é verdadeira.
retornou: -1
Em:. \ Drivers / gles2 / shader_gles2.h: 354

-
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/godotengine/godot/issues/1162#issuecomment -183827627
.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183830014.

@punto- tools relatam que godot.windows.tools.angle.32.exe não é um executável PE válido. Você pode postar uma versão que não seja tocada pelo UPX?

Seu IMAGE_OPTIONAL_HEADER.Magic é igual a IMAGE_NT_OPTIONAL_HDR64_MAGIC que está errado https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

ok tente isto:

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

não é compactado por upx

Em 14 de fevereiro de 2016 às 05:10, anatoly techtonik [email protected]
escrevi:

@ punto- https://github.com/punto- its IMAGE_OPTIONAL_HEADER.Magic é
igual a IMAGE_NT_OPTIONAL_HDR64_MAGIC que está errado
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -183846301.

Ainda é o mesmo problema. depends pensa que é binário de 64 bits, e não apenas 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

É um utilitário unix, btw.

@Hinsbart Você pode tentar isso http://tof.p1x.in/html5/ no computador onde você obtém a tela cinza e aquele erro? supostamente, o chrome usa o mesmo código para seu renderizador.

@techtonik talvez eu esteja tendo aquele bug em que uso bits = 32 e na verdade recebo um binário de 64 bits?

@ punto- Não sei como você compila ou a que bug está se referindo. Logs de comandos e builds podem esclarecer isso. Posso compilá-lo sozinho se você estiver pronto para enviar suas alterações para algum branch.

sim estou nisso

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

Em 15 de fevereiro de 2016 às 14:53, anatoly techtonik [email protected]
escrevi:

@ punto- https://github.com/punto- Não sei como você compila ou
a que bug está se referindo. Logs de comandos e builds podem esclarecer isso. eu posso
compilar sozinho se você estiver pronto para enviar suas alterações para algum branch.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184323695.

Compilar com ângulo = sim

Em 15 de fevereiro de 2016 às 15:25, Ariel Manzur [email protected] escreveu:

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

Em 15 de fevereiro de 2016 às 14:53, anatoly techtonik [email protected]
escrevi:

@ punto- https://github.com/punto- Não sei como você o compila
ou a que bug está se referindo. Logs de comandos e builds podem esclarecer isso. Eu
posso compilá-lo sozinho se você estiver pronto para enviar suas alterações para algum
ramo.

-
Responda a este e-mail diretamente ou visualize-o no 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.

Sem sorte.

tente também com theora_opt = no

Em 15 de fevereiro de 2016 às 18:40, anatoly techtonik [email protected]
escrevi:

scons: *** [drivers \ theora \ theora \ x86 \ mmxencfrag.windows.tools.32.o] Fonte drivers\theora\theora\x86\mmxencfrag.c' not found, needed by target drivers \ theora \ theora \ x86 \ mmxencfrag.windows.tools.32.o '.
scons: construção encerrada devido a erros.

Sem sorte.

-
Responda a este e-mail diretamente ou visualize-o no 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>
                            ^

Ponto final?

Bem, esse é o ponto do ângulo, ele usa 3d direto em vez de opengl: p

Em 15 de fevereiro de 2016 às 18:57, anatoly techtonik [email protected]
escrevi:

No arquivo incluído em drivers \ angle / common / angleutils.h: 12: 0,
de drivers \ angle \ common \ angleutils. cpp: 7 :
drivers \ angle / common / platform.h: 62: 28: erro fatal: d3d11_1.h: arquivo ou diretório inexistente
# incluir
^

Ponto final?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184411949.

O ANGLE tem dois back-ends - o mais antigo usa DirectX 9. Estou baixando o MinGW mais recente com cabeçalhos DirectX 11 agora.

o contexto é criado em platform / windows / gl_context_egl_angle.cpp, I
acho que havia um parâmetro lá para escolher o backend .. Acho que o
problema está nesse arquivo, pode haver uma maneira de detectar quais parâmetros são
melhor para o sistema ..

Em 16 de fevereiro de 2016 às 05:51, anatoly techtonik [email protected]
escrevi:

O ANGLE tem dois back-ends - o mais antigo usa DirectX 9. Estou baixando o mais recente
MinGW com cabeçalhos DirectX 11 agora.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -184580963.

Muitos erros com o gcc 5.3.0 mais recente, por exemplo:

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

Você precisa adicionar -std=c++11 aos sinalizadores de C ++, eu acho.
por exemplo, adicione esta linha após: https://github.com/punto-/godot/blob/angle/drivers/angle/SCsub#L276

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

Não tenho certeza se a sintaxe funcionaria para MSVC, mas com MinGW deve funcionar.

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

É preciso esperar pelo novo lançamento do MinGW .

Talvez a discussão sobre o ANGLE deva ser movida para um assunto separado, mantendo este para "avisar ao usuário que seu hardware é antigo e não tem suporte antes de travar"?

sim, eu concordo

Em 17 de fevereiro de 2016 às 13:25, Rémi Verschelde [email protected]
escrevi:

Talvez a discussão sobre ANGLE deva ser movida para um assunto separado,
mantendo este para "dizer ao usuário que seu hardware é antigo e
sem suporte antes de travar "?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -185282158.

3634 é o problema do ANGLE. # 3694 é PR para obter mais informações ao carregar o mecanismo.

@ Heybye44

Por que Godot funciona magicamente no Ubuntu, mas não no Windows?

Sim! Eu também gostaria de saber o motivo. Funcionou quando testei com o Xubuntu, mas não em nenhuma das edições do Windows.

^^

Não se trata do sistema operacional, mas dos drivers. Em geral, os drivers GL são negligenciados no Windows em comparação com o Linux, graças ao Direct3D. Muitas GPUs mais antigas acabam com uma implementação GL 1.5 mínima em versões mais recentes do Windows.

@adolson

Muitas GPUs mais antigas acabam com uma implementação GL 1.5 mínima em versões mais recentes do Windows.

Então, quando as versões anteriores do OpenGL serão suportadas no Godot? Existe uma necessidade explícita absoluta de confiar no 2.0+? Não é como se a compatibilidade com versões anteriores não existisse, então um dispositivo mais capaz não vai falhar na renderização de uma iteração anterior do OpenGL. Existem recursos do próprio editor visual construído em torno do GLES2 que não poderiam ser redimensionados para usar o GL1.4 em vez? Quer dizer, a maioria dos recursos posteriores do GL são para renderização em 3D, o que é desnecessário quando vem da perspectiva de se ter a intenção de criar um jogo 2D com Godot.

@WinnerEX Isso não vai acontecer. Ser compatível com GL 1.4 significaria abrir mão de muitos recursos interessantes que são usados ​​para 2D e 3D; e no outro extremo do espectro temos pessoas que não podem esperar mais pelo suporte GL 3+ ou mesmo Vulkan. Você pode considerar Godot com segurança como um motor GL 2.1+; se não for isso que você deseja, existem muitos outros engines que podem ter restrições GL mais baixas (por exemplo, OGRE 1.9 ou SDL 2.0).

O tópico aqui é que Godot deve fornecer um erro apropriado quando os recursos GL 2.1+ necessários não estiverem disponíveis em vez de travar; não há intenção de reescrever um renderizador GLES1. Para usuários do Windows, pode haver alguma esperança se o ANGLE for integrado para emulação GL via Direct3D, mas não haverá um downgrade do renderizador GLES2.

Voltando ao assunto: @reduz , pensei que seria possível reproduzir o travamento mesmo em hardware compatível com GL 2.1 tentando carregar Godot em uma máquina virtual sem aceleração 2D e 3D. Vou tentar o mais rápido possível para confirmar, mas isso pode ajudar a descobrir onde ele trava e como escapar de forma adequada com uma mensagem de erro legível por humanos em vez de segfaulting.

Achei que seria possível reproduzir a falha mesmo em hardware compatível com GL 2.1, tentando carregar Godot em uma máquina virtual sem aceleração 2D e 3D. Vou tentar o mais rápido possível para confirmar

Tudo bem, parece que com o VirtualBox 5 não é fácil, pois agora tem um driver GL decente que suporta até OpenGL 3.0 xD.

opengl 3.0 é mais fácil de detectar, porque você tem que solicitar um conext especial
(Eu espero)

Na segunda-feira, 25 de julho de 2016 às 12h28, Rémi Verschelde [email protected]
escrevi:

Achei que seria possível reproduzir a falha mesmo no GL 2.1
hardware capaz, tentando carregar Godot em uma máquina virtual sem 2D
e aceleração 3D. Vou tentar o mais rápido possível para confirmar

Tudo bem, parece que com o VirtualBox 5 não é fácil, pois agora tem um
Driver GL que suporta até OpenGL 3.0 xD.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment -234987968,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AF-Z2_MK5iQA0RxLwv0FHu6po8ucVE8kks5qZNYlgaJpZM4DQoN3
.

Acabei de fazer um teste no meu antigo netbook com um intel igp de baixa qualidade incompatível, no Windows.

Na linha 10791 de rasterizer_gles2.cpp , em RasterizerGLES2::init() adicionei estas poucas linhas:

    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 ainda trava, mas exibe essa mensagem de erro no console antes de desmaiar.

Não sei como dizer a Godot para cancelar a inicialização do rasterizador (RasterizerGLES2 :: init () não retorna verdadeiro / falso, é como se não tivesse escolha a não ser sucesso ou travamento), nem sei como dizer a Godot para sair devidamente.

Mesmo que esse teste de compatibilidade não seja 100% confiável, ele poderia pelo menos reduzir o número de travamentos silenciosos e exibir uma pequena caixa de diálogo do sistema avisando o usuário de que ele vai travar e por quê.

Excelente encontrar @SuperUserNameMan. Eu brinquei um pouco com ele e confirmo que funciona (pelo menos em meus testes onde verifiquei if (glewIsSupported("GL_VERSION_2_1")) pois minha GPU é compatível). Podemos usar OS::alert() para exibir uma caixa de mensagem de bloqueio.

Como você mencionou, a única parte que falta (e a mais difícil) é deixar Godot sair corretamente. Dei uma olhada rápida, mas minhas habilidades acabaram por fazer Godot encerrar no meio da inicialização do sistema operacional.

Aqui está uma diferença da prova de conceito:

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 testar para pessoas com suporte ao GL 2.1, apenas remova ! no teste if.

Ele gera esta caixa de mensagem (bloqueio) no X11:

Depois de discutir com @reduz , parece que meu patch acima pode ser bom o suficiente como um primeiro passo; uma vez que o alerta do sistema operacional está bloqueando, podemos informar as pessoas sobre o problema e avisá-las de que Godot irá travar :) Sair sem problemas seria melhor, mas essa solução intermediária já é boa de se ter.

para testar no Linux sem alterar o código e recompilar, acho que você pode definir a variável de ambiente MESA_GL_VERSION_OVERRIDE para 2.0: http://www.mesa3d.org/envvars.html

IIRC, também foi assim que obrigou o MESA a permitir que a GPU da lista negra funcionasse com Godot.