... What is GL4ES ? ...

GL4ES is an OpenGL 2.x/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android and AmigaOS4. Writen by Sebastien "ptitSeb" Chevalier.


NOTE: all images are clickable for urls or fullsize images !




For AmigaOS4 translation done via ogles2.library (written by Daniel "Daytona" Muessener) and which in turn works on top of warp3dnova.library (written by Hans de Ruiter).

With GL4ES we have not only OpenGL1.x as with MiniGL, but OpenGL 1.x, OpenGL2.x, and even some limited OpenGL3.x support.



Q: How it works?
A: GL4ES emulate fixed-pipeline via auto-generated GLSL shaders and send them to ogles2 which in turn parse & patch them, convert to SPIRV format and send to warp3dnova for compile and execute.

Q: Are shaders that come with OpenGL apps works too?
A: Yes. They also go through gl4es for adding little bits, and then the same send to ogles2/warp3dnova for compile and execute.

Q: Why not made full OpenGL? Why just not port MESA over Warp3DNova?
A: Because it's harder and there weren't thousands of developers willing to do so. Only Daniel was able to take the task, and to make something in the real time frame it was chosen to go the OpenGL ES route. But anyone feels free to made MESA port over Warp3DNova, of course.

Q: Is it faster than MiniGL over old Warp3D? Is it better?
A: It is faster in most cases a lot. In some cases where old GL_BEGIN/GL_END route used, speed can be the same, just without MiniGL bugs. But in other cases it much faster. As GL4ES works over opengles2 & Warp3DNova, we hasve hardware TCL, VBO and all stuff.

Q: Why some things are fast, but other ones are not _THAT_ fast as we hope ?
A: Because currently, we don't have DMA/GART implemented in graphics drivers.

... Intro ...

As of now, it's one year passed since the first GL4ES releases for AmigaOS4 and just 3 months since the first release of GL4ES SDK. While work on GL4ES was started 3 years ago as a fork of glshim project, AmigaOS4 at that time wasn't taken into account. Only 1.5 years ago I made first attempts to made an AmigaOS4 port and with a big help of GL4ES developer (ptitSeb) and our developers like Daniel, Capehill, and Hans that was done. Through to note, that all actual code-work on amigaos4 specific parts in gl4es still done by ptitSeb, and I play there the only role of tester, bug-hunter, and helper with pure amigaos4 related parts in some places.

It is also 3 years ago first releases of Warp3DNova and ogles2.library out, and because of work on GL4ES, there were a lot of bugs fixed and new features added in both Warp3DNova and ogles2.library. Daniel does a lot of hard work on optimization of ogles2.library in all possible cases and today it gives pretty decent results. Hans does fix lots of bugs lately in Warp3DNova as well but probably lacking DMA still shows issues and we do not have the speed we all can hope in some cases. It's still all very much better than old MiniGL and Warp3D combo, but in some cases non-having DMA/GART is a bottleneck.

Now, before we go to releases, there is a list of components you need to update firstly (which you do through Enhancer's Updater).

1). Radeon HD card with RadeonHD 3.7 driver as a minimum. Polaris card is not recommended due to low FPS (see explaining further).
2). ogles2.library v2.11
3). Warp3DNova.library v1.68
4). Fast enough AmigaONE

For first, in RadeonHD 3.7 there was a very important bug fix when things simply crashes on X5000 and Tabor when you pass 256mb barrier of filled GPU memory (some of you may remember issues with RCTW Reboorn crashes on X5000 with hi-details, or Jedi Outcast, so that it: on high details, games want more than 256mb of GPU video memory => crash). Hans fixes it, and so you must update if you on X5000 or on Tabor.

Also as i point out you should have RadeonHD, NOT Polaris card ! I mean for real. The issue there that most of the games and apps will give you much worse result in speed in comparison with RadeonHD cards. The only exception is "Spencer" game, which gives better results on Polaris card, but all other stuff like all gl4es apps, AmiCraft (non-gl4es based), some test cases, all of this give worse results. For example, if with RadeonHD you have somewhere 60fps, then with Radeon RX you will have just about 40. The reason is unknown, but we think its because of no DMA implemented, and by default power management expects DMA to be there, and so didn't rise resources up. But all that to be seen if that the case, but for the time being _NO_ Polaris recommended if you want to have fun with those games with good FPS. Use RadeonHD card and RadeonHD 3.7 drivers as a minimum. When the time will come then Polaris also can be used for those games, but not now.

Also, you need to update ogles2.library and warp3dnova.library to the versions I point above (2.11 for ogles2 and 1.68 for warp3dnova), as there was some important bugs fixed and features added, without which games will work bad, or wrong, or slow, or not works at all. So, update!

