search

ptitSeb / gl4es

GL4ES is a OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android, Emscripten and AmigaOS4.
http://ptitseb.github.io/gl4es/
MIT License
711 stars 160 forks source link

gl4es 1.0+ regressions #20

Closed MagaTailor closed 6 years ago

MagaTailor commented 7 years ago

The issue has turned into a regressions report so I'll open a new one for Texture3d support.

So, I've heard about this new project called gl4es over there and thought I'd bring up the issue here, lest it be 4gotten :O

Great name change, by the way :)

ptitSeb commented 7 years ago

That commit 366de784818782b90238fa28966d6d2f2ec0196e should have improved texture3d tracking

MagaTailor commented 7 years ago

Nice to hear that. BTW, glest hasn't been crashing since quite a while ago but there's also been a regression.

The menu screen is not being rendered at all - it's just the menu buttons and the rain against a grey background.

ptitSeb commented 7 years ago

Menu in Glest is broken even in current version of gl4es?

MagaTailor commented 7 years ago

Yes, I recompiled the latest source before posting.

ptitSeb commented 7 years ago

Ah, too bad.

Ok, I'll take a look at that glest menu later.

MagaTailor commented 7 years ago

Two more issues that could be related.

There are no textures in Astromenace and ToME, as well as font problems.

ptitSeb commented 7 years ago

Ah, more breakage :(

I'll check that.

ptitSeb commented 7 years ago

AstroMenace is fixed with 5940fb4c2ffb1ddfd60675df58cb98e73ba1afbf

MagaTailor commented 7 years ago

As for more font? breakage, you can also check neverball out. (the ready-set-go animation is not displayed correctly)

ptitSeb commented 7 years ago

I assume you are using ES1 backend? I'll check that.

ptitSeb commented 7 years ago

@MagaTailor I tested with current version, and I don't have any issue with neverball (using LIBGL_ES=1 backend, there are some drawing issues in menu with LIBGL_ES=2).

MagaTailor commented 7 years ago

No idea. Astromenace is still broken for me in ES1 mode but seems to work in ES2, save for a wrong screen aspect ratio.

ptitSeb commented 7 years ago

AstroMenace still borken on ES1? I guess your hardware driver doesn't like the Framebuffer creation with NPOT (Non Power Of Two) texture. You have this line LIBGL: going back to npot size pot'ed texture for FBO when you launch it, at the beginning, and then, a message that it failed to create the Framebuffer?

MagaTailor commented 7 years ago

Actually, the only hint of a problem is this line:

glXGetProcAddress: glRenderbufferStorageMultisampleCoverageNV not found.
Frame Buffer Object creation start with parameters 1280 1024 1 1 0 0
Can't create FRAMEBUFFER.

edit: The line is also present in a working glshim, so no, it's not it. I'll recompile with debug enabled.

ptitSeb commented 7 years ago

Ok, so it seems your hardware driver can handle NPOT texture, but not for Framebuffer, were POT texture are required, at least for GLES1.1 I'll add a LIBGL_POTFRAMBUFFER=1 for this case, as I cannot really detect that.

MagaTailor commented 7 years ago

I'll recompile with debug enabled and try again. The message seems to be unrelated to the problem as it was already present in a working shim.

MagaTailor commented 7 years ago

Same old, here's the full output:

glXGetProcAddress: glRenderbufferStorageMultisampleCoverageNV not found.
Frame Buffer Object creation start with parameters 1280 1024 1 1 0 0
glGenFramebuffers(1, 0x155ab0)
glBindFramebuffer(GL_FRAMEBUFFER, 0), list=none, current_fb=0 (draw=0, read=0)
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 1, 0) current_fb=0 (draw=0, read=0)
found texture, glname=1, size=1280x1024(2048x1024), format/type=0x1908/0x1401
LIBGL: glGetError(): 0x0502
glCheckFramebufferStatus(0x8D40)=0x0501
Can't create FRAMEBUFFER.

Frame Buffer Object creation start with parameters 1280 1024 1 0 0 0
glGenFramebuffers(1, 0x155b0c)
glBindFramebuffer(GL_FRAMEBUFFER, 0), list=none, current_fb=0 (draw=0, read=0)
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, 2, 0) current_fb=0 (draw=0, read=0)
found texture, glname=2, size=1280x1024(2048x1024), format/type=0x1908/0x1401
LIBGL: glGetError(): 0x0502
glCheckFramebufferStatus(0x8D40)=0x0501
Can't create FRAMEBUFFER.
ptitSeb commented 7 years ago

