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

@Capehill

Yes, sorry about that, here it is:
http://www.amigans.net/modules/xforum ... id=113837#forumpost113837

Do you have the modern theme in place?
And did you try to open it with unarc?

I don't know how you installed scummvm but sometimes "cp" cripples the theme file on copying.

Recopy it from yor source and you should be fine.

I can provide a static build tomorrow.

@Capehill

You've got PM

There are some more odditiies with ogles2.

If glsnoop is in place the start of scummvm is slow enough to see it.
1) the screen that is opened is not black but a mush of pixel lines in different colors, the same goes for the mouse pointer until the screen is fully loaded and both go back to normal.
2) If i return to launcher without closing scummvm (RTL from within a game) then the mouse pointer will be in either of two states.
--- 1 - It will be a box of mushed up gfx garbage or
--- 2 - it will be completely invisible (this is the case for about 75%)

@Raziel

I have also seen some transient visual issues with ScummVM/OGLES2 version ("first frame broken", "strange mouse pointer"). Could have something to do with texture update.

@Capehill

Thank you for the confirmation...glad it has nothing do with my hardware.

@Raziel

Added a frame counter print and some delay after SDL_GL_SwapWindow call in ScummVM code. The first frame is mostly pink, with some red and black pixels. The second frame is OK. If I disable either FBO or multitexturing in context.cpp, the first frame becomes black while the second is ok. Need more experimenting and understanding, and maybe some FBO test example. I have never used one, maybe it's time to try.

EDIT: fixed SDL function name

@Capehill

Thank you very much

@Hans

I reduced as much as possible FrickingShark shaders, so they still works fine and over gl4es on Pandora, and just on win32 version without gl4es.

Original shaders in use now are:

Vertex one:



Fragment one:



And with those shaders on win32 and on pandora with gl4es we have that:

(press open in new tab for fullscreen):




So all renders correctly, but on amigaos4 it fail like this:

(press open in new tab for fullscreen):



Pathes to textures of course fine and so on (because when shaders disabled, all renders fine from same code).


Also that how those shaders looks like after shaderconv of gl4es regenerate them and send to ogles2, and those ones we can test on our side (thank for glSnoop to take and see them easy!)

Vertex one:




Fragment one:




So.. now those shaders start to be really small, i hope it can be more understandable what wrong.

Maybe you have any idea of what to change for tests sake ?

I also will try to create some SDL2 simple test cases, which will use those 2 shaders, and see, how they reacts on win32/sdl2 and on aos4/sdl2 (so to rule out more involved parts).

@All
Is anyone can write some test code which will use those 2 shaders ? As i understand there need to be 1 texture be draws, but vertex shader with all that matrix and camera make me feel sad :)

@kas1e

Have you tried simplifying the fragment shader down to just the following?


If that's not working, then you could try adding: texcolor.a = 1.0;
That's just in case the alpha channel is missing. If the shader above works on AmigaOS 4 (as in, you see the texture), then you can gradually add back in the other code until you hit whatever breaks it.

Hans

@Hans

I just totaly remove the fog and from vertex and from fragment now, as well as some other parts. That how they looks like now:

Vertex:



Fragment:




So on win32/opengl and on pandora/gl4es i still can see textures, while on amigaos4 still same no-textures.

There is win32 look with those last-reduced shaders:

(press open in new tab for fullsize):




And there is amigaos4 one:

(press open in new tab for fullsize):



As you can see original shaders now very basic, but i assume the problem for us its those ones which generated by gl4es from them and which ogles2 actualy recieved:

Vertex one:



Fragment one:



Probably next step, is to take some sdl2/ogles2 draw-texture tutorial and put those shaders generated by gl4es in, and use them. So if it will works on win32 and fail on aos4 : alilua , almost close then.

Any ideas welcome :) Maybe problems with sampler/texure/arrays mixing ?

@Hans

So after spend few day on it, we seems found something. So..

Short story:

There is some bug on our part named "something about texture matrixes when arrays is in use".

Long story:

By default gl4es generate shaders with usage of arrays. As i show in last post, there are 2 simple shaders which give a bug on our side:

Vertex:



Fragment:



Now, ptitSeb added option LIBGL_NOTEXARRAY (so to not use arrays at all), and with that one BUG IS GONE ! And generated shaders are:

Vertex:



Fragment:



As you can see bug is gone just once we get rid of arrays usage in matrixes and in texCoords

And that what ptitSeb says:

---
It's something about texture matrixes yes, but what I'm not sure. Because, in a shader view, there is not such thing as a Texture Matrix. It's just a matrix.

I'm unsure what's wrong. You should ask Hans what could be wrong, I don't see any obvious way to explain the issue.
---


And, its not issue of arrays+Tecoords, its exactly issue with arrays+matrixes. I.e. we tried even those shaders and they fail on amigaos4 (i.e. without arrays in texCoords, just in matrixes):

Vertex:



