Live data from Hacker News

LÖVE: 2D Game Framework for Lua

github.com

211–220 of 229 posts

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

#211
Despite being a game framework, due to LuaJIT's great FFI you can just write whatever. I recently made a tool that captures frames from GTA:SA using GDI, and when holding ESC only show gameplay frames. It's an anti-epilepsy 'filter' for pause buffering intended for streaming. Now I just need to start streaming SA speedruns.

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

#213

I wish lua would be more popular outside of its scripting language bubble, but its tendency to occasionally introduce breaking changes every release doesn't makes it very palatable as a main language for writting software.

Are you taking about Lua or LuaJIT (the one used in Love2D)? Because LuaJIT will stay in 2.1 rolling release forever, the language is feature complete, no more breaking changes ever.

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

#214

Earlier quoted context omitted.

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

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 coo…

> 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.

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

#215
post #140

Earlier quoted context omitted.

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

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.

Janet does look impressive +1

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

#217
post #75

Earlier quoted context omitted.

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…

Nobody ever said in the thread that web is the most efficient platform, stop with your “designed for documents” trauma already.

The first post in this subthread was literally a statement that "A web-based solution is usually better performing, despite all the bloatware necessary." And you literally joined in to support that assertion against "the Electron haters."

And it isn't trauma, it's literal fact. Electron isn't used because it's technically superior to native applications, it's used because web devs are a dime a dozen. It's popular for business reasons, not technical reasons. It works "well enough," but only because computers are really fast but there's only so much slack an OS can take up when even parts of it are Electron apps, and probably vibe-coded to boot.

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

#218
post #28

Am I really the first one to mention pico8 in this thread? Anyway, pico8 is another option that has a bit different spin, but you also implement the games in Lua :)

antirez' LOAD81 never gets enough love in these discussions even though it is simply awesome: https://github.com/antirez/load81 Anyone looking at Lua/SDL/game engines would learn a lot from antirez' fun little afternoon project ..

With all due respect to antirez, this is too obsolete and most of it is too low-level to be of much interest to anyone using SDL for game development.

People would be better off looking at the examples page and repo for SDL itself.

https://examples.libsdl.org/SDL3/

https://github.com/libsdl-org/SDL/tree/main/examples

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

#219
post #207
post #188

Earlier quoted context omitted.

> For me, the table is extremely powerful. I like it that it can be used as a sparse array, a hash, a vector, whatever. Of course one must know, at heart, the difference between pairs() and ipairs() and what it means for your data, though .. So, as someone only very peripherally familiar with Lua, can someone please explain the table thing to me? I've heard Lua fans gush that Lua is tables all the way down, except it…

It's not really tables all the way down - Lua has datatypes like nil, boolean, number, string, table, userdata + lightuserdata, functions, coroutines. I think that's the entire list, actually. So a table is a hashtable. Just about anything can be a key to the hash - a number, a string, a boolean, another table, a userdata. I can't recall if functions and coroutines can be keys but I suspect they could. I definitely k…

Thanks, that's a great answer and I really appreciate it!

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

#220

Earlier quoted context omitted.

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 v…

I dunno if this is what you were seeing, but LuaJIT has some serious performance issues on ARM. https://love2d.org/forums/viewtopic.php?t=94760 It's unfortunate as Love2D is generally VERY snappy on x86. I used it on a 300MHz laptop back in the day.

As the open source author in question, I'd politely ask everyone to not draw overly-generic conclusions from an ancient discussion in some third-party forum, which links to a (now) resolved bug report.

Open source is not a one-way street. By publicly disparaging open source projects, you're actually harming the ecosystem you rely on.

Post reply on HN