+1

+10

+1

i wrote that code in context_gl_win.cpp but it generally crashes due to
some unimplemented function in windows due to shitty driver
I wish i could exactly find out why

On Sat, Jan 17, 2015 at 2:56 PM, MSC [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1162#issuecomment-70376758.

Setting this as high priority for now as it would be a very useful feature. We get tons of reports of crashes due to people having very old Intel IGPs or whatnot that do not support GLES2.

Ok I guess I've referenced enough crashes to underline my above "tons", I'll stop digging through the archives :D

+1 Why does Godot magically work on Ubuntu but not on Windows?

Any idea on how this could be implemented @reduz?

i wrote that code in context_gl_win.cpp but it generally crashes due to some unimplemented function in windows

Why not use dynamic linking then? It will be obvious which function is missing. I believe that https://github.com/p3/regal does this.

I already did detection and attempt to show a message, but it seems to
still not work.
As I don' t have any unsupported hardware, I can' t see why it crashes and
thus, can' t fix it.
PRs welcome.

On Tue, Feb 2, 2016 at 12:11 PM, anatoly techtonik <[email protected]

wrote:

i wrote that code in context_gl_win.cpp but it generally crashes due to
some unimplemented function in windows

Why not use dynamic linking then? It will be obvious which function is
missing. I believe that https://github.com/p3/regal does this.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-178624438.

If someone with an old GPU could try to run Godot through gdb on Linux, it might be quite helpful then. The Windows "problem signature" debug info seems quite pointless :/

I am not doing C++ at all. Only Python, so I am a user. Tell me what to run and I may get the info.

Tell me what to run and I may get the info.

I have no clue about how to run stuff through a debugger on Windows, but I think it's non trivial for people who don't have much experience compiling stuff on Windows. That's why I suggested for someone to try to debug with GDB on Linux, as it's very easy to use:

$ 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

and copy the output of this bt (backtrace) command to this bug report.

Of course it could be that the problem is Windows-specific, so debugging on Linux would be pointless, but I believe Linux users also had segfaults that were not caught to tell the user that their hardware does not support OpenGL(ES) 2.1.

Beta 2.0 fails on to run on my Linux, but it seems unrelated to graphics card - #3557

Hehe you're a lucky one to run into all the known issues we have in corner cases :)

I guess I just have a "complaining talent" and a GitHub account. =)

