Live data from Hacker News

LÖVE: 2D Game Framework for Lua

github.com

101–110 of 229 posts

Re: LÖVE: 2D Game Framework for Lua

#101
post #18

Earlier quoted context omitted.

SDL3

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.

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.

Re: LÖVE: 2D Game Framework for Lua

#102
post #2

I love LÖVE. For me it sits at the perfect intersection between high and low level abstraction. Unfortunately the latest released version is getting pretty long in the tooth now and a lot of devs use the latest HEAD from the repo since it has better performance and compatibility. One day the mythical 12.0 will get released for real…..

It’s been a recurring issue I’ve seen in open source where there is active development but no releases. I don’t get why you’d put all the work in to fixing bugs and building features but not hit the button to build a release.

Re: LÖVE: 2D Game Framework for Lua

#103
post #41
post #8

Btw, Love2D is based on SDL2. If you hate Lua but needs the same cross-platform capabilities, you can use an SDL2 binding in other languages or make your own.

Now why would you hate lua of all things?

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

Re: LÖVE: 2D Game Framework for Lua

#104
post #50
post #41

Earlier quoted context omitted.

Now why would you hate lua of all things?

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!

Luajit is often faster than C. The qualities you described above actually make it great for game dev.

Re: LÖVE: 2D Game Framework for Lua

#105
post #74

Earlier quoted context omitted.

You might like MonoGame. Same level of abstraction, but in C#. https://monogame.net

Since we've stepped from interpreted language (Lua) to compiled-to-VM language (C#), let's go all the way down to compiled, low-level language (C) with Raylib! https://www.raylib.com/

Or use raylib from luajit FFI and blow C# out of the water. Luajit can be faster than C, truly alien tech from Mike Pall.

Re: LÖVE: 2D Game Framework for Lua

#106

I generally very much dislike dynamic languages but for some reason I've always really liked Lua. I'm not exactly sure why to be honest. Maybe because you can fit the whole language spec on a single sheet of paper and adding more advanced features is pretty easy. Love looks really cool. I never got into it personally but I still might

It has a very lego-like feeling, with simple, orthogonal design that lets you build the language and constructs you need. Very elegant.

Re: LÖVE: 2D Game Framework for Lua

#107

I've used this for many projects that are still working to this day. That said, i'm not impressed. A web-based solution is usually better performing, despite all the bloatware necessary. This says a lot about the state of software development unfortunately.

I'm curious as to how you came to that conclusion. Did you run any tests, or is it just a general observation? What's your computer hardware like? This isn't an accusation of anything, I promise I'm genuinely curious.

I've not done proper scientific comparisons, but had to reimplement some games as websites to make them reliably perform on Raspberry Pi's we used embedded.

This is a bit of an apples to oranges scenario, because the algorithm and architecture is not exactly the same, despite the game functioning identical.

The main weak points of LÖVE that we hit were mainly around embedded video playback though, which is probably very well optimized in chromium.

Re: LÖVE: 2D Game Framework for Lua

#108
post #16
post #13

Earlier quoted context omitted.

too bad universe doesn't ship with unobfuscated source so that you could see whether you're unlucky, or just skill issue

The source is right there, you just have to grok it.

I'm still waiting for the slackers at CERN to finish decompiling it.

Re: LÖVE: 2D Game Framework for Lua

#109
post #50

Earlier quoted context omitted.

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!

Luajit is often faster than C. The qualities you described above actually make it great for game dev.

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

Re: LÖVE: 2D Game Framework for Lua

#110
post #75
post #71

Earlier quoted context omitted.

explain that to my webgl TypeScript browser game running at 180+ FPS while rendering a large RPG tiled world with infinite procedurally JIT generated biomes, with heavy processing delegated to webworkers.

As you aren't posting code or stats I can't say much, but I'd bet a native app would still be smaller and more efficient, since you have to wrap what you're doing in an entire Chromium instance and deal with a web stack designed for documents, which is definitionally less efficient than a native alternative. Tiles aren't exactly cutting edge technology. "Heavy processing delegated to webworkers?" That just sounds lik…

yep, native is faster for sure.

but webgl + web workers is good enough these days.

I can't share code sorry, the project got big and I have commercial plans.

But you can tell Gemini 3.1, Opus 4.6 or GPT 5.4 High to generate a demo and they do a decent job most of the times.

that's how I got started, seeing how it was possible to have good game performance with multi threaded workloads on a browser.

Post reply on HN