SDL3

@Capehill
Awesome news. Can you please give some extra context about SDL_PROP_IOSTREAM_AMIGAOS4_USE_BUFFERED and if this is something we have to enable in our apps?

@walkero

According to dos.library documentation, "Buffered I/O is more efficient for small reads and writes". If you use SDL_IOStreams, you may need to test both to see.

@Capehill
Quote:Compared to unbuffered dos.library (IDOS->Open(), IDOS->Read(), IDOS->Write(), IDOS->Close(), etc.) and unbuffered POSIX low level I/O (open64(), read(), write(), close(), etc.): Yes.
Compared to C library buffered I/O (fopen64(), fread(), fwrite(), fclose(), etc.): No, using buffered C library I/O is often faster than using buffered dos.library I/O (IDOS->FOpen(), IDOS->FRead(), IDOS->FWrite(), IDOS->FClose(), etc.). At least in case of newlib and ixemul, no idea about libnix, clib2, clib4 and vclib.

Maybe a little off topic, I was asking myself to which SDL versions should the links point to in the SOBJs: folder after having freshly installed AmigaOS 4.1.9.1 (or whatever confusing name the latest available public version has).

e.g. should libSDL.so point to libSDL-1.2 or libSDL2-2.3.so or the even newer libSDL3-3.xx.so?

Same question about the other links ins SOBJs:

thanks.

@joerg

Thanks for information. SDL3 uses dos.library's (F)Read/(F)Write functions and this can be now selected by the developer.

@Tuvok

SDL1, 2 and 3 are different and incompatible libraries.

So,

libSDL.so should point to libSDL-1.2.so.
libSDL2.so should point to libSDL2-2.x.y.so.
libSDL3.so should point to libSDL3-3.x.y.so.

If you have the AmigaOS 4 SDK installed, you can check which shared objects some binary is using by:

readelf -d binary_name

@Capehill

Thank you very much!!

@Capehill
Thank you very much for your work on SDL* for AOS4.
I checked out your latest version of SDL3, the ioq3 fork with the SDL3 patch, and SDL2.
It works very well and plays great.
Thanks!!!

@smarkusg

Cool. I noticed that GL2 renderer can be now started with minor modifications, but unfortunately, there seem to be some texture coordinate issues and crashes later.

3.2.24 is available: https://github.com/AmigaPorts/SDL/releases/tag/v3.2.24-amigaos4

AmigaOS 4 changes:

Quote:

Direct link: https://github.com/AmigaPorts/SDL/rele ... v3.2.24-amigaos4/SDL3.lha

@Capehill
Thank you for the update!

3.2.28 is available: https://github.com/AmigaPorts/SDL/releases/tag/v3.2.28-amigaos4

Direct link: https://github.com/AmigaPorts/SDL/rele ... v3.2.28-amigaos4/SDL3.lha

It contains mostly upstream bug fixes since 3.2.24.

Thank you for the new version.

Not sure if this is my system or a new problem with SDL3. But the testsprite program does no longer run on my X5000:



The Minigl test programs in SDK:Examples/MiniGL do work, so I think there is no problem with my system.

@FlynnTheAvatar

Do you have "opengl" as render driver? If so, please use compositing (default), opengles2 or software.

MiniGL support was removed from renderer subsystem. Main problem is that it doesn't support frame buffer objects.

@Capehill:

Not that I am aware of. I tried to set a different driver with SDL3 prefs, but the test program failed with the same error regardless of the selected driver (compositing, opengles2, software).

@FlynnTheAvatar @Capehill
Quick test on my machine (QEMU PEG2 RADEON HD)
Works correctly

quick video - > https://youtu.be/z8i978QlwQg

EDIT 9.12.2025:
A small correction. I made a mistake because the video shows the sdl2 version from os4depot (3.2.24).
I have now checked with version 3.2.28 on GitHub (link 4 posts above).

It works fine for me. Versions 3.2.24 and 3.2.28. The test was done in the same way.

@smarkusg @Capehill

It works when I set the renderer with the option "--renderer".

Not sure why the renderer defaults to opengl on my system. Any idea how SDL3 gets the renderer from? It clearly ignores SDL_RENDER_DRIVER.

@FlynnTheAvatar

I was expecting to see GetVar on Snoopy log but there wasn't one. When renderer is created, it should check the given hints.

In any case, this example seems to work differently for me, it defaults to compositing as expected. And setting different drivers from SDL3 prefs works correctly here. Checked also using testsprite --info render.

@Capehill

Thanks a lot for checking. It is really strange that there are no GetVar calls in SDL3's testsprite.

I checked SDL2's testsprite2, and it works correctly; it defaults to compositing and the renderer can be set by setenv SDL_RENDER_DRIVER.

Strange thing is that I also do not see any GetVar calls in testsprite2, too. But it seems to work.

Is there another way to get the variable besides GetVar?

BTW, this what testsprite logs regarding the renderer:


I am not sure where the opengl is coming from...

@FlynnTheAvatar

I think ScanVars is used.