... Release time ...

Now, after a wall of text, let's start:

1). Irrlicht Engine 1.8.4



Back in past many of us always asking for some "demo/game engine" for modern Amigas with OpenGL support and stuff, which very well tested, documented and feature-rich. There is : Irrlicht Engine.



The Irrlicht Engine is an open-source realtime 3D engine written in C++. It is cross-platform, using D3D (for win32), OpenGL (for others) and its own software renderers. It is a stable library which has been worked on for nearly 20 years. Irrlicht got a huge community and is used by hobbyists and professional companies alike. The engine is well documented. You can find enhancements for it all over the web, like alternative terrain renderers, portal renderers, exporters, world layers, tutorials, editors, language bindings and so on. And best of all: It's completely free.

For the years there were books written for, for example, those ones (press on the image to go on amazon page):



The engine also big-endian aware for now (it was originally, and in last year I with help from all developers (and Irrlicht ones, and our ones), fix almost all remaining endian issues).

The original release of 1.8.4 was in July 2016, and work on 1.9.0 is ongoing right now with a lot of new features added and bugs fixed. Once there will be 1.9.0 out, the AmigaOS4 version will come out as well.

Through, 1.8.4 already very enough for making the games, and as examples of its usage there today 3 new games based on it.

AmigaOS4 port is on Github here: https://github.com/kas1e/Irrlicht/ and if you find any amigaos4 specific issues plz report them on issues page here: https://github.com/kas1e/Irrlicht/issues (and yes, odyssey didn't work with Github anymore, so you had to use Linux or win32 for Github).

It is released in 2 variants (which you can grab from os4depot as everything else):

irrlicht-1.8.4.lha - full archive, with all the sources, includes, documentation, precompiled binaries, link library and media files. Size of archive 115mb.
irrlicht-1.8.4_minimal.lha - that just includes and newlib's link library which is enough to start code over it. Size of archive 4mb.

The engine is fully tested to be compiled and on AmigaOS4 natively and over cross-compiler (see the readme_amigaos4.txt inside). As a basis for makefile(s), I use the latest GCC 8.3.0 from adtools, so if you on something older, you will have needs to adjust makefiles a bit (by removing -athread=native)

For examples check 'bin/AmigaOS4/' directory, because the directory 'examples' is for source codes. Every example on running asks you what rendering backed you want, so for AmigaOS4, it can be: OpenGL (via GL4ES/ogles2/warp3dnova in our case), Burning's Software Renderer (very accurate) and Software Renderer (not very accurate, but faster).To close example press alt+f4, or press on the close gadget as usual.

NOTE!: If you wish to program over Irrlicht Engine, you also should be sure that you have GL4ES SDK installed.

Compiling over MiniGL with some hacks possible, but it gives so bad results in compare, as well as gives lots of visual and crashing bugs. But for sake of tests, I was able to make some hacked MiniGL version just to show the difference (at least in those examples which runs somehow and before they crash:) ) in compare with gl4es one. See that pretty graph (as with all other images there, click on it for full size):



And as usual, a video:

Youtube video of Irrlicht Engine in action on AmigaOS4, 1920x1080 full HD

2). SuperTuxKart 0.8.1



One of the first Irrlicht based games I was able to deal with is SuperTuxKart 0.8.1:



One may ask why 0.8.1 and not the very latest one? There are 2 reasons:

1). That was the last version where they use the public version of Irrlicht, and since 0.9 they move to their own engine, porting of which means porting another engine just for one game (and I am not sure, but probably they also dropping big-endian support since that too).

2). Their latest versions pretty slow even on the modern PCs (tested it myself of course), while visually they not _that_ better than 0.8.1 as one may expect for such an fps drop.

Surprisingly the hardest part there was to deal with amigaos4 paths (full of them, in all possible places, in different ways of usage). As well a game does use heavy Ftell()/Fseek(), which found some problems in Newlib, which was fixed in and will be available in the next os4 update, but in the meanwhile, I add some workaround code, so loading will be fast and on public Newlib.

NOTE!
One sad remark though: Don't enable "use frame buffer object" in options, or you will then crash with "invalid FBO attachment" when you choose a car. The issue is known, and we still trying to understand where it comes. Visually, without that enabled, it only gives you a little bit of slowness when you choose a car (rotation of cars will be not very fluid), but in other parts and in actual gameplay you will not notice that. Once we fix a bug I will make another release.

On x5000 with RadeonHD and latest ogles2/warp3dnova, you can expect up to 60FPS on some levels, while in other ones you may drop to just 15-20. Most of the time you will be around 30-40.

