SDL2

@IamSONIC

Thanks, good to hear!

@All

RC4 is available. Please test your apps.

https://github.com/AmigaPorts/SDL-2.0/ ... /tag/v2.0.20-rc4-amigaos4

Quote:

@Capehill
Thank you for the continuous work. I have an issue which existed on 2.0.14 releases and it still happens with 2.0.20.

The editor that I port when I start it, it opens in window mode and I can drag 'n drop files in it and they open just fine.

But if I change it to Fullscreen with the following method
SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP);

and then back again with
SDL_RestoreWindow(window);
then the drag 'n drop is disabled and the X cursor appears when I try to drop a file in the window.

The same code on other systems is working fine. Is there anyone who had the same problem? Could this be a bug in the SDL port?

@walkero

Thanks for the report. Issue seems obvious in code: app window is not created during fullscreen toggle. Hopefully easy to fix.

However I'm confused by the usage of SDL_RestoreWindow here: it should return from maximized / minimized position. Fullscreen mode should be something else?

Quote:
Did I get it right? You mean in SDL code, right?

Quote:

I forgot to mention that before the SDL_RestoreWindow an SDL_SetWindowFullscreen(window, 0);
to return to window mode.

@walkero

Quote:

Yes, I will try to reproduce issue and then fix it. If you want, please create a ticket.

Issue created. Thank you so much.
I did a compile with the latest version and didn't have any issues so far.

Thank you for this awesome port.

@capehill
I had a discussion with Lite XL developers about the situation where a surface dimension is wrong and it is designed skewed at one side when the window is resized. In a previous reply of yours, you mentioned that we should use surface->pitch/4 for our 32bit CPU instead of surface->w, which I did and fixes the problem.

They can't understand though why this is happening and they try to figure it out so as to understand the issue and if they should apply that in their code.

And I have by them the following question:
Quote:

Part of the discussion is at https://github.com/lite-xl/lite-xl/iss ... 3#issuecomment-1030635672
but I am discussing in discord with them, and that's where the above question is coming from.

Do you have any insight to share about that?

@walkero

I could try to check the discussion tomorrow (too tired now) but a small note: by 32-bit I have meant the bitmap depth, not the CPU.

https://wiki.libsdl.org/SDL_Surface

Surface.w is in pixels but surface.pitch is in bytes so when we have 32-bit ARGB (for example), we must divide pitch by 4 to get the correct number. Bitmaps are sometimes wider in memory (than their pixel width) for alignment required by DMA transfer.

EDIT: some updates.

@Capehill

Thank you very much for all the updates.
Will try asap

@Capehill
Thank you so much for your reply. Have a good rest.

@walkero

Adding here some more information. For window framebuffers, we allocate a user-private bitmap and use the pitch (bytes per row) value from that: https://github.com/AmigaPorts/SDL-2.0/ ... SDL_os4framebuffer.c#L110

Found some older discussion where it's confirmed that bytes per row alignment is required due to DMA transfers: https://www.amigans.net/modules/xforum ... t_id=95611#forumpost95611

So even though assumptions that Lite XL makes (or made earlier?) about surfaces may work on some platforms, these assumptions shouldn't be made. It's safest to query things from SDL_Surface and not assume that surface pitch is always window width * 4, or that pixel bit depth is always 4 bytes.

I haven't checked the latest Lite XL code, so maybe things have been changed meanwhile.

@Capehill
Great info. Thank you for sharing.
I talked with the developers after your previous reply and they investigated more and agreed that it is better to use surface->pitch than surface->w, because they didn't get into consideration systems that might have lower than 4 bytes per pixel. So, they provided me with some patches to test, which seem to work quite well.

@Capehill

How slim is the chance of integrating the gl4es changes into your SDL2 release, so to not have two different libSDL2 libraries?

@Raziel

If somebody converts gl4es into gl4es.library, then yes, it should be doable similarly as MiniGL or OGLES2, by setting up certain GL versions.

