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

@Hans
yes, really and yes, exactly
Took me quite some time to finally make them adjust their "article" back then (it's not just months but ~ a year ago btw., time flies), annoying.

@Daytona675x

I made wrong assumptions, I thought that EGL_Wrap was an OpenGL ES 2.0 wrapper for Nova just like yours. Should I stop reading Amiganews.de?

Apologies.

@Kamelito

Nah, don't stop reading if you enjoy the site. Just stay critical and ask questions when they need to be asked.

@Daniel

Great summary of a slightly confusing topic.

@Hans,Daniel
As Capehill progress well with tracing of ogles2.library, i come back to fricking shark issue. Now with ogles2.library v2.4 it crashes on the same place, but crash a bit changes. I.e. the same stack trace, but while before it was lbzu r6,1(r8) where r8 = 0xffffffff , now it crashes on lwz r9,0(r4), where r4 = 00000000.

While 0xffffffff mean end of memory, 0x00000000 mean unitilized memory, which probably can point us on some other direction ..

I rechecked twice : with ogles2.library v1.22 we have 0xffffffff, with ogles2.library v2.4, we have 0x00000000. Probabaly issue just shifts a bit, but at least now its not end of memory, but unitialized memory (maybe it was even with 0xffffffff).

There is current crashlog:

@kas1e

Attempting to load data from 0x00000000 is a null pointer error. AmigaOS doesn't set uninitialized memory to null, so this isn't necessarily uninitialized memory. A pointer may really have been set to null.

Hans

@Hans,Daniel,Capehill

About that fricking-shark issue: with help from Capehill we patch and ogles2 and warp3dnova, and we catch those functions:

from ogles2:

glCompileShader
glGenBuffers
glBindBuffer
glBufferData
glBufferSubData
glDeleteBuffers
glEnableVertexAttribArray
glVertexAttribPointer
glDrawArrays
glDrawElements

from warp3dnova:

CreateVertexBufferObject
DestroyVertexBufferObject
VBOSetArray
VBOGetArray
VBOGetAttr
VBOLock
BufferUnlock
BindVertexAttribArray
DrawArrays
DrawElements

And there is log (with stripped at begining about 25mb of data while game starts, show first screen, etc, just last 2mb till crash happens):

http://kas1e.mikendezign.com/aos4/gl4 ... w3d_and_gles_patching.txt

As can be seen, all data still looks sane (right ?) , and seems it crashes right after VBOLock().

Also see what happens after crash: 6 bad access and then our BufferUnlock. Then again after VBLock() 6 bad acess, and BufferUnlock. Its repeated 4 times and then all continue fine since then.


I do compare it with pure debug version of warp3dnova, and there is also point out on crash after VBOLock() , but with sane values, there is:

http://kas1e.mikendezign.com/aos4/gl4 ... shark/whole_w3d_debug.txt


After seeing logs, ptitSeb says that it seems the crash happens while filling the VBO with new data (because BufferUnlock() hasn't occured yet). Also, don't forget gl4es doesn't create any VBO, ogles drivers does.

And as it all about texture in stack-trace, that Texture 0 is a valid texture. It's not used for the blitTexture function, but it's used sometimes in games. And blitTexture doesn't create any texture anyway. The texture is already created, bitTexture only create a few vertex array and use glDrawArrays to draw the texture.

@all
As Daniel says in ogles2 topic he fix issue with fricking shark, cawabanga ! Thanks all for time :)

@Daniel
Found that since ogles2.0, in quake3 i can see some blinking textures there and there. Retested many times that with 1.22 it works, and that since 2.0 with every next release (and included 2.6) issue still here. There is video over ogles2.6:

The issue visibly on the gate's main textures, but also sometime you can see how some "line" draws all over the game. Looks exactly the same as it was with foobillard++ before (while foobillard works fine with 2.6 in all modes).

Start watching from 25 second:

https://youtu.be/xKPWCviyQbw

Those blinks remind me the same blinks i have with foobillard when disable batching mode in gl4es, but which you fix lately in 2.4 & 2.5. It looks like it can be the same kind of issue just hiding somewhere else ?

I also notice the same kind of issue (i think its the same) in RTCW Reboorn when checking those sky-bugs , but its too dark in that place to video-capture it normally. But it looks exactly just in q3 on video above, just in some other places.

@kas1e

Is the FPS counter behaviour normal for gl4es build? I don't remember seeing that kind thing earlier, like bouncing between 80 and 120 FPS (or whatever the readings are).

@Capehil
Yeah its normal. The same for your sdl2 minigl build as well

@Daniel
Another issue we find when ptitSeb made some new changes in GL4ES:

Issue is with the default value of MAG filter for texture, that should be GL_LINEAR and not GL_NEAREST (we look at the spec here: https://www.khronos.org/registry/OpenG ... /xhtml/glTexParameter.xml for the default for other parameters).

So, ptitseb made some commit where he don't change Texture parameter if unneeded, and gl4es expect Mag filter to be GL_LINEAR , which in end cause some visuall differences as seems that GL_NEAREST is our default.

@Daniel,Hans
That bug in Quake3 with blinking textures which didn't happens in 1.22, but happens from 2.0 till 2.6 of ogles2.library, seems have no connection to the bug i see in RTCW Reborn (as i was in hope that it the same) , as at least with 1.22 of ogles2.library bug in RTCW still here, so, it can be also and not ogles2 as well.

I was able to catch the video of that bug too , there is:

https://youtu.be/nBVKit7tPPU

Also i was able to catch those "white lines on the walls" bug on the same place where we catch sky-bug before, and this time i can come very close to place where it happens and can be seen that it looks like as some missing/trasnaprent line, but not white one. It was white on the walls before because it was sky which trying to showups over transparent line.

There is:

https://youtu.be/nBVKit7tPPU

Strange through that it happens very rare. I see it only one time on floor, few times on the walls,etc. Maybe there is more, just maybe it visibly only when sky is under the hood, so "white" color can be seen.

@Hans
Can that transparent-lines be same issues as was in quake3 with "lighting beams" some time ago ? Maybe not the same, but close to it ?

@kas1e

The flickering textures looks a bit like "z-fighting," where one surface occasionally ends up with a coordinate just above the other, so it ends up drawn on top. Alternatively, is something inverting the order in which those surfaces are rendered? That would have the same effect.

EDIT: Or, did the z-buffer get switched off temporarily?

I doubt that the transparent/white lines are similar to the old Quake 3 lines. If you look closely in the videos, you'll see that the line appears to come from an outer wall, but it appears on-top (or through) the inner wall. Look closely at the line visible from about 11-15s in the first video from your last post.

Hans

@kas1e
https://youtu.be/xKPWCviyQbw
Please upload the respective savegame to my ftp. While I'm a pretty good UT99 and DukeNukem3D player (well, at least I was ~20 years ago) I always hated Quake and for some reason always get a headache and the need to vomit real quick with it :P

The other vids I have no idea what this could be, looks like a combination of z-fighting with object sorting order changing.

@Daniel
Quote:

Your ftp/reports_here/q3config.cfg.lha

Unpack that file to quake3/baseq3/ (overwriting old q3config.cfg)

Then once start, choice "single player", and there Q3DM7 (so level 7). Once game starts, you not always will be spawn on the same place as on video, but level itself veeery small (just few rooms), so you can easy found those gates in case they not always will be starting point. Sure that blinking error happens not only on gates, just on them it most of time easy reproducable if walking/run/jumping around them.

@All
About those "White lines" in the RTCW Reborn, i just put link to the wrong video (see in post 572 there the same youtube links 2 times), second one where lines shows quite clear should be that one instead:

https://youtu.be/_6YQq9mHxiY

@kas1e
Quote:
Thanks! I can reproduce it. Interesting: it only happens if r_ext_compiled_vertex_array is 1.

EDIT: fixed it (ogles2_wip on my ftp). Comes at a significant performance loss though. The bug existed prior to 2.0, only that since 2.0 it became much more likely to show up.

@Daniel
Yeah, bug fixed, and yep, perfomance loos is pretty big everywhere :( There some results:


q3 1024x768 : speed loss ~ 12 fps
q3 1600x1200 : speed loss ~ 7.5 fps

fricking shark speed loss ~3fps

neverball: speed loss ~5 fps
neverputt: speed loss ~15 fps

foobillard++ : speed loss ~1.5fps

rtcw reborn 1280x720: speed loss ~3fps

Maybe even better didn't fix that bug and keep it as it ?:) At least in all other apps it didn't happens visually, only in q3.

@kas1e
Quote:
Nay! If you look at the absolute numbers the speed loss is measurable, yes, and therefore it is significant, but it's certainly not even near as severe as is the bug that got fixed...
I mean, AFAIK it's e.g. Friking Shark 100 -> 97, Neverputt 390 -> 375, Foobillard 55 -> 53.
Sorry, but those few fps really don't justify to keep that bug inside.

Quote:
Luck. Well, not exactly, it depends on many factors. Yes, depending on how a program's rendering strategy / code looks like, the chance for the bug to reveal is higher or lower. And yes, for some games it actually is 0. At the moment!! Some future code change (even in Nova) may very well change that... The transition to ogles2 version 2.0 was such a chance-increaser.
So all in all I'd not even recommend to add some glHint to optionally disable the fix.

@Daniel
Yeah, only visibly real speed los is q3, in which we just collect fps by fps and once we was able to won over minigl, we again jump back :)

But sure, that all right, less bugs less problems.

@Hans
Knowing that you are busy with everything, but just to remind after 2 months, is it possible that you can find some time soon to working on nova again ?

What i mean is that bug:

http://www.amiga.org/developer/bugreports/view.php?id=407

(in which we find that seems register allocator may be leaving holes)

That one is important to made another good title to work.

Also, what you can suggest of how can we debug why Nova fail to made FrickingShark shaders works correctly, while compile them fine ? (taking in account, that shaders are ok, and that on win32 and linux version the same code which use those shaders works correctly).

One thing is when shaders didn't compiles, but another when they compiles but fail to render stuff as should.. At moment i only think about taking one of those shaders, and compile some tests case on few platforms, to compare how it looks like and how it should looks like.