A game needs about 350 MB of RAM, 350 MB of GPU memory, 40 MB of system's VRAM memory and 350 MB of HDD space.

You can see it on video:

Youtube video of SuperTuxKart 0.8.1 in action on AmigaOS4, 1920x1080 full HD


3). H-CRAFT Championship



H-Craft Championship is fun to play sci-fi-racer. It features 28+ racetracks, a fresh design and unique driving physics. It comes with a challenging Championship, an arcade, and 2 time-attack modes. Also on "Rivals" up to 4 players can have an exciting tournament on a single computer.



The game was commercial and closed-source, but just a few years ago sources were open.

On x5000 with RadeonHD and latest ogles2/warp3dnova, you can expect 50-65 fps in 1920x1080.

You also need to read (or at least check) the tasty PDF coming with the game. As the game was commercial, it means that all was done as should, and it comes with good pdf tutorial.

There are a few brief moments which probably need to take attention on before you start:

-- to have FPS counter enabled press "F11" in an actual game.
-- to change between fullscreen/window mode, change in media/config.xml on line 23 "fullscreen" value (1 - fullscreen, 0 - window).
-- to change between different camera views press "C"

A game needs about 250MB of RAM, 300 MB of GPU memory, 35 MB of system's VRAM memory and 250 MB of HDD space.

See how it all in action:

video of H-CRAFT Championship in action on AmigaOS4, 1920x1080 full HD


4). Nights of The Zombies



NIGHT OF THE ZOMBIES it's a first-person-shooter where you must survive endless waves of attacking zombies, earning points that may be used to purchase weapons, unlock new areas, etc. Every next round, zombies become stronger, faster and more hungry!



Game is close-sourced, but the author gives me sources to make AmigaOS4 port, and later allow to made Pandora port by ptitSeb as well.

That one takes a bit of love:

-- we rewrite close-sourced IrrKlang (3d party sound/music library for Irrlicht which game use for win32) to SDL_Mixer
-- fixes a bunch of errors which win32 somehow handle and didn't crash
-- add support of not only old Irrlicht , but also of new one.
-- because of that game was fixed alignment issues in MS3D mesh loader of Irrlicht (by Salas00 and Corto).
-- rewrite a postprocessing shader to not use texture arrays which warp3dnova didn't support yet.
-- fixes a bunch of issues with signed/unsigned ints
-- fixed lots of warnings which GCC 8.2.0 throw and compile whole code with -Wall and -O4
-- fixed in gl4es calculation of FOG in pixel shader instead of vertex (initially that was done for speed reasons, but seems mesa on Linux and win32 doing it in pixel, so..)
-- usual endian and paths fixes

A game needs about 450 MB of RAM, 500 MB of GPU memory, 10 MB of system's VRAM memory and 350 MB of HDD space.

You also need 1280x720 (widescreen) or 1024x768 (normal screen) for fullscreen modes.

On running you will be asked if you want fullscreen. Pressing "y" will run it in fullscreen, and "n" in a window.

There is a video (with some experimental 1920x1080 mode added for fullscreen, which is not yet in release):

Youtube video of Night Of The Zombies in action on AmigaOS4, 1920x1080 full HD

5). Now, there are also 3 re-releases of already released games with some noticeable changes:

5.1). NeverBall/NeverPutt



Tilt the floor to roll a ball through an obstacle course before time runs out. Neverball is part puzzle game, a part action game, and entirely a test of skill. Also found here is Neverputt, a hot-seat multiplayer miniature golf game, built on the physics and graphics engine of Neverball.



The new version gives us +15 fps in Neverball in general. While in some levels it was already nearly 80 fps in 1920x1080 (and now its about 100), in more heavy levels speed increase will help much. There is also hope that new version may help with issues x1000 owners have with a previous build.

I didn't made a new video of it, as its all the same as before just faster. So you can watch an old video if you didn't before:

video of NeverBall 1.6.0 in action on AmigaOS4, 1920x1080 full HD


5.2). Foobillard++



Foobillard++ was created as a continuation of the Foobillard's development. It has a realistic physics engine and a computer opponent AI. It features an optional red/green 3D stereo view (requires anaglyph 3D glasses), a free view mode and an animated cue. It is also a complex OpenGL 1.5 game, that uses cascaded display list, line stipple and TexGen works, which are good stress-case for our gl4es->ogles2->warp3dnova combo.



With that version, speed is DOUBLED. Now you can set the maximum possible details, with all "very high" settings, and be on the 60 fps all the time.

There was worth to capture a new video, as with maximum details and doubled speed it looks better (fullscreen mode shows at 4:00 in the video, and there is better visibly how all can look and feels now)

