upvote
SDL3 should get more love in general.

The SDL3 GPU API[1] provided a cross-platform GPU API even before WebGPU.

In Rust it's a good alternative for winit/wgpu. For that reason I added it to areweguiyet.com[2] last week, where apparently it wasn't even listed before.

I am currently using it to develop a space game[3] inspired by the original BBC Elite. Using emscripten to get on the web and QUIC/Webtransport for networking.

[1]: https://wiki.libsdl.org/SDL3/CategoryGPU

[2]: https://areweguiyet.com/#ecosystem

[3]: https://git.levitati.ng/LevitatingBusinessMan/elite/src/bran...

reply
SDL3 is something I've been keeping an eye on, but at least one thing that held me back from diving into it was SDL_Mixer (audio library) was not updated to a release version for SDL3 until I think a month ago? I need to get back to it but lately I've been messing with SDL2 + wasm stuff using emscripten.
reply
SDL3 doesn't support bindless resources and the plans to do so in the future are very loose[1].

[1] https://github.com/libsdl-org/SDL/issues/11148#issuecomment-...

reply
reply
There is a lot more that goes into Love2D than just SDL. It uses many other libraries for sound, image loading, etc as well as using luajit so that the lua runs very fast and has a super easy C FFI.
reply
But SDL already provides an API for all the things you listed. So I am assuming the libraries in Love2D still call those underlying SDL APIs right?
reply
Love2D uses openAL for audio, FreeType 2 for fonts, DevIL for image loading and Box2D for physics. It can also use image fonts. It uses luasocket for networking and has a compression API built in.

On top of that there are love2d specific libraries people have written to deal with 2D games like GUIs and tile libraries.

Then there is the ease of debugging, where you can use lua to have runtime access to the table of variables and can print them on screen if you need to, not to mention dynamically loading new update and draw and input functions.

This is all to say that just downloading SDL is not going to get anywhere close to what love2d has included.

reply
Cool stuff!
reply
Now why would you hate lua of all things?
reply
For all the reasons, but the 1-based index alone makes me uncomfortable.
reply
1-based indexing is great. It's just _different_ - from C, where the array index is just sugar for pointer arithmetic, and from other languages which borrowed the practice without reasoning.
reply
There are arguments for why 0-based indexing is _better_, unrelated to pointer arithmetic. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

> we had better regard —after all those centuries!— zero as a most natural number

Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.

reply
That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world.

I like the argument that 1-based is better for indexing and 0-based is better for offsets: https://hisham.hm/2021/01/18/again-on-0-based-vs-1-based-ind...

reply
To be honest, I actually agree that Dijkstra's argument seem a bit one sided. It's also interesting to see the argument in your linked article that offset and index doesn't have to be the same.

If I get the root of the argument in the linked article, it is that zero-based indexing is more of a optimization than anything, but I would disagree; there are reasons beyond that (see the examples in my previous comment).

Also, here's an example of an 1-index based system that has caused me some headaches: In music theory, the first note of the scale is called the "first", etc. It also talks about e.g. "stacking thirds", which means take the third of the scale, than take the third from there. However, the offsets are two. (first=offset 0, second=offset 1, third=offset 2). Which is hard to work with in my opinion.

You have an interesting argument about iterating backwards, although I would say; if we need a tie-breaker between the two, iterating forward should have more weight than backwards.

I appreciate your comment, and while trying as best I can to be convinced of the "other side", I still land on 0-indexing. The only argument I buy, is that it matches our natural language starting at 1. Which, of course, is a strong argument.

reply
The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.

It's like right-click-to-select.

reply
In many aspects, Lua is more verbose and awkward than other similar languages. Compare

  local alive_enemies = {}
  for _, enemy in ipairs(enemies) do
    if not enemy.dead then
      table.insert(alive_enemies, enemy)
    end
  end
  enemies = alive_enemies
with

  enemies = enemies.filter(enemy => enemy.alive)
reply
It's more minimalistic, that's true. But there's nothing stopping you writing or downloading an array library so you can do this:

  enemies = array.filter(enemies, function(e) return e.alive end)
Or even setting a metatable so you can do:

  enemies = enemies.filter(function(e) return e.alive end)
reply
Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries. And I don’t want to reimplement basic functionality every time I start a new project.
reply
That seems like a contextual problem, not a Lua problem.

