News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

SDL 3

Started by Matei, November 01, 2025, 09:49:04 AM

Previous topic - Next topic

Matei

SimcarStunts version using SDL 3 is in the attached file, details in README.txt. Anyone intersted in testing?

Duplode

Nice, I'll try it out soon.

Duplode

Quote from: Duplode on November 04, 2025, 10:51:07 AMNice, I'll try it out soon.

I tried running it, but couldn't make it work while using sdl3 from the Arch Linux repo, and didn't manage investigate further so far. Running the binary from the attachment initially gives the following error:

$ ./simcar
SDL_FRAMEBUFFER_ACCELERATION 0
>> Set BITSPERPIXEL to 24 and recompile.<<

After changing BITSPERPIXEL in graphics/grconfig.h and recompiling, the executable segfaults:

$ ./simcar
SDL_FRAMEBUFFER_ACCELERATION 0
Set 1064x600x24
Segmentation fault         (core dumped) ./simcar

Matei

Quote from: Duplode on November 20, 2025, 02:32:54 PM$ ./simcar
SDL_FRAMEBUFFER_ACCELERATION 0
Set 1064x600x24
Segmentation fault         (core dumped) ./simcar

Of course it says "Segmentation fault", the functions support only 32 and 16 bits. If the game works with SDL 2, then you probably have 16 bits, so try 16 with SDL 3, but take this version:

https://matei.one/idxscr.html#download

QuoteVersion 6.2.0 supports SDL 1.2, 2.0 and 3.0, according to your preference.

If your screen is really set to 24 bits then you can only use SDL 1, but I never saw a screen working with this setting on any computer ever since I use GNU/Linux, from 2003.

Matei

"1064x600x24" actually looks like the screen is set to 32 bits (1064*24/32=798), so it shouldn't "Segmentation fault", unless there's a problem with "sdl3 from the Arch Linux repo". Maybe you have an older version, so you can try installing a newer SDL 3 from source code, see "SDL.txt". More details in file graphics/forsdl3/graph2d.c, lines 147...153.

Matei

I think I found the problem. When you started the program, it said "1064x600x24", but 1064 means a width of 798 pixels, although it was set to 800. On my computer it says "1066x600x24". The SDL function to create the window is called in file graphics/forsdl3/graph2d.c at line 139:

SDL_CreateWindow(title,width,height,0);
The graphical functions then use variables RGLOB_width and RGLOB_height set equal to width and height, but the created window is smaller, so memory for those pixels isn't available, so "Segmentation fault". I don't know how to find the parameters of the window:

https://wiki.libsdl.org/SDL3/SDL_GetWindowSurface

Doesn't say. I can set RGLOB_width and RGLOB_height to smaller values than width and height after creating the window, but this is not reliable. Does the problem occur in the same conditions if the image is set to full screen ("fullscr=1" in file "config") or with SDL 2?

Duplode

Good catch; I wonder if my environment is somehow interfering with the window size (will try to find out later). Trying with the 6.2.0 from your site, both the SDL3 build and full screen always segfaults. The provided binary (which is the SDL2 one, I believe) segfaults some of the time (if I retry enough times it works somehow), and the size reported on the console for it is 798x600x32.

Matei

You can also try with various resolutions (file "config") and see what happens. Is the resolution set in "config" ever reported properly?

Duplode

Quote from: Duplode on November 20, 2025, 11:04:39 PMGood catch; I wonder if my environment is somehow interfering with the window size (will try to find out later).

Yes, it is my environment. I normally use XMonad (a tiling window manager) on this computer; switching to a Xfce session I get no segfaults, and the expected 800x600 size is reported. Maybe the two pixels taken by the window borders are somehow being deduced from the available window size (but if so, why just from the width and not the height?). It's mostly academical now, but if I find a workaround for XMonad (and I guess there must be one) I'll post it here.

Matei

Quote from: Duplode on November 20, 2025, 11:35:14 PMbut if so, why just from the width and not the height?

This is why:

Quoteprintf("Set %dx%dx%d\n",8*RGLOB_screen->pitch/BITSPERPIXEL,height,BITSPERPIXEL);

File graphics/forsdl3/graph2d.c, line 153. The height reported is just the value sent to the function, not the resulting height of the window, which was obviously also reduced, but as mentioned above, I don't know how to find it.

Matei

Possible workaround for "XMonad". Add 2 pixels to the width and height of the created window, file graphics/forsdl3/graph2d.c, line 139:

RGLOB_window = SDL_CreateWindow(title,width+2,height+2,0);
If it doesn't work with 2 (it should), try more. I will make an update, but I have to think how. Fortunately, this problem doesn't occur very often; I never saw it and I tested:

https://matei.one/#performance