video of Foobillard++ with VBO support in action on AmigaOS4, 1920x1080 full HD


5.3). FrikingShark



FrikingShark is a Remake of Taito's classic Flying Shark with a 3D C++ engine that uses OpenGL and OpenAL.



The new version gives +10 fps. Also with new warp3dnova 1.68, CompilerShader() are ~2.5 times faster and with ogles2.library 2.11 precompiled shaders support added (which still limited by Warp3DNova's CompilerShaders() speed, but still) and micropauses when you first-time play in a game in the first level starts to be more micro and rare than before :) Also one of original shaders bugs were fixed in warp3dnova, but there is still some left, which is hope to be fixed soon or later, and game can be played with its own shaders.

There also an old video, as its all visually didn't change much, just a faster a little bit:

video of FrikingShark in action on AmigaOS4, 1920x1080 full HD


6). GL4ES SDK.



In the end there first update to GL4ES SDK.

As on os4depot you always have the latest version of SDK, I create a GitHub repo where all versions will be placed. It's always useful to have older versions of SDK in case of some bugs introduced in the last one.

https://github.com/kas1e/GL4ES-SDK/releases/

Remember, that work on SDL1/SDL2 done by Capehill, and gl4es updates done by ptitSeb. All I do its wrote replacement to MiniGL for both SDL libs, so they use GL4ES instead, and pack this all up.



So, changes are:

General:

- updated GL4ES Documentation
- updated SDL1, SDL2 and GL4ES libs, see below for changelog.
- fixed typos and grammars in the readme

GL4ES (updated till commit done Dec 19, 2019):

- use -gstabs for AmigaOS4 debug builds
- Using real VBO now by default for glList() & glBindBuffer() (help a lot to games which use those functions, sometimes speed gain is very high).
Also added LIBGL_USEVBO environment so it can be disabled/enabled. See usage.md for more details.
- Exposed GL_ARB_map_buffer_range extension, and fixed its behavior (help Arx Libertatis, using real VBO)
- Don't try to clean resources if GLES lib is already unloaded (fixed crashes with games/apps which didn't clear/free textures on exit)
- Fixed a nasty bugs with texture handling (when going gl(Sub)TexImage2D on other than GL_TEXTURE0 (helps eDuke32)
- Some FPE Fragment shader optimization on (multi)texturing
- Force to recalculate mipmap if needed after a glCopyTexSubImage2D
- Added support for GL_NV_fog_distance extension
- Fixed an issue with two-sided lightning (fixed ManiaDrive)
- Optimized Instanced drawing (should help FEZ)
- Fixed LIBGL_RECYCLEFBO 1 option (when that environment set to 1, then if FBO is deleted, it's then not really deleted but goes on a "pool" of unused FBO.
Then if an FBO is recreated and the pool is not empty, that "unused" FBO is taken from the pool and used).
- Added internally some betters ways to hack shaders on the fly when that really need it.
- Added support for GL_R8 as internal format (helps a lot video in Desperado)
- FOG is now calculated per pixel (instead of per-vertex) shader (help Night Of The Zombies)
- Force 24/8 for LIBGL_FB=2, also always report 24/8 even if depth is 16 when stencil is 8
- Fixed an issue when using GL_UNPACK_BUFFER with glSubTexImage2D and some shrink mode (or automatic NPOT->POT conversion)
- Redone a bit a shaderconv to avoid memory overwriting

SDL1_gl4es (updated till commit done Sep 21, 2019):

- A window wasn't active by default after uniconification.

SDL2_gl4es (updated till commit done Oct 19, 2019):

- Fix mouse wrapping (help Irrlicht Engine when used with SDL2)
- Some debug output was left unnoticed, removed.
- implemented SetWindowResizable()


... Outro ...

At the end of all wants to remind that if anyone has any issues or questions with anything from that release, plz write this in a dedicated thread on amigans.net. When there are many things, it's easy to forget something, so some fast-bugfixes probably will need somewhere.

And as usual, want to give a big thank you to:

to ptitSeb for gl4es and all his help with everything: https://github.com/ptitSeb/gl4es/
to Daniel for OpenGL ES2 and all his help with everything: http://www.goldencode.de/
to Hans for Warp3DNova and all his help with everything: https://keasigmadelta.com/
to Capehill for never ended work on SDL1/2, glSnoop and all his help with everything: https://github.com/AmigaPorts/SDL https://github.com/capehill/glsnoop
to AEON/AmigaKit because of which we have OpenGL ES2 and Warp3DNova: https://www.facebook.com/AEonTechnologyLtd/
to others for all the help and tests
Merry GL4ESXMAS!