I don't know about such old videocards that crash at startup, but on, for example, on NVIDIA 6800 GT,
it crashes only on few projects. So there are cmd output about framebuffer errors on all projects and Godot modules. It can be fully fixed by disabling the "fp16_framebuffer" setting in the project rasterizer settings. I know, on the same videocards (don't know about full connection), there are wrong rasterizing (no textures) what can be fully fixed by disabling the "fragment_lighting" setting.
So I think Godot should check if these functions are supported, and if not, note the user and disable them.
Maybe it'll help with the crash at startup too.

Tell me what to run and I may get the info.

$ gdb /path/to/godot/binary // if possible self-compiled in debug mode, to have more info

Godot_v2.0_beta_20160205_x11.64 doesn't crash on Fedora 23 with the same hardware. It is detected as Mobile Intel® GM45 Express Chipset there.

Godot_v2.0_beta_20160205_win32.exe still crashes on Vista 32.

@techtonik I think the reason is that Linux, unlike Windows, uses software realization for OpenGL when there are problems with hardware OpenGL, but it's slower than hardware one, of course.

@Algrin6 it would be nice if engine could just provide some transparency into that fact. In the old times, games like Baldur's Gate were shipped with graphics test binaries. 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 of memory! And now I have 3 GB + 3 GHz and can't run game engine. How come?

2 MB of memory! And now I have 3 GB + 3 GHz and can't run game engine. How come?

Because we're in 2016 and that Bioware engine is super old? And this test was designed to check if the graphics driver is powerful enough, so likely the test was _working_ starting with DirectX 3.01a, but maybe saying "upgrade your hardware or drivers" if you were below DirectX 7 or something. And Bioware engine was working solely on MS Windows <= XP, while Godot works on a dozen platforms...

Now since you seem to know exactly what we need to do, please make a pull request.

@techtonik major problem about this is that none of the core developers have old hardware to test the issue. So you either have to provide debug info to pinpoint the cause of trouble or fix it by yourself (which is the beauty of open source).

Baldur's gate is not programmed in a general purpose 2D/3D game engine.
It's custom tailored programmed in C, x86 assembler, likely Watcom
compiler, protected mode and uses a basic stack machine for scripting. Also
feel free to do all the custom blitting code yourself.

On Sun, Feb 7, 2016 at 12:36 PM, George Marques [email protected]
wrote:

@techtonik https://github.com/techtonik major problem about this is
that none of the core developers have old hardware to test the issue. So
you either have to provide debug info to pinpoint the cause of trouble or
fix it by yourself (which is the beauty of open source).

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-181034018.

@reduz can Godot produce "platform compatibility table" for the code produced by engine (or used by editor) that lists all features that game currently uses (blitting, particles, 3D objects, ...)?

If that is impossible at the moment, is this at least technically feasible?

The use case for validation is to be able to produce a minimal game (test) that it can run on any blitting device and measure the performance.

@reduz What about https://github.com/godotengine/godot/issues/1162#issuecomment-180466018 ?

@Algrin6 It's pointless to check if that stuff is supported in older versions of OpenGL. These GPUs have drivers that tell OpenGL that everything is supported, then go into some sort of bizarre software fallback that is slow, freezes or crashes.

I prefer to pretend that such old hardware does not exist and has fallen from the planet.

I think that means "patches are welcome" I really doubt anybody will reject
nicely done support for
older platform.

On Thu, Feb 11, 2016 at 3:41 AM, Juan Linietsky [email protected]
wrote:

@Algrin6 https://github.com/Algrin6 It's pointless to check if that
stuff is supported in older versions of OpenGL. These GPUs have drivers
that tell OpenGL that everything is supported, then go into some sort of
bizarre software fallback that is slow, freezes or crashes.

I prefer to pretend that such old hardware does not exist and has fallen
from the planet.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-182658216.

I'm still waiting for someone with an old chipset to contribute better
detection of unsupported hardware. I don't have any of that hardware since
a decade, so there's nothing much I can do.

On Wed, Feb 10, 2016 at 11:30 PM, Sergey Lapin [email protected]
wrote:

I think that means "patches are welcome" I really doubt anybody will reject
nicely done support for
older platform.

On Thu, Feb 11, 2016 at 3:41 AM, Juan Linietsky [email protected]
wrote:

@Algrin6 https://github.com/Algrin6 It's pointless to check if that
stuff is supported in older versions of OpenGL. These GPUs have drivers
that tell OpenGL that everything is supported, then go into some sort of
bizarre software fallback that is slow, freezes or crashes.

I prefer to pretend that such old hardware does not exist and has fallen
from the planet.

—
Reply to this email directly or view it on GitHub
<https://github.com/godotengine/godot/issues/1162#issuecomment-182658216
.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-182676389.

I have access to store with PCs from 80s to early 2000, if that will help,
but I need some details regarding how to test and to debug as I'm not
windows developer in any way and have no ideas on tools, etc.
Have a set of i740s with win95se2 boxes, some Pentim233MMX even.
Due to accounting this won't be thrown away until 2025.

btw, Juan could you contact me via email so I have your personal address?
Won't bombard it with anything stupid.

On Thu, Feb 11, 2016 at 5:48 AM, Juan Linietsky [email protected]
wrote:

I'm still waiting for someone with an old chipset to contribute better
detection of unsupported hardware. I don't have any of that hardware since
a decade, so there's nothing much I can do.

On Wed, Feb 10, 2016 at 11:30 PM, Sergey Lapin [email protected]
wrote:

I think that means "patches are welcome" I really doubt anybody will
reject
nicely done support for
older platform.

On Thu, Feb 11, 2016 at 3:41 AM, Juan Linietsky <
[email protected]>
wrote:

@Algrin6 https://github.com/Algrin6 It's pointless to check if that
stuff is supported in older versions of OpenGL. These GPUs have drivers
that tell OpenGL that everything is supported, then go into some sort
of
bizarre software fallback that is slow, freezes or crashes.

I prefer to pretend that such old hardware does not exist and has
fallen
from the planet.

—
Reply to this email directly or view it on GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment-182658216
.

—
Reply to this email directly or view it on GitHub
<https://github.com/godotengine/godot/issues/1162#issuecomment-182676389
.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-182678470.

You don't need to go that further back. Just intel Series 3/4 or i940 is
enough to make it crash...
Just compile with mingw/msvc and try to figure out why it crashes instead
of showing a MessageBox that hardware is not supported

On Thu, Feb 11, 2016 at 12:00 AM, Sergey Lapin [email protected]
wrote:

I have access to store with PCs from 80s to early 2000, if that will help,
but I need some details regarding how to test and to debug as I'm not
windows developer in any way and have no ideas on tools, etc.
Have a set of i740s with win95se2 boxes, some Pentim233MMX even.
Due to accounting this won't be thrown away until 2025.

btw, Juan could you contact me via email so I have your personal address?
Won't bombard it with anything stupid.

On Thu, Feb 11, 2016 at 5:48 AM, Juan Linietsky [email protected]

wrote:

I'm still waiting for someone with an old chipset to contribute better
detection of unsupported hardware. I don't have any of that hardware
since
a decade, so there's nothing much I can do.

On Wed, Feb 10, 2016 at 11:30 PM, Sergey Lapin <[email protected]

wrote:

I think that means "patches are welcome" I really doubt anybody will
reject
nicely done support for
older platform.

On Thu, Feb 11, 2016 at 3:41 AM, Juan Linietsky <
[email protected]>
wrote:

@Algrin6 https://github.com/Algrin6 It's pointless to check if
that
stuff is supported in older versions of OpenGL. These GPUs have
drivers
that tell OpenGL that everything is supported, then go into some sort
of
bizarre software fallback that is slow, freezes or crashes.

I prefer to pretend that such old hardware does not exist and has
fallen
from the planet.

—
Reply to this email directly or view it on GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment-182658216
.

—
Reply to this email directly or view it on GitHub
<
https://github.com/godotengine/godot/issues/1162#issuecomment-182676389
.

—
Reply to this email directly or view it on GitHub
<https://github.com/godotengine/godot/issues/1162#issuecomment-182678470
.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-182679526.

Compiled godot.windows.tools.32.exe with MinGW. Crashes. What to do next?

The only thing I can think of is that you need to debug the crash. I'd
start with main() function and print each function name
it runs until the one it crashes in is found, then just add printing to
each line of function to find exact line where it
crashes and report back the results. Also if compiled by mingw as you get
crash address you can use
addr2line -e /path/to/debug/exe 0x

Actually, MinGW appears to be shipped with 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)

