SimcarStunts version using SDL 3 is in the attached file, details in README.txt. Anyone intersted in testing?
Nice, I'll try it out soon.
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
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.
"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.
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?
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.
You can also try with various resolutions (file "config") and see what happens. Is the resolution set in "config" ever reported properly?
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.
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.
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/
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
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]
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 November 21, 2025, 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 November 21, 2025, 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:
Screenshot_2025-11-21_09-23-15.png
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.)
Quote from: Duplode on November 22, 2025, 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.
Quote from: Matei on November 21, 2025, 11:03:44 PMfullscr=0 - the controls didn't work,
Actually they did but the image doesn't update. Edited file graphics/graph2d.c, lines 276...:
#elif SDLVER==2
if(RGLOB_initgr==0){printf("display(): Screen not initialized\r\n"); exit(1);}
if(SDL_UpdateWindowSurface(RGLOB_window)<0){
printf("%s",SDL_GetError());
exit(1);
}
#elseError:
QuoteWindow surface is invalid, please call SDL_GetWindowSurface() to get a new surface
Which version of xMOn@D do you have? I have 0.18.0.
https://disenchant.net/tyrquake/
Tyrquake works, but it uses "SDL_CreateRenderer()" instead of "SDL_GetWindowSurface()".
https://wiki.libsdl.org/SDL2/SDL_CreateRenderer
https://gamedev.stackexchange.com/questions/180077/in-sdl-what-is-the-difference-between-using-a-surfaces-and-a-renderer
However, unlike my game, tyrquake with SDL 2 had a very low framerate on this laptop with Fedora 14, although it worked well with X11:
https://www.miniputer.com/Acer/Aspire_3000.html
https://matei.one/gnxfed14.html
Quote from: Matei on November 23, 2025, 05:03:16 PMWhich version of xMOn@D do you have? I have 0.18.0.
0.18.0 here as well.
Anyway, I found a reasonable workaround for me on the XMonad side: remove the borders of Simcar windows upon window creation (https://github.com/duplode/xmonad-duplode/commit/fbad5679a69b5e909cd7bf5c165e4ddc8462dec2). If I were to insist on having the borders, it would also have been possible to fix it by growing the window to account for the border, along the lines of what's described in this issue tracker comment (https://github.com/xmonad/xmonad/issues/198#issuecomment-528874084).
Those red borders bother me when I try to view a video with MPlayer at full screen, but for the game just leave them:
https://wiki.libsdl.org/SDL3/SDL_GetWindowSizeInPixels
I will post the fixed graphics/forsdl3/graph2d.c file for you to test it (I can't), but I just found out there might be other problems:
https://wiki.libsdl.org/SDL2/SDL_GetWindowSizeInPixels
"This function is available since SDL 2.26.0."
So for SDL 2 I'll have to use this:
https://wiki.libsdl.org/SDL2/SDL_GetWindowSize
So I will also post file graphics/graph2d.c which I also can't test, so you should, because as mentioned above, my problems with SDL 2 in xMoNad are others - the pointer given by SDL_GetWindowSurface() and the size of the window change after the rendering starts (function display()).
Attached file graphics.tar.gz. First set the settings in xmoNAd back to where they were and try version from simcarstunts-6.2.0:
https://matei.one/idxscr.html#download
If the problems still occur, then download file attached here, put files graph2d.c from it in the game source, recompile and see what happens. You can also try with various resolutions in full screen (fullscr=1), with both SDL 3 and SDL 2 (ex.: 960x720).
https://xmonad.org/news/2023/10/06/wayland.html
QuoteWe think we now have enough contributions coming in monthly to pay for someone to work with us on it.
Problem is, we have no idea who can do this.
Updated game, file simcarstunts-6.2.1.tar.gz:
https://matei.one/idxscr.html#download
Xm0NaD aside, you pointed out a problem which could occur with SDL3 even with a graphical window manager that doesn't have bugs:
https://wiki.libsdl.org/SDL3/SDL_GetWindowSize
QuoteThe window pixel size may differ from its window coordinate size if the window is on a high pixel density display. Use SDL_GetWindowSizeInPixels() or SDL_GetRenderOutputSize() to get the real client area size in pixels.
https://wiki.libsdl.org/SDL3/SDL_CreateWindow
QuoteThe window size is a request and may be different than expected based on the desktop layout and window manager policies. Your application should be prepared to handle a window of any size.
Solved that, but int SDL 2 there are a few differences:
https://wiki.libsdl.org/SDL2/SDL_CreateWindow
QuoteIf the window is created with the SDL_WINDOW_ALLOW_HIGHDPI flag, its size in pixels may differ from its size in screen coordinates on platforms with high-DPI support (e.g. iOS and macOS). Use SDL_GetWindowSize() to query the client area's size in screen coordinates,
I didn't create the window with the SDL_WINDOW_ALLOW_HIGHDPI flag, so here I could get the width and height in pixels with SDL_GetWindowSize(). I still have problems with SDL 2 because of some bug(s) in xm0Nad, but I ~solved those too, details in file SDL.txt from the archive mentioned above.