@Capehill
I probabaly need to create few test cases (one for opengl, and another for opengles) where just blit something in the window and trying to resize it, to see if there will be bug arise.

Probabaly it not related to the fact how window created, its maybe more about context creation. Maybe it only happens with ogles2 (i use OGLES2_CCT_RESIZE_VIEWPORT,TRUE when create ogles2 context when use gl4es, can be related).

@all

How can i force my SDL(1/2) app to pick up a given iconification icon?

@Raziel
Do you mean to choice when show "busy" icon and when show "non-busy" one, something like that ? At moment everything is hardcoded as i can see, you can only use icon coming with the binary. Capehill can clarify more about of course.

@Capehill
Reading your bugreport on warp3dnova, as well as issue in sdl2 tickets about ogles2, did it all mean that you have now hardware with working gfx card which support ogles2/warp3dnova/etc ? If so that will be cool !

@kas1e

I think Raziel is experiencing the same bug that you reported: fullscreen toggle "breaks" the gadget.

Yes I have an X5000 now. It is hopefully easier to sort out those remaining SDL2/ogles2 issues now :)

@Capehill
Quote:

If so then he just need to build latest version (you fix it all if i remember right)

Quote:

Yeah ! That will help surely !

ps. i write some more info in the bugreport you create on mantis about warp3dnova.

@kas1e

Nevermind...

It already chooses the apps icons as iconificated icon.
Problem was that i was testing the app from shell. Doing that resulted in the iconifated icon being the shell icon instead of the apps one.

@kas1e

Quote:
I'll wait for the next RC release to test any further...don't want to add new bugs by a faulty build on my own

@Capehill

Bad news, that patch for minigl about replacing "&&" to "||" in the glTexImage() broken things : Cube and Lugaru (both on os4depot) have problems with textures: Lugaru in menu have white textures, and Cube in game itself have some mess with textures.

I tried firstly my own builds of latest source code, but then tried your one, from the ticket 34, that one: http://capehill.kapsi.fi/minigl/minigl_texture_debug.lha

And it have the same issues as my build.

Once i removed back "||" to "&&" those games start to renders correctly.

Probably its not enough to fix original issue like this, something should be changed somewhere else as well.

@kas1e

White textures might happen if game uses non-power of two texture sizes because Warp3D doesn't support those. Well, have to investigate.

@Raziel

2.0.9 RC2 is published: https://github.com/AmigaPorts/SDL/releases/tag/v2.0.9-rc2-amigaos4

@Capehill

Thank you for the heads up.

Installed, rebuilt and tested some bugs (unfortunately still there, the MiniGL update didn't make a differerence either, so those bugs seems to be SDL genuine)


I'd love to test the ogles2 mode to see if that makes an impact in-app regarding speed of drawing operations...

@Raziel

It seems that I forgot to improve those (gadget-related) debug prints I promised for RC2. I'm getting old. Maybe for RC3.

SDL_renderer's OpenGL ES 2 backend is broken at the moment. I'm trying to figure it out. I have requested help from both Daniel and Hans.

Regarding performance: I ported Diamonds and Dust (2D game) to OpenGL ES 2: it is 2x-3x faster than MiniGL on my current setup.

@Capehill

No problem, i'll stand for RC3 (or a debug beta) then.

Ah, ok

So, i guess those games don't use SDL?

I'm intruiged to try out ogles2 for scummvm/residualvm once more (the last test was cut short due to bugs back then), so i'm also standing by for the fix.

Maybe you could give me another heads up when those become available?
That would be grand

Thanks a lot for the new SDL2 version (and the SDL1 debug build)!

@Raziel

Definitely try OGLES2! I just configured ScummVM with:

--opengl-mode=gles2

If you get the shader compilation hickup during the startup, we can work around or report it. At the moment I'm not sure whether it is a ScummVM, OpenGL ES 2 or driver issue.

Quote:

Which games did you refer here?

@capehill

wrt to OGLES2
The configuration and compiling is not a problem, it's the "hiccup" you so nicely put.
But it's not a "hiccup", rather a missing shader(part) implementation in our gfx driver, exactly the boolean uniforms (now that i said it, i think i forgot about it when speaking of trying it out again, there's no point since those shader parts aren't supported [yet?])

I have both a compiled exe of scummvm and residualvm sitting in my development partition, both done with ogles2, just they don't start (say - crash on startup) because of those boolean uniforms not being supported (see also here for reference).
The same (but even worse) is with residualvm, since they rely heavily on shaders (for their 3D engines)

Hans answered on when he would think this boolean uniforms will get supported. (Not very encouraging either)

I'm also not very fond of doing workarounds, i'd rather have it supported by the system and not alter code, or i will surely forget what i had to do to make it work and as soon as a new version of the app comes out i'll be starting from scratch all over again :-/

wrt to the "games"...i meant those you mentioned in one of your last posts and with them the fact that ogles2 for sdl2 is broken atm, so i asked if they aren't sdl(?) (and i just now realized that it's only one game :-/

Quote:

@Raziel

Quote:

But ScummVM doesn't use boolean uniforms as far as I can see:

https://github.com/scummvm/scummvm/blo ... ics/opengl/shader.cpp#L60

I renamed "texture" to "s_texture", and voela, compiled. So I was pondering whether to report this issue or not but I haven't had investigated more yet.

Quote:

No, OGLES2 (context) for SDL2 is not generally broken. It's only the SDL_Renderer's OGLES2 backend (one of four possible backends). SDL_Renderer is used by some 2D games but why worry about OpenGL(ES2) here since you could use the compositing backend.

@Capehill

Quote:
No, but residualvm does

But if it's that easy in scummvm i'll try myself and test.
You could report it since you can describe what is going wrong better than me.
I think we can hijack another thread for that, Hans asked for stuff that should be supported in MiniGL future versions...i'll use that opportunity

Quote:
Because with "compositing" renderer in place fps in some games (where fps display is supported) went up by 0.5-1 fps, which is not worth it.
That may be because those engines/scummvm dosn't make use of certain drawing routines (and as thus nothing is optimized) or the fact that composite is not as fast in comparision as i thought it might be.

@Capehill
Quote:
texture2D is deprecated since GLSL 1.30 and its replacement is the overloaded GLSL function texture() ... Looks like you get a conflict here because of that. Adding an explicit #version tag (probably below 1.30) on top of your GLSL might help.

@Daytona675x

Where would that version tag go?
Inside the app's shader function?
Just to know if i can annoy the devs with that...

@Capehill

I tried, built with the workaround and side by side tested some of the more demanding games...there is, unfortunately, no visible or feelable difference.

Where the intro on one game needs 52 seconds with pure SDL2/OpenGL it needs 50 seconds with ogles2, while both stress out the cpu to max (might have also been a slow finger when pressing the stopwatch).

The same have i witnessed when using compositing.

Seems the engines doesn't really use the shaders...