Linux Game Engine Dependencies

[greenm01]

Hello,

What dependencies are required on Linux for the game engine, e.g. SDL2, glfw, audio libs, etc?

I've successfully compiled Lobster on Nixos in a development shell, although I'm not sure if I have all the required game engine runtime dependencies..... whenever I try to compile any of the samples with my Lobster binary I get the following error:

Unable to create window: Invalid window fatal error: Unable to create window: Invalid window

Looking forward to giving Lobster a go. I appreciate the language design ethos. Both Nim and Lobster are on my radar for a small project I have in mind.

[aardappel]

SDL2, SDLMixer, FreeType, and a few other dependencies are included in the repo (statically linked), and as such are not platform dependencies.

The only platform requirements should be OpenGL and.. libc?

Are you able to compile and run other OpenGL apps?

[greenm01]

All of the samples give me that same error when I try to run them.

When I compile with something like:

../bin/lobster --cpp pythtree.lobster or ../bin/lobster --pak pythtree.lobster

the compiler does not produce any output at all. It just drops me straight back to the command line with no message.

[greenm01]

I have gcc 12.2.0 installed on my system if it matters.

[aardappel]

Those two options just compile but don't run, so they just succeed with no output. You need to run without those options.

gcc 12 is pretty old but if it compiles that is unlikely the problem.

As I asked, are you able to compile and run other hardware accelerated OpenGL programs on your system?

[greenm01]

Yes, I can. e.g. I can build and run similar opengl demos with Nim.

I've successfully run the Lobster demos on Windows and I'm very impressed. Struggling to get them to work on my Nixos box unfortunately.

As mentioned, I keep getting this error:

Unable to create window: Invalid window fatal error: Unable to create window: Invalid window

[aardappel]

Well, it is this call failing: https://github.com/aardappel/lobster/blob/0abbc005be1398fa1c606555268a7a16a39219a2/dev/src/sdlsystem.cpp#L394-L402

I am not enough of a Linux expert to know what could cause SDL to fail to open a window..

[greenm01]

I did some searching, and I found this open issue at SDL2's github repo: https://github.com/libsdl-org/SDL/issues/8291

Have you considered using an alternative library like raylib or glfw rather than bundling SDL2 in Lobster core?

Maybe decouple the game engine from Lobster core entirely and provide separate C/C++ library bindings to a game engine like raylib?

https://www.raylib.com/

[aardappel]

No, that be a ton of work. Our integration with SDL goes a lot deeper than just bindings that are easily interchangeable.

SDL is also a very stable robust library that has existed forever, if it can't open a window on your system, I would not assume that is necessarily a bug in SDL.

[greenm01]

From a systems perspective, I would say integrating an external game library like SDL2 into Lobster core is not a viable strategy for long term success. I'll have to take a hard pass at the moment. I wish your project the best; you have something really cool going here.

[aardappel]

Lobster can be built without the built-in engine (in console mode), and you can use the "language" project with your own engine in whatever way, but of course doing your own engine bindings is a lot of work. https://aardappel.github.io/lobster/implementation.html

[greenm01]

That's interesting. In her current state (please correct me if I'm wrong), Lobster does not yet have a FFI baked in that allows one to call C/C++ directly from Lobster code (similar to Nim's importc pragma). Instead, we have to add bindings/wrappers to external C/C++ libs within the Lobster compiler itself, which then exposes our C/C++ API to Lobster code via your "nfr" NativeRegistry methodology..... Just like you did with the Audio and Box2D extensions, etc... Correct?

In this context, it does make sense why you would include some batteries in Lobster core (i.e. SDL2) rather than no batteries at all, just to get people going with the fundamental tools to craft a game.

The ultimate prize would be for all these external libraries to be written in Lobster, or at least existing C/C++ libs called directly from Lobster code. First class interoperability with C/C++ would make Lobster a real contender vs Rust, Zig, Nim, etc for game development.

Reading through your TODO, I don't see plans for FFI. Is this on your radar?

Over the ten years you've been working on this project, you've already accomplished quite a bit all by yourself. That's serious commitment. Cheers to you!

[aardappel]

Yup, currently writing bindings is labor intensive.

I don't think I necessarily want to add automatic C bindings though, since some of the value of those manual bindings is being able to lift the level of abstraction and convenience a ton, often combining several C functions into a single Lobster function.

What I do want to do is declare all the interface for this in Lobster, and codegen the binding function such that you only need to concern yourself with implementation.

Lobster does not compete with those languages, because currently it is both way more high level and also slower. That last part I can solve given enough effort. Once it can compete with Rust for speed then maybe direct C bindings would also make more sense.