According to the trace above, it crashes at the line:

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

So, what's next?

apitrace output

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 @0 wglCreateContext(hdc = 0xcd01199a) = 0x10000
3 @0 wglMakeCurrent(hdc = 0xcd01199a, hglrc = 0x10000) = TRUE
warning: ChoosePixelFormat returned a pixel format supported by the GDI software implementation
4 @0 glViewport(x = 0, y = 0, width = 1024, height = 600)
4: warning: glGetError(glViewport) = GL_INVALID_ENUM
5 @0 glScissor(x = 0, y = 0, width = 1024, height = 600)
741 @0 glEnable(cap = GL_DEPTH_TEST)
742 @0 glDepthFunc(func = GL_LEQUAL)
743 @0 glFrontFace(mode = GL_CW)
744 @0 glClearColor(red = 0, green = 0, blue = 0, alpha = 1)
745 @0 glClear(mask = GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT)
746 @0 glGenTextures(n = 1, textures = &1)
Rendered 0 frames in 0.268717 secs, average of 0 fps

godot.windows.tools.32.1.trace.zip

The function is NULL because the driver doesn't provide it, that's why it
crashes.

On 12 February 2016 at 01:21, anatoly techtonik [email protected]
wrote:

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

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183174112.

@punto- where do you see that it is NULL?

at the top of the backtrace, frame 0, the address if 0x00000, that's how it
looks like when you call a function pointer that is null

On 12 February 2016 at 06:58, anatoly techtonik [email protected]
wrote:

@punto- https://github.com/punto- where do you see that it is NULL?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183257600.

