Need help with an SDL2 game

So I was looking into what it would take to make a Haiku build of my game:

It’s written in C with SDL2 (and GL or Vulkan) as it’s only dependency. (source included in if anyone wants to look)

Looks like the next issue is that Haiku doesn’t support multiple GL contexts maybe?

I used haikuporter to install to install libsdl2_devel, but pkg_config --list-all doesn’t show it. The build log said it installed headers into /packages/libsdl2-2.26.4-4/.self/develop/headers/SDL2/*.h, but there is no SDL2 dir inside of the headers dir. The package also say it provides “cmd:sdl2_config”, but the command isn’t found.

Solved by installing libsdl2-devel via pkgman.

Admittedly I approached this as being a Unix like OS since it provides a posix-ish seeming shell, hoping to just use pkg-config or sdl2-config. I spent some time trying to figure out how libraries are supposed to work, but I feel like I’m hitting a wall. What am I missing? What is the normal way to find headers and link against libraries on Haiku?

1 Like

There isn’t a need to build it with haikuporter, you should be able to install the package with pkgman install libsdl2_devel.

If you already have it built with haikuporter then you can copy the .hpkg file from the haikuports/packages directory to /system/packages to install it.

Oooooh, there wasn’t a “devel” package for SDL in HaikuDepot, and I didn’t realize that pkgman had a larger (different?) set of packages that it could install. Well that cleared things up and I got it compiling with just a couple of source tweaks. Seems to crash shortly after creating a GL context, and kinda takes the whole system down with it. Hrm… I have my foot in the door at least. :slight_smile:

So I take it my mistake is that haikuporter builds packages, and I was assuming it installed them?

I believe there is a menu item that allows you to toggle whether devel and source packages are shown in HaikuDepot.

Yes, haikuporter doesn’t automatically install the package, it just builds it.

Okay, so next issue I’m running into is that creating a shared context fails. SDL at least seems set up for single context only as it directly stores the context in a single variable in the window class. Hrm…

What is the usual way to create shared contexts on Haiku? It looks like that is all wrapped up in BGLView, though I don’t see anything in the docs about creating shared contexts.

On the other hand, does anyone know the status of Vulkan on Haiku? I installed the vulkan and lavapipe packages, but SDL says “Vulkan support is either not configured in SDL or not available in current SDL video driver (haiku) or platform” Would have sidestepped the shared context issue, though I guess I’m not too surprised. Hrm…

Well, I did get it working by disabling the rendering thread, and rescheduling it’s tasks on the main thread. (Kinda surprised it didn’t deadlock…) Performance is fairly bad though at ~50 ms. :frowning: From what I can gather, Haiku uses single threaded llvmpipe? SDL’s mouse capture seems somewhat broken too making it difficult to play. (though maybe that’s because I was running it in a VM) Oh well, it was kind of fun to tinker with it. :slight_smile: Maybe someday I’ll get bored and write my own software renderer for the game…

Ping me if you want to try it out anyway. :smiley:


Not sure how one activates this in SDL, but you can see in that same linked function that there is a check lower down which conditionally specifies BGL_SHARE_CONTEXT, which creates a shared context.

Do you have a backtrace of the crash?

Oh interesting. I skimmed right over that. To create a GL context in SDL, you pass it the window you want to use it with. So I’m not quite sure how it’s supposed to work on Haiku since it only tracks a single context per window. Maybe it was just never tested? I’ll have to look into it a bit more, maybe an SDL patch will come out of it.

Unfortunately no. I suppose it technically hangs, but it ultimately takes the system down with it. SDL_GL_CreateContext() seems to never return (log or even abort statements after it never happen). If I try to ctrl-c the process in the terminal I ran it from it tends to lock up the terminal too, and if I try and ctrl-alt-shift click it in the Tracker(? the Haiku menu?) it locks that up too. A lot of rebooting was required to figure it out. >_>

I guess this could make for a good bug report if I knew what was going on enough to make a proper writeup. It does feel like a fairly serious bug. I can share the patched source if someone wants to look at it.

You can attach Debugger to a running process, or run it beforehand. Once the threads “hang” you can set each of them to the debugged state in debugger, and then use “create report” from the menu.

I think it works with Blender, at least, so it was tested that way.

That won’t be very useful if it’s hung in the kernel.

Ouch! Most of the bugs like this I’ve investigated, though, tend to be pretty easy fixes. Does it also reproduce on the nightlies, or only the beta? Either way, if you have source code for your game available (or a minimal testcase reproducing the problem – or even just binaries of your game somewhere accessible), please open a ticket and I will investigate.

Why not? The report should show in what system call it is stuck?

You can’t interrupt a thread that’s locked inside a syscall, not even with debugger. This is a situation that normally shouldn’t happen, the syscalls are supposed to be interruptible by signals. But if we fail to do that correctly, it just blocks, and tends to block everything that touches it, as described here.
So you have to go to the kernel debugger to figure things out.


I’ll be away for a few days, but can look into it more next week. :slight_smile:

So I was able to look into this a bit more. I installed Haiku on my laptop while I was traveling, and was able to get it to run without issues.

In “About this system” both machines show: R1/beta4 (hrev56578+95). However the broken machine says “Kernel: Feb 2, 2024” and the working one says “Kernel: Feb 11, 2024” I ran pkgman update on the broken machine and despite none of the packages looking like they would have anything to do with kernel or graphics stuff it works now. So I guess whatever it was got fixed? Seems a little weird, but (shrug). I could look through the update log if someone thought it was important I guess.

Here is the source+binary in case anyone wants to poke at it:

It still has some issues before I would want to release it, but it does run ok from the command line via ./veridian-expanse --gl --disable-threads

1 Like

There is a difference with running pkgman full-sync, update will only check for available package updates whilst full-sync will run a full scale update including system packages IIRC.
At least that’s how I use it here. (with the newer kde frameworks I don’t want to update the system if it isn’t strictly needed)

Could you check the hrev mentioned in the about window, guessing it shows as hrev57575 (which is broken), you should be able to run a pkgman full-sync on there.