The OpenGL ES 2.0 thread

@Capehill

Could you maybe still, if time permits, test your available ogles2 version against the latest scummvm and see if the glitch is there?

Please?

Thank you

@Raziel

It might be easier if you share your config file for reference. Did you mean "Normal" scaler and 1x mode? After some quick tests using ogles2.library v3.4 it seems to work for me.

@Capehill

That's quite alright.

If your updated ogles2 version doesn't show the mouse pointer glitch AND doesn't suffer from the mini-screen glitch it's good enough for me.

Thank you for the test

@Raziel

I'm not actually a beta tester for this stuff, but since I sometimes report issues, I get test libs from Daniel. This is already an old lib, some January version IIRC. Things might have changed meanwhile.

@Raziel
Quote:
You are such a someone

@Raziel
@Capehill
Both of you got a permanent link to the latest ogles2.library 3.4 wip builds.
This link didn't change, so you can always download the very latest wip versions for your tests.

@Raziel
Quote:
I often don't have time to process "please test" mails immediately because of real life (which is also the reason why I rarely publish any ogles2 wip news; and it's also one of the reasons why you got that link to be able to serve yourself).
And sometimes when I get such a mail, I just put it into some Amiga folder for later and then occasionally forget about it.
This is why your preferred option should be to simply report an issue into the aeon mantis, there it won't be forgotten and every other tester can easily check it out too.
Also, if possible use the latest ogles2 wip version and provide a glSnoop log containig ogles2 and Nova calls.

Quote:
Regarding your concrete issue:
I don't see any problem, background is fine, mouse cursor is fine.
Probably / likely (I didn't bother to compare with previous builds) your issue is already handled by one recent fix regarding a falsely optimized-away Nova Submit call.

@Capehill
Quote:
Highly unlikely.

@all
FYI, current ogles2 3.4 wip state looks as follows:

- Added support for texture formats GL_RG and GL_RED. Added GL_EXT_texture_rg to the extensions string.

- Fix: an FBO's scissor-rect was set to 0,0,0,0 right after creation which essentially disabled any drawing, including clearing. This happened because the necessary scissor-reapplication was only invoked when binding the FBO. But by the time of its 1st bind the FBO's width / height is still 0... So if you didn't rebind before drawing then your draw-commands would effectively become noops. Unfortunately (in this case only) a common code-path is to pre-create FBOs and then use them later (by using a explicit bind), which explains why this bug remained unnoticed for so long. Thanks to Capehill for reporting.

- Fix: while I was at it I found and fixed another one in that area: if you changed the dimensions of a texture which was used as a render-target then this change didn't immediately invoke a scissor / viewport adjustment.

- speed up for glReadPixels from an FBO with texture-attachment by integrating the GL-required vertical image flip into the render-to-bitmap pass.

- the strategy of handling GL state changes has been modified. In a nutshell the actual application of those changes is now deferred until just before the next draw-command. The new state handler is able to detect and ignore all redundant changes. Before it was only able to detect simple stuff like glDisable(GL_BLEND) followed by another glDisable(GL_BLEND). Now it can also detect and ignore stuff like glEnable(GL_BLEND) ... Draw() ... glDisable(GL_BLEND) ... glEnable(GL_BLEND) ... Draw() ... glDisable(GL_BLEND). Here the two useless "inner" state changes are ignored. This may dramatically increase performance for some games. Thanks to Steffen for reporting a performance issue with Heretic which was caused by this (not that uncommon) pattern.

- Fix: at least one fragment shader managed to drive the integrated unused-variables-detector into an endless loop. A safety mechanism has been added. Thanks to Capehill for reporting.

- Fix: ogles2.h now respects the AmigaOS namespace for OGLES2Base too. Thanks to Andrea Palmate for reporting.

- On the A1222 the texture wrapping modes were falsely applied. Actually, supposedly pretty much all parameters set via glTexParameteri were affected. In case of the wrapping mode a translated GL_REPEAT magically became a W3DN_CLAMP_TO_EDGE (which happens to be the value 0) instead of W3DN_REPEAT. The reason for this weird issue was a LTE issue (therefore blacklisting ogles2.library was a valid workaround). ogles2's code used a C union at the critical area to "merge" a uint and a float. This was merely done to underline mutual exclusivity for those two variables. While that code was absolutely valid, it obviously "irritated" AmigaOS4's LTE on the A1222. Consequently removing the union did the trick. Thanks to Eldee for reporting and testing.

- Fix: it is crucial for good framerates to reduce Nova submissions to a minimum. However, certain operations require a submission. ogles2.lib's internals try to get a good balance here. However, the last time I optimized things here I introduced a bug where I made such a necessary submission due to certain state changes but falsely marked the used-objects list as empty - which in turn caused another required follow-up submission not to be executed. The results could be anything from textures at wrong places or whatever because e.g. Nova would then use a newly bound texture for a PREVIOUSLY issued draw-call. Yes, be glad that you don't have to use Nova directly...

Unofficial:

I also added a feature that's private to me for now and which isn't available in the current wip builds for testers yet:

- Introduced ogles2_patch.json. Such a file can either reside in LIBS:ogles2/ or in the respective client app's main folder (the latter's content has higher priority). This mechanism allows for global and / or per-app tweaks of ogles2 and will be filled with concrete functionality in the future.