But I don't get - C++ is not Python, so when godot binary loads, the system should load driver dll and fail with warning that given symbol is not present. Why it doesn't happen?

Or does that mean that Godot actually implements dynamic run-time linking, but doesn't warn about missing symbols?

glew does the run time linking, that's why the function exists but can
sometimes be null..

On 12 February 2016 at 13:41, anatoly techtonik [email protected]
wrote:

Or does that mean that Godot actually implements dynamic run-time linking,
but doesn't warn about missing symbols?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183401773.

@punto- this doesn't seem right. Can this GLEW inject your own stubs for these NULL functions that complain with error instead of segfaulting?

I don't know.. maybe.. that'd be a good idea

On 12 February 2016 at 15:01, anatoly techtonik [email protected]
wrote:

@punto- https://github.com/punto- this doesn't seem right. Can this
GLEW inject your own stubs for these NULL functions that complain with
error instead of segfaulting?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183431329.

C++ is not python, but python is C :) glew probably looks for the symbols
and when they're not present it assigns NULL to the function pointer. I
don't remember all the details tho, but that's how it always crashes,
whatever function from gl is NULL..

On 12 February 2016 at 13:40, anatoly techtonik [email protected]
wrote:

But I don't get - C++ is not Python, so when godot binary loads, the
system should load driver dll and fail with warning that given symbol is
not present. Why it doesn't happen?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183401442.

Can anyone with one of these Intel cards try this build?

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

On 12 February 2016 at 15:45, Ariel Manzur [email protected] wrote:

C++ is not python, but python is C :) glew probably looks for the symbols
and when they're not present it assigns NULL to the function pointer. I
don't remember all the details tho, but that's how it always crashes,
whatever function from gl is NULL..

On 12 February 2016 at 13:40, anatoly techtonik [email protected]
wrote:

But I don't get - C++ is not Python, so when godot binary loads, the
system should load driver dll and fail with warning that given symbol is
not present. Why it doesn't happen?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183401442
.

vista 32

It's 32 bits.. is it possible for windows to only accept 64 bits?

On 14 February 2016 at 01:29, anatoly techtonik [email protected]
wrote:

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

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183819635.

Dependency walkers shows that it is 64-bit module linked to 32-bit libs.

Does it say which one?

On 14 February 2016 at 01:38, anatoly techtonik [email protected]
wrote:

Dependency walkers shows that it is 64-bit module linked to 32-bit libs.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183820237.

(also why does it work on my computer? is that a 32 bits cpu?)

On 14 February 2016 at 01:52, Ariel Manzur [email protected] wrote:

Does it say which one?

On 14 February 2016 at 01:38, anatoly techtonik [email protected]
wrote:

Dependency walkers shows that it is 64-bit module linked to 32-bit libs.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183820237
.

Can you try this one?

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

On 14 February 2016 at 01:54, Ariel Manzur [email protected] wrote:

(also why does it work on my computer? is that a 32 bits cpu?)

On 14 February 2016 at 01:52, Ariel Manzur [email protected] wrote:

Does it say which one?

On 14 February 2016 at 01:38, anatoly techtonik <[email protected]

wrote:

Dependency walkers shows that it is 64-bit module linked to 32-bit libs.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183820237
.

On my old laptop (intel gma x3100) it doesn't crash, but the window stays grey with the following errors:

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

Can it be too old shaders version?
But it is strange it tries D3D ones instead of GLSL...

On Sun, Feb 14, 2016 at 9:03 AM, Hondres [email protected] wrote:

On my old laptop (intel gma x3100) it doesn't crash, but the window stays
grey with the following errors:

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

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183827627.

So is there ever a case where graphics work using angle and not gl directly?

On 14 February 2016 at 03:25, Sergey Lapin [email protected] wrote:

Can it be too old shaders version?
But it is strange it tries D3D ones instead of GLSL...

On Sun, Feb 14, 2016 at 9:03 AM, Hondres [email protected] wrote:

On my old laptop (intel gma x3100) it doesn't crash, but the window stays
grey with the following errors:

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

—
Reply to this email directly or view it on GitHub
<https://github.com/godotengine/godot/issues/1162#issuecomment-183827627
.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183830014.

