-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Having attempted this myself, the answer is "a lot of work." Even with the classes and bindings separated, there is still a lot of C++ code used in the binding layer, and some of the C++ code is tied specifically to Lua data structures. If a transition to a C API were to be made, that C++ code has to be put behind a corresponding C wrapper, so basically opaque pointer types to all those classes and functions/methods have to be wrapped to fully support using LOVE as a standalone library.
I still think that a C API would be a better option than trying to fork the project to replace Lua with Squirrel or some other language, so that at least others can have a chance to writing language bindings for their favorite languages without having to do all the porting work again.
Here is the tracking issue: https://github.com/love2d/love/issues/1640
Lua is a language that I started programming with, and has a special place in my heart even if has some crappy parts.
The main issue I have with the language is with table accesses and 'nil'. Tables in Lua are the most fundamental type of objects in the language, it can be either an array (1-based index) or a hashtable. In this language objects are basically just tables with fields in them, and with metatables you can basically emulate all the features in a typical OOP language (classes, inheritance, traits, operator overloading, etc.) Field access in objects are just table accesses (like what you can imagine with Javascript).
However, when you try to access a field in a table that doesn't exist (such as 'print(table.key_that_doesnt_exist)'): no errors or exceptions are explicitly raised, it just silently returns nil. This is such a dealbreaker that makes the language much harder to debug than other languages (at least Javascript returns undefined, which is different from null! Oh well, that actually has problems of its own though....) Some more horror: global variables are also implemented as tables (imagine that there's a table _G at the top of the scope). This means that any spelling mistakes with variables will also just silently return nil, since if it doesn't find any variable names at the local scope, it tries to find at the global scope.
The global variable thing was actually such a big problem that people came up with some voodoo metatable trickery script that prevents this from happening (a showcase of the language's power, but probably not its proudest). I'm sure you could also do this with table creation (make a wrapper function tbl() that automatically adds metatables to prevent invalid field access, so every time you need to do things like 'pos = tbl({x = 1, y = 2})') But still, there isn't a solution baked into the language, and it's cumbersome to do this.
Right now I'm trying to integrate Squirrel (http://www.squirrel-lang.org/) instead of Lua as a scripting language into my game. Squirrel is an embedded scripting language that's hugely inspired from Lua, but also fixes this shortcoming of the language by making invalid table accesses runtime errors. And when you want to add new fields to a table you need to explicitly do so via the <- operator:
table = {}
So there's actually two things:
1. Love can actually be used directly as a C++ library. It's a bit of work to get the build system going but that's what we do on https://github.com/castle-xyz/castle-client/tree/master/core -- example of use of the Love API: https://github.com/castle-xyz/castle-client/blob/7bfffa10e84... -- we used to use the Lua Love and have since worked on porting our engine to C++. It even runs in the web with the same code through Wasm.
2. For a 'simple C library for 2d (and actually 3d) game development' -- I would highly recommend https://www.raylib.com/. I really, really dig the API design there. One of the main 'downsides' I guess is it doesn't out of the box build natively for iOS -- but the Wasm support makes it run there pretty fine out of the box and raylib-fork can be used to get a native iOS build going with some work. It's got a lot of stuff out of the box including a GLTF loader and skeletal animation.
So there's actually two things:
1. Love can actually be used directly as a C++ library. It's a bit of work to get the build system going but that's what we do on https://github.com/castle-xyz/castle-client/tree/master/core -- example of use of the Love API: https://github.com/castle-xyz/castle-client/blob/7bfffa10e84... -- we used to use the Lua Love and have since worked on porting our engine to C++. It even runs in the web with the same code through Wasm.
2. For a 'simple C library for 2d (and actually 3d) game development' -- I would highly recommend https://www.raylib.com/. I really, really dig the API design there. One of the main 'downsides' I guess is it doesn't out of the box build natively for iOS -- but the Wasm support makes it run there pretty fine out of the box and raylib-fork can be used to get a native iOS build going with some work. It's got a lot of stuff out of the box including a GLTF loader and skeletal animation.
Here's a tiny 3D engine: https://github.com/groverburger/g3d. Should show you everything you need to do 3D.