With d91f617d89c98c512369d024ca2e2675df461a9e try with LIBGL_POTFRAMEBUFFER=1

MagaTailor commented 7 years ago

No difference, as I already mentioned, the message had been present before the breakage. astro2

MagaTailor commented 7 years ago

OK, found the config option that breaks gl4es - FBOCoreMode value="1", setting it to '0' restores the correct rendering. (with the corresponding performance drop)

ptitSeb commented 7 years ago

So still something with FBO that the GLES1 hardware doesn' like... As it works with ES2 backend, I guess it's fine.

MagaTailor commented 7 years ago

ES2 backend is also broken, just differently. astro3

MagaTailor commented 7 years ago

It should look like this: (LIBGL: v0.9.2 built on Dec 3 2016 23:26:50) astro4

ptitSeb commented 7 years ago

I don't get it. With LIBGL_POTFRAMEBUFFER=1 it should works as with gl4es 0.9.2.

Can you put here a debug output of the Framebuffer stuff with that env. var.?

MagaTailor commented 7 years ago

There's no new stuff, apart from the following:

LIBGL: Force framebuffers to be on POT size
glXChooseVisual(0x1b0e50, 0, 0xbe9e8530)
glXChooseFBConfig(0x1b0e50, 0, 0xbe9e8530, 0xbe9e84e8)
FBConfig depthBits=16
glXCreateContext(0x1b0e50, 0x1ef398, (nil), 1), latest_visual=0x1ef398, fbcontext_count=0 => 0x1efb48
glXMakeCurrent(0x1b0e50, 0x2000011, 0x1efb48), isPBuffer(drawable)=0, context->drawable=(nil), context->eglSurface=(nil) => True
glXQueryExtensionString(0x1b0e50, 0)
glXQueryExtensionString(0x1b0e50, 0)
glXQueryExtensionString(0x1b0e50, 0)
glXSwapInterval(0)
LIBGL: Enable LIBGL_VSYNC=1 if you want to use vsync.
glXMakeCurrent(0x1b0e50, 0x2000011, 0x1efb48), isPBuffer(drawable)=0, context->drawable=0x2000011, context->eglSurface=0x20000001 => True
Same context and drawable, doing nothing
Set video mode: 1280 x 1024 x 16
ptitSeb commented 7 years ago

Anamorphic issue should be fixed with 888a318fe5746f937076596333d71098364d7ad9

MagaTailor commented 7 years ago

No change since https://github.com/ptitSeb/gl4es/issues/20#issuecomment-340244314

ptitSeb commented 7 years ago

The Anamorphic fix was for the GLES2 backend only.

Also, ec8a24c768856e83684f15ddb1873886f0c54233 should have fixed remaining issue about texture POT'ed size.

MagaTailor commented 7 years ago

I confirm the GLES2 fix but otherwise there really is no change since https://github.com/ptitSeb/gl4es/issues/20#issuecomment-340244314 :)

I'm attaching texture.c DEBUG logs obtained with LIBGL_POTFRAMEBUFFER=1/0 respectively. log_pot.txt log_nopot.txt

MagaTailor commented 7 years ago

I've just noticed LIBGL: Force framebuffers to be on POT size is not printed in either case. Might the env.var handling have been broken between the fixes?

ptitSeb commented 7 years ago

I have the POT statement on my side:

/media/SEBEXT/sources/git/glseb$ DISPLAY=:0 LIBGL_FB=3 LIBGL_ES=1 LIBGL_POTFRAMEBUFFER=1 glxgears
LIBGL: Initialising gl4es
LIBGL: v1.0.2 built on Oct 29 2017 17:19:23
LIBGL: using pbuffer
LIBGL: Using GLES 1.1 backend
LIBGL:loaded: libGLES_CM.so
LIBGL:loaded: libEGL.so
LIBGL: LiveInfo detected, fps will be shown
LIBGL: Using GLES 1.1 backend
LIBGL: Hardware Limited NPOT detected and used
LIBGL: Extension GL_OES_blend_subtract detected and used
LIBGL: Extension GL_OES_blend_func_separate detected and used
LIBGL: Extension GL_OES_blend_equation_separate detected and used
LIBGL: Extension GL_OES_framebuffer_object detected and used
LIBGL: Extension GL_OES_point_sprite detected and used
LIBGL: Extension GL_OES_point_size_array detected
LIBGL: Extension GL_OES_depth24 detected and used
LIBGL: Extension GL_OES_rgb8_rgba8 detected and used
LIBGL: Extension GL_EXT_multi_draw_arrays detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_texture_cube_map detected and used
LIBGL: Extension GL_OES_draw_texture detected and used
LIBGL: Max texture size: 2048
LIBGL: Texture Units: 4(4), Max lights: 8, Max planes: 6
LIBGL: Targeting OpenGL 1.5
LIBGL: Force framebuffers to be on POT size
LIBGL: Current folder is:/media/SEBEXT/sources/git/glseb
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.

