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

@kas1e

Please pass on a big thank you to ptitSeb from us. All the help he has given in debugging GL4ES problems on AmigaOS is much appreciated.

Hans

@Hans
Yeah of course, passed :) He have no amigaos4, no machine for, not that he was paid even 100$ for all that work (not mean that any of us there for money, of course), so i also doing donations to him from time to time and for now making another one. Just so he see that we all apprecated his help.

And you with Daniel deserve it all as well. In terms of graphics support only real things coming from you both today.

@kas1e

On topic of GL4ES, in post 488 we have a fragment shader:

Quote:

I don't know how clever those GLSL compilers are, but it seems to me that it might be possible to discard the fragment before texture is sampled and color multiplied.

Quote:

@Capehill
Will bring that on ptitSeb, more optimisation the better.

@All
Checked beta 2.23 from Daniel, result:

1). Lugaru bug : fixed !
2). Quad_mystery.lha bug : fixed !
3). RTCW Reborn sky issues: fixed !
4). some issue in FooBillard++ with disabled merger : fixed !

Was in hope it will have some impact on fricking shark's crash with that 0xffffffff coming from nowhere , but nope, that one still there.

Cool anyway, thanks Daniel !

@kas1e

Are you talking about this crash?


Because this one i got just now.
Every time i hit an enemy the game crawls down to a near stop only to play along afterwards, after five or six hits, the crash happens.

ogles2.library 1.22 (26.08.2018)

@Raziel
Quote:

That only at begining, because gl4es generate shaders for every state, and there is no precompiled shaders support in gl4es at moment. Once you play a bit in first level, you can then exit/go again to, and all will be fine.

To fix those "pauses" fricking shark's shaders need to be working , and as i aware from mantis, Hans already fix it in 1.64, so when that one will be ready for beta, i can check if shaders work, and can then reupload version with enabled shaders.

As for crash itself, nope, first time see it. The crash about which i told are not happens in fricking shark uploaded on os4depot as i disable that functionality : i.e. it possible to press f4, to have stats such as fps and co, and so, once i enable it, and die or pass the level, then it crashes (crash skippable), and in the logs somewhere come strange 0xffffffff (end of memory) , which we currently don't know from where (need ogles2.library debug build which will printf VA,DBO, and whatever which can help to debug it). For os4depot upload "f4" do nothing, to avoid that crash for users.

@Hans
Just bring it here as that can be and gl4es related in end, so to discuss it in full all together : its about bug 388 (stride 0). With beta 1.64 it start to behave different.

If before it was something like:

WARP3D_SI.library: ERROR: Interleaved arrays with different strides detected in VBO 0x00000000

Then now, its :

W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x65F69630.
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60CDD230.
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60D05930.
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x65F64830.
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60CFC430.
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60CE6830.
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x6338FD30.

and so on.

Should we reopen ticket 388, or, it need to be discussed before and then created another one ? (if it will be Nova in end)

@kas1e

Bug 388 relates to handling VBOs with 0 stride, which works now.

If you're still getting that error, then you really do have interleaved arrays that collide with one-another.

Leave the bug report closed.

Hans

@Hans
What i mean, is that maybe fix somehow related to that ? Because with 1.63, i didn't have anything of that sort, only everything about VBO 0x00000000. But with 1.64, nothing about VBO 0x00000000 but all about other addresses.

Like issue still the same, just values changes.

I mean, should't those errors be there on serial with 1.63 as well, and not only about 0x00000000 ?

@kas1e

I may have also fixed the debug message so that it correctly print's the VBO pointer (i.e., the 0x00000000 was wrong).

Either way, the zero-stride issue has been fixed, so if you're still seeing that error then you really do have interleaved arrays that collide with one-another.

Hans

@Hans
Mmm.. If it was just wrongly printed VBO pointers then yeah, issue still here and need invistigate. Will try with ptitSeb a bit more then, thanks.

As for RTCW Reborn and those "lines" : sadly i can't catch shaders there, as Huno build it with some older gl4es , but dumping of shaders via environments was added just few days ago, so probabaly we need him to build RCTW with latest gl4es, and then can make more tests..

@kas1e

...Or we could patch the relevant library calls and capture inputs :)

@Capehill
Working on apitrace already ?:)

Yeah, probably catching ogles2.library's glCompileShader() and output content to stdout will be enough

@all

Good evening,
Excuse me but at the moment I work on the new functions of the EGL_Wrap lib and I have not finished incorporating the fix after what Kas1e pointed out to me but it can be used to test the new functions of ptitSeb for the shaders. for information I block on a lot of things because I have never received the latest updates from NOVA, yet I wrote several times matthew but without answers, I can not evolve at the same time as you, however have access to the lib opengles happily.
I just put on ftp my executable and the beta currently being created from EGL for you to advance in the rtcw shaders.
HunoPPC

Your wrapper is free while his is not so he just want to slow down competition I guess.

@Kamelito,
No I do not think (had less I hope not to be wrong saying this ) just there must be a reason but I do not know and I expect his response in private message
A new version will be available for all users and there will be glu and glut support complete with the gl4es of ptitSeb with the help of Kas1le
I added a lot of new features and new demos to show how the library works and especially the performance

HunoPPC

@Hans
With new rebuild from Huno with latest gl4es i was able to catch shaders which is used in the level where we have those strange lines/dots on the walls and on floor.

There just 5 pairs of shaders, they all generated right once i load level (all 5 pairs), and then while you play in level no shaders generated anymore.

So, there they are:

pair1 :

vertex one:



fragment one:




pair2 :

vertex one:



fragment one:





pair3 :

vertex one:



fragment one:




pair4 :

vertex one:



fragment one:





pair5 :

vertex one:



fragment one:




Vertex ones almost all the time the same (in case 1,2, 4 and 5), only from pair3 its a bit different (2 multitexcoords used).

But fragment ones always different , almost same by logic, but still different by values and stuff.

Probabaly one of those fragment ones can cause those issues ?

@kas1e

Quote:
Maybe, but I don't see how at this point. The shaders are all very basic, whereas the quake III mirror one had a more complex flow.

Will take a closer look later...

Hans

@Kamelito
Quote:
You obviously have a wrong picture, the dependencies look like this:

- HunoPPC's EGL_Wrap requires OpenGLES2
- GL4ES requires OpenGLES2
- OpenGLES2 requires Warp3D Nova

And the respective lib's functionality is:
- EGL_Wrap is a library which offers comfort functions based on OGLES2 and independent (game) helper functions.
- GL4ES is a library which offers "legacy" OpenGL functions (more or less extended MiniGL set of functions), in case of AmigaOS4 its OGLES2 backend is used.
- OGLES2.library is an implementation of OpenGL ES 2.x, a shader-based OpenGL version commonly used on mobile phones. Our AOS4 implementation uses Warp3D Nova.
- Warp3D Nova is a rather low-level AOS4-specific shader-based 3D driver implementation.

You see, it's all different things. There simply is zero competition. The contrary is true, because everybody gains if cooperating here. But you aren't the first who mixes things up here. I remember amiga-news spreading similar false info some months ago, only that in their fiction-story EGL_Wrap became a free competitor to a canceled ogles2

@Daytona675x

Quote:
Really?

Looks like some people are so busy looking for dirt that they're seeing it even where there's none.

Meanwhile we keep working...

Hans

P.S., What happened to the rofl smiley?