GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

@kas1e

I'm pretty worn down.
Work keeps stalling free time projects.

I can wait for the next full release or whatever kind of solution you'll come up with.

Right now I try to calm down and recover whenever I can and with whatever works...Amiga stuff is not one of them, but I'll try to keep up

@kas1e

How can I compile libGLU_gles4.a for clib2?

Last year,you sent me clib2 version of GL4eS sdk for clib2 but that library is missing.

I want to try compiling wipeout-rewrite with clib2 to see if it makes any changes with wrong colors

@Sinan
I build today's version of GL4ES and GLU_gl4es for clib2 , so you can grab them there:

https://kas1e.mikendezign.com/aos4/gl4es/clib2/08_september_2013/

Through, i didn't test them, just build. In theory, gl4es should contain additional fixes as well, so worth to try both libs.

But i am not sure that swapping of C libs will fix color issues, as they look like casual endian byte swap issues.

@kas1e
Is there a new build of SDL2_gl4es ?

Last one is pretty old. Or, are there any instructions on how to build with updated releases?
Finally, what is the latest gl4es available?

Thanks for all the work you do to make it easier for everyone else.

Dave

@dave
Everyone can build latest version of gl4es for newlib or clib2, following details in the readme:



And then "make".

If you need build for clib2, then all the same, just add:




To build SDL1 and SDL2 recent version with applying necessary changes to make it works with GL4ES, you can just check this commit history for both SDLs and apply the same on recent SDLs:

https://github.com/kas1e/SDL2_GL4ES
https://github.com/kas1e/SDL1_GL4ES

@kas1e Looks like I got gl4es built. How did you build GLU_gl4es?
Also when testing my compiled version of libgl4es.a it works way slower than yours. Any ideas about that?

Thanks for any insight,
Dave

@dave555
Quote:

It's usual ./configure ; make of ptitSeb's version of GLU, just be sure that SDK/Local/common/GL/ directory contain GL4ES includes, and not MiniGL ones and as it contain some older version of necessary for libtool/etc files, you may want to run autoupdate/etc as well. Like this for clib2 build:



And same if you need newlib version, just omit clib2 flags (so newlib will takes by default):



Ready library will be in the .libs directory, named ligGLU.a which you just rename like i did for SDK to libGLU_gl4es.a.

But of course you can keep it as libglu.a as well of course, just it will make logical mess with minigl's one in SDK and you will in needs to keep an eye on it always to not mess one with other, so better to rename.

Quote:

How you detect that it is slower ? On what tests ? And what versions do you compare : my one from SDK, or my one which i uploaded there in previous message ? The one in SDK is for newlib and a 10-15 months old one, and the one i upload few posts back are for latest version of experemental-in-progress clib2 and from recent gl4es repo (which may have regression too, of course).

Maybe you didn't reboot when test and some LIBGL_* left_overs from Huno's EGL_Wrap in ENV: left, or, maybe you build debug version by default with -gstabs and without optimization turned on by some reasons ?

@kas1e thankyou for the info. Very much appreciated.

Quote:

It was on program that I wrote. It's about as fast as a software only renderer when linking against the lib I compiled versus yours which runs nice and fast. I am using newlib and your version is from your sdk archive. I compiled using your instructions but obviously using a new clone of gl4es. Is there any chance you could do a new build for newlib so I can have a direct lib to compare against (file size etc) to help see what's going on?

Thanks again,
Dave

@Dave
Quote:
And what if you use my one for clib2 compiled a few days ago in that thread ? It also fast as newlib one from SDK, or slow the same as your build ?

@kas1e I haven't tried as my program, and sdl2 are compiled with newlib. Assuming you can't link a clib2 with newlibs

@Dave
Quote:

Right.. Ok, so here new build of latest gl4es for newlib:

https://kas1e.mikendezign.com/aos4/gl4 ... september_2023/libGL4ES.a

And if it will be slow too, can you then share with me your test program, so i can play with to find out what wrong ?

@kas1e Howdy.

I tried the newly kas1e comnpiled newlib version but its still slow (slower than software only rendering actually).

My code isn't ready for prime time yet, but I did notice a couple of differences in the GL4ESBANNER output, so not sure if that is relevant.

@Dave
It can be gl4es regresstion then, but just in case : be sure you delete .psa directory (it's precompiled shaders dir created after you run app build with gl4es, so maybe old ones can cause harm).

Anyway, test case need it so i can find what wrong (if i will be not able to reproduce it with my tests).

In meantime, stick to SDK's version then

@kas1e
Looks like it might be this commit that broke things:
https://github.com/ptitSeb/gl4es/commi ... 0c1885df6f3097446f68f4083

commit previous to this is running at fast speed, but this one slows to a crawl.

Dave

Quote:

So the offending line in gl4es.c is (line 253 of newest version):
glstate->list.active->use_vbo_array = 2;

If you comment that out (even on the newest commit), then everything runs at speed.

Dave

@Dave
Can you maybe create a BZ on ptitSebs site for with explain what you find, etc ?

@kas1eQuote:

What is a BZ?

@davec555

A bugreport

@samo79Quote:

Assumed so

And will do.

Dave