- Added shader-extraction feature to ogles2_patch.json. If the new "extract-shaders" flag is set to true then all the shaders are extracted to RAM: for now.

- Added shader-replacement feature to ogles2_patch.json. This allows you to replace an app's shaders. Use the shader-names from a previous extraction-run for replacement.

Cheers,
Daniel

@Daytona675x

Quote:
This sounds like a driver bug. It certainly should NOT be using a newly bound texture for a previously issued draw call regardless of whether you called Submit().

Please submit a bug report to A-EON's bug tracker with a way to reproduce this, and I'll look into it.

Hans

@Daytona675x

Apologies.
I sincerly didn't think the link you sent was permament, I didn't check afterwards either as I was under the impression the link has already timed out and/or the linked file will not be updated any further.

Thank you very much for the heads up.

@Daytona675x

Many (if not all) glitches i encountered fixed by 3.4

Thank you

@Raziel

Great news.

@Daytona675x

Regarding A1222 and C union, I wonder if this affects also C++17 std::variant ( https://en.cppreference.com/w/cpp/utility/variant )?

@Daytona675x
Quote:
Uuuuuh...neat...so...hypothetically... ...could i tell you a bunch of shaders that doesn't work (within ScummVM) and you extract and test them (and fix any found bugs in ogles2)?

@Raziel
I am a bit late on the party, but as you remember a year ago we with one of ScummVM devs test and fix/report where necessary all the shaders to make them works on our ogles2/warp3dnova and with at least v3.3 of ogles2 and latest warp3dnova all the shaders coming with scummvm were working (that include shaders for Myst3, GRIM+Monkey, and Wintermute3D games).

Are there new shaders for other games included now except those tested which not works, or, by some reasons, those previously working ones before stop working ?

And is it with direct ogles2 build, or GL2 one through gl4es ?

@Daytona675x

There are some issues about GCC and A1222, some workaround are needed to let code run fine.
..Any news about it? I remember an article by Hans about some tips to "taborizing" apps and drivers.

Just found the url: https://keasigmadelta.com/blog/taboriz ... imizing-for-the-e500-spe/

@kas1e

The added shaders are not game specific, rather they are used to change the look of a whole game, just like retroarch does, or dosbox (e.g. some smooth out the pixel graphics, some add filter methods etc.).

If you start ScummVM, go to Global Options and Graphics, there is a "shader" option where you can choose from a magnitude of different shaders.
Cross-checking with a windows build i found four shaders that are seemingly broken by design (which i already reported to the ScummVM bug tracker), but the other 99% either work fine or show some signs of unsupported features (f.e. a green screen instead of a green opaque hue OVER the actual game screen and so forth).

I made a list of those shaders that crash during compilation and a list of shaders that work, but are glitched.

If you need them lists, let me know...