@punto- tools report that godot.windows.tools.angle.32.exe is not a valid PE executable. Can you post version that is not touched by UPX?

Its IMAGE_OPTIONAL_HEADER.Magic is equal to IMAGE_NT_OPTIONAL_HDR64_MAGIC which is wrong https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

ok try this:

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

it's not compressed by upx

On 14 February 2016 at 05:10, anatoly techtonik [email protected]
wrote:

@punto- https://github.com/punto- its IMAGE_OPTIONAL_HEADER.Magic is
equal to IMAGE_NT_OPTIONAL_HDR64_MAGIC which is wrong
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-183846301.

Still the same problem. depends thinks it is 64-bit binary, and not only 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

It is unix utility, btw.

@Hinsbart Can you try this http://tof.p1x.in/html5/ on the computer where you get the grey screen and that error? supposedly chrome uses the same code for their renderer..

@techtonik maybe I'm having that bug where I use bits=32 and I actually get a 64 bit binary?

@punto- I don't know how do you compile it or what bug are referring to. Commands and builds logs may clarify it. I can compile it myself if you're ready to commit your changes to some branch.

yeah I'm on it

here it is https://github.com/punto-/godot/tree/angle

On 15 February 2016 at 14:53, anatoly techtonik [email protected]
wrote:

@punto- https://github.com/punto- I don't know how do you compile it or
what bug are referring to. Commands and builds logs may clarify it. I can
compile it myself if you're ready to commit your changes to some branch.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-184323695.

Compile with angle=yes

On 15 February 2016 at 15:25, Ariel Manzur [email protected] wrote:

here it is https://github.com/punto-/godot/tree/angle

On 15 February 2016 at 14:53, anatoly techtonik [email protected]
wrote:

@punto- https://github.com/punto- I don't know how do you compile it
or what bug are referring to. Commands and builds logs may clarify it. I
can compile it myself if you're ready to commit your changes to some
branch.

—
Reply to this email directly or view it on 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.

No luck.

try also with theora_opt=no

On 15 February 2016 at 18:40, anatoly techtonik [email protected]
wrote:

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

No luck.

—
Reply to this email directly or view it on 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>
                            ^

Fullstop?

Well that's the point of angle, it uses direct 3d instead of opengl :p

On 15 February 2016 at 18:57, anatoly techtonik [email protected]
wrote:

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
^

Fullstop?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-184411949.

ANGLE has two backends - older one uses DirectX 9. I am downloading newer MinGW with DirectX 11 headers right now.

the context is created in platform/windows/gl_context_egl_angle.cpp, I
think there was a parameter there to choose the backend.. I think the
problem is in that file, there might be a way to detect what parameters are
best for the system..

On 16 February 2016 at 05:51, anatoly techtonik [email protected]
wrote:

ANGLE has two backends - older one uses DirectX 9. I am downloading newer
MinGW with DirectX 11 headers right now.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-184580963.

Lots of errors with newer gcc 5.3.0, for example:

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

You need to add -std=c++11 to the C++ flags I guess.
e.g. add this line after: https://github.com/punto-/godot/blob/angle/drivers/angle/SCsub#L276

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

Not sure if the syntax would work for MSVC though, but with MinGW it should be ok.

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

Need to wait for new MinGW release.

Maybe the discussion about ANGLE should be moved to a separate issue, keeping this one for "tell the user that their hardware is old and unsupported before crashing"?

yeah I agree

On 17 February 2016 at 13:25, Rémi Verschelde [email protected]
wrote:

Maybe the discussion about ANGLE should be moved to a separate issue,
keeping this one for "tell the user that their hardware is old and
unsupported before crashing"?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-185282158.

3634 is the ANGLE issue. #3694 is PR for getting more information when loading engine.

@Heybye44

Why does Godot magically work on Ubuntu but not on Windows?

Yes! I would like to know the reason too. It works when I tested with Xubuntu but not on any of Windows editions.

^^

It's not about the OS, it's about the drivers. In general, GL drivers are neglected on Windows in comparison to Linux, thanks to Direct3D. A lot of older-ish GPUs end up with a minimal GL 1.5 implementation on newer versions of Windows.

@adolson