But I don't want that SDL2 becomes dependent of gl4es in a way that every user is required to link with libgl4es.a, needed or not. If I understand it correctly, this is the current situation.

I have proposed to create a "gl4es" branch in our current SDL2 repo to make it easier to merge SDL2 changes.

By the way, if you are using gl4es for ScummVM build, I'm curious what is the benefit compared to using ogles2.library directly which is supported by ScummVM?

@Capehill, Raziel

Yeah, the problem with gl4es integration, is that SDL you build with it is forced to use gl4es, even, if you didn't have gl4es. Of course, it still will work on machines where are no gl4es (as the check will be done on running), but it still requires an additional linking library (gl4es) on the linking stage, which just can be not needed for some of us.

As for making it a shared library: I do not know how ready gl4es for it, but it already has code to be "shared for amiga", because minigl4gl4es from Daniel use it. But minigl4gl4es has some bugs in terms of "can't run more than one instance at a time", etc, which may be related to the fact that gl4es is not very well designed to be an amiga shared library. But that of course all can be done probably.

Quote:

From my own tests can say that building ScummVM with OpenGL support just over gl4es instead of minigl, cause no issues just everything starts to works 3 times faster. But in the case of direct usage of opengles there were some issues with shaders or something if i remember right. I.e. with pure OpenGL shaders in no use, so when building over gl4es only internal gl4es shaders are used, but when build with ogles2.library directly, scummvm use some internal shaders (a very little, 2-3 of them), which use boolean uniforms, which, of course, very easy to fix, but at least that is not "compile/run" for the port.

There also were some strange bugs in auto-generated shaders too: https://github.com/ptitSeb/gl4es/issues/366

That one I didn't check deeply for now, so can't say wtf.

In other words, with gl4es builds _, for now,_ it's easy to build and all working already. With direct OpenGLES2 and ScummVm's shaders, there needs a bit of polishing work to do.

@Capehill

What Roman said.

I tried a PR implementing choosing between OpenGL and ogles2 on a backend level and it unfortunately displays the same shortcomings as it does with OpenGL.

While I can workaround the boolean uniform issues I still get the same shader errors as with OpenGL which makes me believe our ogles2 is as limited in features as is our OpenGL.

I don't know that, of course, but it looks like it, so I'd rather go the gl4es way, which seems to circumvent those problems and can use all the gfx hardware bells and whistles.

@Raziel

Quote:

What kind of shader errors?

OpenGLES 2.0 is actually much more advanced than MiniGL, I'm still hyped about the fact we can use it :) Shaders, VBOs, FBOs... Even though everything is not implemented yet (like those boolean types), OGLES2+NOVA is pretty amazing if you ask me.

@Capehill

I need to get back to you for details, but once I "fixed" those boolean uniforms I was thrown back to the same shader compilation errors I already got with OpenGL.

If ogles2 is really that advanced and usable I'm all for using it instead of gl4es, but right now it seems there are still forces that prevent me from doing so.

@Capehill
Quote:

Boolean uniforms not supported by Nova is not a big issue (easy to workaround).

An issue which we have now (and exactly with scumm vm), is that for some reason internal gl4es shaders didn't build correctly _even_ with gl4es usage, and i had to "disable shaders" in scummvm's code. See:

https://github.com/ptitSeb/gl4es/issues/366

So i was about to try to debug that issue till death to find out where/what, but then was distracted by gprof/profilers and gdb tests. Hope i will find out the roots of that issue soon, and then gl4es can be used without disabling shaders, and the ogles2 version will work too (with a bit fixed boolean uniforms).

@Capehill, Raziel

And yeah, Nova and Ogles2 in their current form are really mature very well. In the case of scummvm it means only a little bit of polishing, and then all will work. And of course ogles2 is advanced enough, gl4es works over it :)

@Capehill

2.0.20RC4 built a full ScummVM without any errors, nice job as always

Thanks a lot