But yeah, it's missing on you log, so something is wrong.

MagaTailor commented 7 years ago

OK, my bad for pasting your typo from https://github.com/ptitSeb/gl4es/issues/20#issuecomment-340243411 :O

However, it still doesn't work. Here's the proper log. log_pot.txt

ptitSeb commented 7 years ago

I would also need you to activate DEBUG in framebuffer.c. I see some texture creation and deletion (the color attachement of the framebuffer I presume, accoding to the size), but now what is happening with the Framebuffer itself

MagaTailor commented 7 years ago

Here you are: more_log_pot.txt

ptitSeb commented 7 years ago

Can you try 966b59f1f8ab54d4aa98265134fddb7d7f26f928

I changed how the macro LOAD_GLES_OR_OES get the function pointer, as I noticed the call to glGenFramebuffers return 0, wich is not good. Be sure to test on both ES1 and ES2 backend, as I suspect I may have broken GLES2 fixing GLES1.1 on your hardware.

MagaTailor commented 7 years ago

I'm happy to report both backends work fine now, with or without LIBGL_POTFRAMEBUFFER=1. Thanks!

ptitSeb commented 7 years ago

Great :)

MagaTailor commented 7 years ago

Unfortunately, glest and neverball regressions haven't been affected by the recent fixes.

As for ToME, the problematic option turns out to be "Framebuffers". With the background disabled, it's all white, otherwise there are artifacts. tome2

ptitSeb commented 7 years ago

I'll analyse how the rendering is done. It may be some texture format that are not supported, or some blending (I remember I had to make some changes for some SDL or SDL2 app to work properly, not sure when or what it was).

MagaTailor commented 7 years ago

Oops, Framebuffers doesn't seem to make any difference after all, I must have been shuffling different glshims.

However, LIBGL_ES=2 makes the screen and the artifacts black instead of white.

ptitSeb commented 7 years ago

Maybe it's a texture that didn't load. I had something similar on my side on another game, and it was textures too big for card. using LIBGL_SHRINK=10 fixed my issue.

MagaTailor commented 7 years ago

I'll give it a try. However, does that mean the 1.0+ versions of gl4es work differently regarding textures?

The 20161203 glshim that I like to call the reference version is able to handle anything.

ptitSeb commented 7 years ago

No, it hasn't really changed. Some more format are supported, and Compressed textures are not shrinked anymore (it was before but I'm not sure it still was the case at the time you mentioned).

MagaTailor commented 7 years ago

OK, tried that and it made no difference (other than lowering the picture quality).

Factoring your previous comment in, it's just a bunch of regressions affecting the ES1 backend. I haven't changed my system's configuration and besides, I remember using gl4es much later than Dec. 3rd without these issues.

MagaTailor commented 7 years ago

Illustrating the remaining issues: (good/bad) neverball_good neverball_bad

MagaTailor commented 7 years ago

freeorion_good

freeorion_bad

MagaTailor commented 7 years ago

glest_good glest_bad

ptitSeb commented 7 years ago

For ToME, it stiil seems to me that some texture didn't upload correctly (the White rectangle in ES1 / Black rectangle in ES2). To try track what's wrong, can you activate logs in texture.c (using latest commit cb268f4b1102e8e62bf16fcc6c7938d4c5162ae0) and see if you have som GL_INVALID_whatever error in glTexImage2D or glTexSubImage2D?

For the other stuff, it's different, and it seems I have lost something in the state traking.

ptitSeb commented 7 years ago

For FreeOrion, e1e8c0323441ba8898f8ce04c341ce78f7e16034 (and the previous commit) should fix it.

MagaTailor commented 7 years ago

FO has been fixed indeed and as for te4, I don't see any GLINVALID errors, so I'm attaching the log. texture.zip