A lot of older-ish GPUs end up with a minimal GL 1.5 implementation on newer versions of Windows.

So when will earlier OpenGL versions be supported in Godot? Is there an absolute explicit necessity to rely on 2.0+? It's not like backwards-compatibility doesn't exist, so a more capable device isn't going to fail at rendering an earlier iteration of OpenGL. Are there features of the visual editor itself built around GLES2 which couldn't be scaled back to use GL1.4 in lieu? I mean, most later GL features are for 3D rendering anyway, which are needless when coming from the perspective of intending to create a 2D game with Godot.

@WinnerEX That won't happen. Being compatible with GL 1.4 would mean giving up many interesting features that are used for both 2D and 3D; and at the other end of the spectrum we have people who can't wait any longer for GL 3+ support or even Vulkan. You can safely consider Godot as a GL 2.1+ engine; if that's not what you want, there are plenty of other engines that might have lower GL restrictions (e.g. OGRE 1.9, or SDL 2.0).

The topic here is that Godot should give a proper error when the required GL 2.1+ features are not available instead of crashing; there is no intent to rewrite a GLES1 renderer. For Windows users there might be some hope if ANGLE is integrated for GL emulation via Direct3D, but there won't be a downgrade of the GLES2 renderer.

Back to the topic: @reduz, I thought that it might be possible to reproduce the crash even on GL 2.1 capable hardware by trying to load Godot in a virtual machine without 2D and 3D acceleration. I'll give it a try asap to confirm, but that might help find out where it crashes, and how to bail out properly with a human-readable error message instead of segfaulting.

I thought that it might be possible to reproduce the crash even on GL 2.1 capable hardware by trying to load Godot in a virtual machine without 2D and 3D acceleration. I'll give it a try asap to confirm

Alright, looks like with VirtualBox 5 it's not easy as it now has a decent GL driver which supports up to OpenGL 3.0 xD.

opengl 3.0 is easier t detect, because you have to request a special conext
(I hopt)

On Mon, Jul 25, 2016 at 12:28 PM, Rémi Verschelde [email protected]
wrote:

I thought that it might be possible to reproduce the crash even on GL 2.1
capable hardware by trying to load Godot in a virtual machine without 2D
and 3D acceleration. I'll give it a try asap to confirm

Alright, looks like with VirtualBox 5 it's not easy as it now has a decent
GL driver which supports up to OpenGL 3.0 xD.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/1162#issuecomment-234987968,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2_MK5iQA0RxLwv0FHu6po8ucVE8kks5qZNYlgaJpZM4DQoN3
.

I've just made a test on my old netbook with an incompatible crappy intel igp, under Windows.

At line 10791 of rasterizer_gles2.cpp, into RasterizerGLES2::init() i've added these few lines :

    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 still crashes, but it displays this error message into the console just before fainting.

I don't know how to tell Godot to cancel the rasterizer initialization ( RasterizerGLES2::init() does not return true/false, it's like if it has no choice but success or crash), neither i know how to tell Godot to quit properly.

Even if this compatibility test might not be 100% reliable, it could at least reduce the number of silent crash, and display a little system dialog box warning the user that it is going to crash and why.

Awesome find @SuperUserNameMan. I played around with it a bit and I confirm that it works (at least in my tests where I checked for if (glewIsSupported("GL_VERSION_2_1")) since my GPU supports it). We can use OS::alert() to display a blocking message box.

As you mentioned, the only missing part (and hardest one) is to then let Godot exit properly. I've had a quick look but it's way over my skillset to make Godot quit in the middle of its OS initialization.

Here's a diff of the proof of concept:

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

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

To be able to test for people with GL 2.1 support, just remove the ! in the if test.

It spawns this (blocking) message box on X11:

After discussing with @reduz, it appears that my above patch could be good enough as a first step; since the OS alert is blocking, we can tell people about the issue and warn them that Godot will crash :) Exiting cleanly would of course be better, but this intermediate solution is already nice to have.

to test under linux without changing the code and recompiling, i think you can set the environment variable MESA_GL_VERSION_OVERRIDE to 2.0 : http://www.mesa3d.org/envvars.html

IIRC, that's also how to proceeded to force MESA to allow black listed GPU to work with Godot.