Fragment:




So its exactly problem when matrixes used in array. I.e. issue is "uniform highp mat4 _gl4es_TextureMatrix[1];" + "_gl4es_TexCoord_0=_gl4es_TextureMatrix[0]*_gl4es_MultiTexCoord0;"

We think about maybe uniform was not found, but we do some test case , and it's not the case (at least in our simple test case)

@kas1e
Hans is probably not guilty this time, it's more likely me
I added code for GLSL input-arrays en passant back in early 2018 for version 1.18 when Nova finally supported structs and I implemented support for those, but the array-stuff was never tested (actually I didn't even mention it in the relnotes because of this).
Looks like the array-part is broken, at least that would explain what's happening (although a not found uniform would be the kind of problem I had expected first; maybe it's Nova after all - but let me check first ).
Please upload your most minimal test to my FTP, thanks!

@Daniel
Sadly we don't have the most minimal test at moment :( Its all tested inside of gl4es compiled inside frickingshark, and shaders in test are replaced ones in fricking shark.

I was about starting to create some test case which will use exactly those shaders taken as base some simple sdl2+ogles2 example with texture drawing, but didn't gone so far , as shaders in question use matrixes calculation, while that simple test case over which i tried to use them, are not. But maybe it will be easy for you to fix test case to make it work with holding original shaders. As far as i got there need to create some dummy(or not)-matrix-calculation code to make those shaders work as intendent.


There is archive:

http://kas1e.mikendezign.com/aos4/gl4 ... g_testcase_unfinished.zip

At top there commented out original shaders (so you can uncoment them, to see that original code with trawing triangle + texture over it works), and currently uncommented (but of coruse not working too) , those gl4es shaders with arrays which need to use in that test case.

Compile lines are at top of hello_texture_frickingshark_test.cpp file, for os4 it will be:


ppc-amigaos-g++ -athread=native -std=c++11 hello_texture_frickingshark_test.cpp events.cpp camera.cpp -o hello_texture_frickingshark.exe -lSDL2 -lSDL2_image -lpng -ljpeg -ltiff -lwebp -lpthread -lz

@kas1e
Thanks, that will do!
The weird part is that an uniform array with just 1 element should not break things inside ogles2 even if there's a bug in the array-support-code in general. But well, I'll check it out.

@Daniel
Quote:

Don't worry, i seems found 2 other shader issues :) (not related to arrrays), but waiting confirmation from ptitSeb that on his side on gl4es/pandora all ok before posting them there.

@kas1e

I was about to suggest you try bypass gl_TextureMatrix[0]... Looks like my hunch was right, but I was a little too slow.

Arrays of matrices should be working in Warp3D Nova (it's tested), but if it isn't then just submit another bug report.

Hans

@Hans,Daniel

So about those 2 new bugs i find in fricking shark shaders when we do test it with LIBGL_NOTEXARRAY.

issue #1:

There something with lighting. For first, whole game is "low-lighting". For second, when hit the enemies everything goes black. I.e. on the moment of explosion. Probabaly when fog starts (i.e. other shaders effects). But that bug disappear only when delete fully lighting code from shaders. When remove fog's code from shaders bug still there. Also as you will see on video, all textures are "low-lighting". I.e. textures of ships in menu, and whole gameplay in the levels.

Better to see it on video:

https://youtu.be/DKiTE6OCJjk

As can be seen later in the video, everything but not "water-ripple" effect and "fog / fire" are start to be black. So like only pure textures, and not other "shaders" effects.

issue #2:

There is some "water-ripple" effect : in the menu at begining, and in the game there and there. So, after i game starts, and you watch water-ripple effect somewhere (be it menu, or game), then after about 150-200 seconds, that effect start to disappear bit by bit, until fully not disappear. And only way to get it back its quit and re-run game (So shaders will reinitialized).

I recorder another video to show this : i start 1st level, fly to the moment where water-ripple effect visibly, then press "Esc" (for menu), and waiting 150 seconds.

On video better just move slider to 3:20 and see how from 3:30 it all start:

https://youtu.be/VyS2q1rSqRQ

I asking ptitSeb of course, if for him all fine, he say that yes, with or without LIBGL_NOTEXARRAY all works fine. He have an idea that issue with lighting (issue #1) , maybe a precision issue in the light calculation (and can be the same roots of issue #2). gl4es there use "high precision float in fragment shader" , so maybe related to that.

And there is those shaders in questions (original ones, not glsl, and pretty big ones):

Vertex:



Fragment:



Any ideas what can be touched/changed in lightings code in those shaders so to find out what cause issues ?

As positive note in light of bunch of new bugs, shaders start to be the complex ones, that kind of mean we go pretty far with nova/ogles2 :)

@kas1e

Quote:
We're using 32-bit floats (that's what the hardware supports), so it's not a precision issue. Do you know which variable is responsible for #1 happening? Once we know which variable is causing it, then we can track down where it's going wrong.