with SDL 2, but the problem also appears with SDL 2. I will have to update all my programs though and this could be a problem...

https://sourceforge.net/u/matei_v/profile/

Matei

https://wiki.libsdl.org/SDL3/SDL_CreateWindow

There might also be some flags here that could ~fix the problem, but I can't test them. Ex.:

SDL_WINDOW_BORDERLESS

This is to be added to the line mentioned above, instead of "0" and without adding 2 to "width" and "height". As I saw, the windows in "Xm0NaD" are without borders anyway, so maybe they have to be set like that from SDL.

https://en.wikipedia.org/wiki/Xmonad

Matei

#12
Ok I just installed xM0n@d version 0.18.0 on Fedora 41. Worst dependencies I've ever seen, I had to download 110 files besides the updates. I had no problems with SDL 3 or SDL 1, with which the game worked perfectly with fullscr=0 and fullscr=1, but with SDL 2:

fullscr=0 - the controls didn't work, when I pressed any key the caracter just showed in the terminal, SDL_WINDOW_MOUSE_FOCUS|SDL_WINDOW_INPUT_FOCUS|SDL_WINDOW_MOUSE_GRABBED also didn't work, so Ctrl+Alt+F2 and "killall simcar".

fullscr=1 - "Set 623x600x32" instead of "Set 800x600x32", so a little more than 2 pixels missing and "Segmentation fault". DOSBox for SDL 2 also didn't work in full screen (just black rectangle), and ffplay from ffmpeg version 7.1 only shows the image on half of the screen, can't set it to full screen. MPlayer works well, but it doesn't use SDL 2.

There is a good solution for the problems with xMoNaD: don't use it, it's broken (I'll have to put that in the documentation).

[edit]
I forgot: on Fedora 41 I have sdl12-compat instead of SDL1, so with the option for SDL1 the game actually displays the image with SDL2, which worked, but with SDL2 (and MATE) the framerate is ~twice as high as with sdl12-compat. With SDL1, SDL2 and SDL3 used directly the framerates are comparable, of course.
[/edit]

[edit2]
DOSBox for SDL 2 didn't work in full screen with MATE either, but here the whole screen was black instead of the rectangle in center. I typed "exit" and it worked though.
[/edit2]

Duplode

#13
Thanks for trying it with XMonad, and sorry for the truckload of dependencies 😅 Installing XMonad pulls the Haskell toolchain because it is configured through Haskell code (much like, say, dwm is configured through C code), so it is mostly used by people who already have the Haskell toolchain on their system for independent reasons.

Quote from: Matei on Yesterday at 11:03:44 PMI had no problems with SDL 3 or SDL 1, with which the game worked perfectly with fullscr=0 and fullscr=1

Interesting that it worked for you on SDL 3 plus (I presume) the default configuration of XMonad (as opposed to the customised one I have here). Another reason for me to examine my setup, I guess.

Quote from: Matei on Yesterday at 07:55:39 AMPossible workaround for "XMonad". Add 2 pixels to the width and height of the created window, file graphics/forsdl3/graph2d.c, line 139:

RGLOB_window = SDL_CreateWindow(title,width+2,height+2,0);

This workaround did work here on my current XMonad setup: no segfaults and 800x600 reported size on both the SDL2 and SDL3 builds. I don't think you'd want to make that change in your code, though, as it has side effects on other environments where everything has been working normally -- see e.g. the black lines at the right and bottom of the window in this screenshot taken in Xfce, where the window size becomes 802x602:

You cannot view this attachment.

The share of Simcar users that have XMonad as their window manager is vanishingly small (i.e. probably just me), so it wouldn't be reasonable to expect Simcar to incorporate messy workarounds just to cater for that. Besides, I'm reasonably confident about finding a way to deal with this through XMonad configuration, by adding some kind of special rule for the handling of window borders. (And worst case, if nothing else works, I can just start a Xfce session when I want to play Simcar.)

Matei

Quote from: Duplode on Today at 01:10:04 AMI don't think you'd want to make that change in your code, though, as it has side effects on other environments where everything has been working normally

That's not what I meant. As I wrote above:

Quote from: MateiI will make an update, but I have to think how.

I would have added some instructions in the documentation to edit graph2d.c and add those 2 pixels if necessary, or put some parameters in file "config", but if you read my previous message, that doesn't help:

Quotefullscr=1 - "Set 623x600x32" instead of "Set 800x600x32", so a little more than 2 pixels missing and "Segmentation fault".

Quote from: Duplode-- see e.g. the black lines at the right and bottom of the window

You can imagine that I already tested and saw those, which is how I came to the conclusion that the "workaround" should work for you.

The share of Simcar users is vanishingly small without having to specify other details. People don't like good games, I can't do anything about that.