If you're in Love and/or control the environment you're free to bring in whatever libraries you want. Or to build your wrapper to support multiple files from the user.

Like you could suffer from a bad embedded scripting setup with any language. Granted if it was embedded Python or Javascript you would get a bit more for builtin if they embed a full implementation. But also embedding Lua with support for user supplied libraries is less effort than embedding a whole Python/JS runtime

reply
> Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries.

Last time I used LÖVE that wasn't the case, nor does it seem to be the case today, you can require libraries or even use LuaRocks if that is what you prefer, and everything just works.

reply
well, it is true that the second one is more concise.

The only difference is that one of the language is embedded and barely takes any place. it's just a few C files :-D It offers just enough functionality while not making it overly complicated to make basic things.

The other one is way way bigger. and even Array.filter didn't exist from the start

reply
Alright, here is Janet, which is designed to be embeddable just like Lua:

  (set enemies (filter |($ :alive) enemies))
Though JavaScript has QuickJS, which is also lightweight.
reply
Janet does look impressive +1
reply
Small stdlib, “implement it yourself” philosophy to even things like classes, diverging language versions and fragmentation (a lot of people don’t like any of the post 5.1 changes), bad tooling and editor support, dynamic duck typed language with no type hints
reply
If it were about making a choice of which web framework to use on the server, obviously you wouldn't want to use Lua.

But if it is about using it as an embedded language. you want just enough language to get you started and be able to tweak controls. so that the embedded language itself doesn't take up unnecessary space, on its own.

It's a design choice to have a language as small as possible while still offering cool tools.

reply
> If it were about making a choice of which web framework to use on the server, obviously you wouldn't want to use Lua.

Wait just a minute, there exist many web frameworks in lua, and programmers who enjoy lua might want to use them.

reply
[dead]
reply
I don't necessarily hate Lua, but I prefer C and Raylib for game dev. Lua is garbage collected, dynamically typed, strays far from standard syntax patterns, and has less existing tooling than C.

I see why people might hate Lua. Especially for game dev!

reply
Luajit is often faster than C. The qualities you described above actually make it great for game dev.
reply
A JIT is a double edged sword, it _can_ make your code faster, i remember in the early days of smartphone gaming, developers often had to manually "warm up" the JIT to prevent stutters during gameplay

It still is an issue nowadays https://discussions.unity.com/t/app-needs-warmup-first-slow-...

Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques

JIT and GC aren't the panacea people make them out to be

reply
True using a JIT without understanding it is not a panacea. Same as a GC. Same as malloc and free (you're often much better off with arena allocators).

Most JITs let you tune when and how they inline. It's also worth knowing how they works and what they can/can't inline.

You linked to monojit. Luajit is a whole other beast. I'd argue it's superior to anything in JS/JAVA/C# land (and I say that as someone with a reasonable understanding of the JVMs C2 JIT).

As an aside with low latency GCs like the JVM's ZGC trading manual memory management for no memory related security vulnerabilities is pretty appealing.

Like everything in programming it's a trade off.

reply
Lua is extremely popular for game dev though?
reply
SDL3
reply
Definitely SDL2.

Author is currently building version 12 which will be using SDL3. But it's been in development for quite some time with no clear end date afaik.

reply
Who is "the author" these days? Is it Slime? I wonder what Rude and Bartbes and vrld are up to these days. Are releases still done on holidays? Are all libraries still named after sex themes? I was active for versions 0.4 - 0.6.
reply
It is easy to get Lua (with LuaJIT) working with SDL3, though.

That obviously isn't a replacement for the framework but it is perfectly doable if someone just wants to write a game in Lua with minimal overhead.

Edit: I mention LuaJIT specifically because it lets you create metaclasses around C objects, which is much easier than messing with the Lua stack from C, and it's easy to make a 2d vector class from an SDL Point or a spritesheet or what have you. There are a few rough edges like dealing with pointers and gc but to me it's the best of both worlds (the speed of C, and some implicit type checking, and the flexibility of Lua.)

Obviously you could do it the hard way and the other way around with normal modern Lua but it's such a pain in the ass.

reply
I stand corrected!
reply
As far as I know only the latest (unstable) version uses SDL3.
reply