SDL2

@Raziel

Please verify the .so files, maybe something went wrong with installation.

I cannot test it today, but I checked both .so files and .a files using 'nm' on Linux machine and they all seem to have SDL_OpenURL symbol.

@Capehill

nm?

Will verify, thank you.
Sounds reasonable that the .so's have been corrupted (or not being copied at all)

@Raziel

You can use the 'nm' tool also on OS4, it's part of the GNU binutils.

@Capehill

No, it's alright.
For some reason i had a file instead of a link as libSDL2.so and that file was, of course, outdated.
Created a link again instead and now it compiles just fine, no more errors.

Thank you for the URL addition

@Capehill

Find out some issue (about which we discuss in mails before) about some game where things messed up when we change window-resolutions.

I find out it that this in end about those 2 lines of code:

Quote:

That combo works as expected on Linux/win32, but on our side, things messed up (window sets wrong). And solution there is to add some Delay (even IDOS->Delay(5) is ok) between those calls to make all works as expected.

Imho, that point out to us (i hope), that SDL_SetWindowPosition is too fast and didn't check if SDL_SetWindowSize finished, and the second command executed too fast leading to a mess.

I can fast-fix it in code by adding Delay(5) for example which visually will be unnoticed, or something, but isn't it something we need to add to the SDL_SetWindowSize (like, until it not done, we didn't do anything else). Or to the SDL_SetWindowPosition to see if all other SDL operation about window is done firstly and only then do call.

Taking into account that this code works as expected on other platforms, maybe indeed worth checking in SDL itself?

@kas1e

Reproduced. It seems almost as if Intuition doesn't always want to resize the window as requested (as the IDCMP_NEWSIZE event reports old window size). Both operations are using SetWindowAttrs() function.

It works occasionally, like 1/20, without delay.

@Capehill
Do you think it needs to be fixed in SDL?

@kas1e

I am planning to add window size polling in SDL_SetWindowSize implementation. Maybe that helps in case consequtive SetWindowAttrs calls cause random issues.

@Capehill
Checked your latest commit, yeah, the issue fixed! I through build SDL2 via GCC 10.0.2, and I had to add to SDL_os4library.c __attribute__((weak)) to IExec and to INewlib to make the final libSDL2.a links without errors about those symbols, but then, on exit from programs linked with built libsdl2.a this way, I have crashes in __NewlibCall after I call alcDestroyConectext from alut or something.

So probably for time being, I switch back to GCC 8.4.0 build of SDL2.

@kas1e

Please try modifying SDL2 makefile, add:

-fcommon

to CFLAGs. GCC10 changed the default behaviour from -fcommon to -fno-common.

@Capehill
Yeah, that works, thanks!

@Capehill
I build some games with older sdl2 (1-year-old) and the latest one. And can see, that with a new one, fps seems lower. At least visually, I can see that with the old one in some part of the game everything at 60fps (visually), while with the latest SDL2, it seems slower and visually can be noticed some little "stops" on milliseconds.

Can it be the SDL2 changes of last year causing this? Can't say exact fps right now, but I can try to add fps counter to the game

@kas1e

If this game is using the SDL_Renderer subsystem then it has seen some changes. In that case the next question would be which backend we are talking about? Batching mode might have some impact.

@Capehill
Quote:
Checked on SDL_Renderer call in whole .cpp/.h files and didn't see any reference to it.

It's that eldritch game we talk about which we talk in emails before. It uses SDL2 + Ogles2 directly. And I can see that in fullscreen it starts to be slower (can't say if it slower in window mode or not).

I just compile objects and tried to link with both old and new sdl2, and can see a difference. On serial, there is also nothing, so that not debug outputs.

If you want I can send you for the test just a ready to run stuff, with 2 binaries (via old sdl2 and new sdl2) and point out the place where things visibly.

It's like something with VSYNC happens or so in the newer version.

@Capehill
I run both versions in fullscreen mode, to see via Ranger what kind of screen modes created with old and new sdl2. And now there are differences between new sdl2 and 1-year-old sdl2: width, height, and depth all the same. But Flags, compositing, and drop-shadows are different! That surely the thing which causes differences.

That what I have for the old SDL2 (fast) version:

Flags: Quiet HiRes
Compositing: Disabled
Drop Shadows: Disabled

And that what I have for the new SDL2 (slow) version:

Flags: Quiet HiRes AutoScroll SharePens OffScrDrag LikeWB
Compositing: Enabled
Drop Shadows: Enabled

So somewhere in the process, we change how fullscreen mode creates. Maybe that was because of that "bad look of asl in milky tracker"?

One of the new Flags, or maybe Drop Shadow cause this IMHO.

@kas1e

Interesting, so maybe it could be SA_LikeWorkbench flag (and some setting it brings on)? Can you test it?

PS. Ranger is a great tool.

@Capehll
Yeah well try to remove that flag and see how it changes


EDIT: Yeah, that it. SA_LikeWorkbench gives us all those new flags and stuff and causes slower speed because of that. Uhm, seems there is no easy workaround, but just to disable it for my own builds?

@kas1e

If it's the compositing, then do some settings in the GUI prefs make a difference?

And if it's the compositing, then maybe you can try to open the SDL screen with "SA_Compositing, FALSE" tag.

@Capehill
Yeah, you are right, it is compositing. I firstly checked via disabling it from GUI, so it creates with SA_LikeWorkbench screen with all the flags, but with compositing and drop-shadow disabled.

Then i just enable in SDL2 SA_LikeWorkbench back, but disable SA_Compositing, and it also works as expected now. Through is it unclear if it exactly compositing, or DropShadows (they seem disabled and enables both by SA_Compositing or from GUI effects).

And should we add it to SDL2 at all or not it also unclear, because it means no compositing for full-screen if we will disable it? (But then it was disabled all the time even before, so wasn't noticed). Or Compositing when creating a video mode has no reflection with the usage of compositing in renderers at all ?

@kas1e

We can probably disable SA_Compositing tag, as far as I know it impacts only compositing effects (eye candy) but not Composite() call, for example. SA_Compositing would be needed for transparent windows but they don't make sense in fullscreen mode.