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

@All
Btw, if any of you don't use my prebuild SDK, but want to use the latest GL4ES from ptitSeb's GitHub, then be sure that you compile it like this:

Quote:

Also, there is a hint :

Quote:

And at the end of all, if you build the latest version from github, it has broken .psa support. Issue is:
http://www.amiga.org/developer/bugreports/view.php?id=869

So in meantime, you will need to disable .psa generation from gl.init in the function void initialize_gl4es(), by adding:

Quote:

But that only, if you want the very latest version of gl4es until I did not make a new version of SDK.

Also, as 2 more speed hints, I want to bring 2 moments that may help to speed things up in your ported OpenGL over gl4es apps.

By default _in most_ cases what the gl4es default states have are enough, but, in some cases, some additional tricks can be done to speed things up (and radically).

One of them is environment LIBGL_BATCH:

Quote:


What it means in the reality, is that when you build any of your apps, and it didn't have FPS you are satisfied with, or, you simply want to have as much as possible, you then in the shell firstly play with this Env before running your port like: "setenv LIBGL_BATCH 0-40", and so on, or 0-20 or 20-50, i.e. you got an idea.

If, under some values, you have really better performance, then to avoid issues/worry for users, you do as I do for NeverBall/NeverPutt ports: you just build your special gl4es build, with settings necessary value again in the initializing function of gl4es, like you do for disabling .psa. if you build the latest version. That trick brings in NeverBall quite a lot FPS more, the same as in my local test of Cube port. So, that must check always.


A second speed-hint which you may try for your ports, is happening for me only in the FrickingShark game, and so far i do not know the reasons of it, just found it by some luck. It's the usage of MAX_Textures in gl4es.

For FrikingShark i found that if i use in config.h #define MAX_TEX 8, or 4, or 2 instead of 16, i have better and better FPS in-game. And by better, i mean almost 50% increase with MAX_TEX 2. But that _ONLY_ in fricking shark. In no other games that make any difference (but I tried all my ports). The reason for that is still unknown but we think it can be some weird stuff in FrickingShark itself (i.e. game's code) that enables a VA for every existing TMU (without actually using them then). At least that would explain the performance differences. But that's just a guess.
Through it is worth noting that this was the second hint helping me to increase the speed.

So that is all you need for the current maximum usage of gl4es if you build your own versions.

Also, be sure your checked always https://github.com/ptitSeb/gl4es/blob/master/USAGE.md.

All the environment there works for AmigaOS4 as well, via "setenv LIBGL_xxxx blablaba". And there is a lot, and some of them surely can bring some performance too, just i didn't find with ptitSeb anything else more or less important as LIBGL_BATCH and that MAX_TMU switch in FrickingShark.

@kas1e

I assume you'll do a new gl4es release once SDL2 gets it's release?

@Raziel
I can build easily if you need new gl4es and new sdl2 at any time, but not the new full SDK as I have more plans for it to add. But for your use with scummvm, etc that will be more than fine, just tell me when you will need it

@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?