For #2, what value does the CurrentRealTime variable get up to when the waves start reducing. Perhaps the hardware cosine instruction doesn't work well with large values.

Hans

@Hans
Quote:

At moment i only found that if in vertex shader i replace line 91:

g_ambdiffspec=gl_LightModel.ambient+amb+diff+spec*gl_FrontMaterial.specular;

with that:

g_ambdiffspec=vec4(1.0);

Then bug disappear.

So that g_ambdiffspec are faulty variable, have any futher ideas ?:)


Quote:

Yeah, put prinf there , and when all starts it show 7.823000 at first, and then increases every redraw or so. Then when effect start to disappear as far as i can see somewhere around 80.xxxxxx .. Maybe a little bit before.

If i put there some static value (i mean in game's code), like 7.823000 for all the time, then, that bug didn't happens as it was : in menu and first level it seems (can be placebo too of course) all fine, but in second level bug 100% still there: i fly over sea , and somewhere in the middle effect ends.

What probabaly mean, its not CurrentRealTime, but probabaly something else. Or CurrentRealTime with something else, and setting it to static only shift problem a little bit.

I also printf WaterMappingSize and WaterMappingOffset uniforms.
EVerything strart with :

WaterMappingSize dMaxU = 50.500000, dMaxV = 8.500000
WaterMappingOffset dMaxU = 0.000110, dMaxV = 0.000000

Then, WaterMappingSize never changes, always the same values. And WaterMappingOffsset dMAxV never changes too , what only changes its WaterMappingOffset's dMaxU. And that one increases well till about 8.xxxxxx and somewhere at this point effect start to disappear.

But nothing abnormal in values ..

And we rechecked again on Pandora/gl4es and on win32 version without gl4es (win32's opengl) : in all cases when we run game with shaders, water effect didn't disappear. That only on our side :(

@kas1e

Quote:
Try removing the input variables to that equation one by one to see which one(s) is responsible (e.g., remove gl_LightModel.ambient first, then amb, then the next...). Hopefully it comes down to one of them.

EDIT: Maybe something's going wrong with one of the point light sources? If any value is/becomes "nan" (not a number), then the end value becomes "nan" too, which would probably result in black areas.


Quote:
Please submit a bug report for this. It certainly sounds like the cos() function stops working properly when the number gets too big.

Hans

@Hans
Quote:

removing only "gl_LightModel.ambient" : everything black all the time. Not only when hit the enemy, but all the time.

removing only "amb" : original bug, i.e. same as full line

removing only "diff" : original bug, i.e. same as full line

removing "amb" + "diff" : better than full line : this time "ground" is not blacks , but all others textures are still.

removing only "spec*gl.FrontMaterial.specular" : original bug, i.e same as full line.

So dunno how to find which one guilty when its mix of them..

Quote:

I just tried to add at top of PointLight setting to vec4(1.0), that:

ambient : no changes
ambient + diffuse : no changes
ambient + diffuse + specular : no changes

But then, i tried the same at bottom of function, so :

ambient : no changes

ambient + diffuse : "too dark" initial lighting of game start to be "fine" one, when i hit the enemy. Ground texture not blacks anymore, but all others are

ambient + diffuse + specular : game again starts as too dark, but when i hit enemy, everything start to be normal, instead of black. Then again back to "a bit too dark" , and when hit enemy again goint to "full light".

Its like, there several issues with lighting.

Quote:

Sure will do.

But are you sure about ? I mean, don't you need to check it by some test-case or something somehow , so to be sure that it is and so we can stop invistigate that bug futher ?

I just doing another test and pretty possible that your right, but still will share info there, so we all can be sure that we sure :) :

I just tried to set fCurrentTime to some static value, like:

{
fCurrentTime = 85;
iShader->second.m_piShader->AddUniform("CurrentRealTime",fCurrentTime);
}

So, results:

-1 - effect still there
85 - effect still there
86 - effect still there
100 - effect still there
140 - effect start to disappear, begining of visuall differences
150 - effect almost disappeared, just final end before disappear completely
200 - effect disappear completely.
300 - effect disappear completely.
999 - effect disappear completely.

From previous test in another post you can see that when it runs with original code where values increased , then its enough to reach 80-85 for fCurrentTime to make effect disappear. But if i put it statically like this, then there need to be bigger values.

For example, if i do something like :

if (fCurrentTime >75) {fCurrentTime = 100;}; then effect disappear completely once it reach >75 check. But that only when it reach those 75 from 0.

But if i do check like if (fCurrentTime >30) {fCurrentTime = 100;};, then effect didn't disappear when reach 30.

In other words when fCurrentTime value in static for all the time, then value should be a bit bigger to make ripple-effect disappear, while with increased fCurrentTime from 0, that fCurrentTime can be lower to make effect disappear.

But what is for sure, is that its indeed bigger values cause issues. So will create BZ about and put all the info inside.