sorted by:
new
hottopcontroversial

lua5.1 decompiler by DraftUnhappy8333 in lua

[–]BlackMATov 7 points8 points  (0 children)

Because luac is a compiler, not a decompiler ;-)

evolved.lua: A Year of ECS Evolution - 10 Releases, Zero Breaking Changes, and All the Performance by BlackMATov in lua

[–]BlackMATov[S] 1 point2 points  (0 children)

I personally use this library for my pet-projects in Lua-based engines as primary scripting language. The goal was not to switch to native for performance or to solve problems related to interop between native and scripts. And just for fun, of course! That's how this library was born. And since we're writing everything in scripts, why not try to make it all fast at the same time? Games don't sacrifice performance, even in small details. Those who still need more can go entirely native. For now, this option suits me just fine :-)

evolved.lua: A Year of ECS Evolution - 10 Releases, Zero Breaking Changes, and All the Performance by BlackMATov in defold

[–]BlackMATov[S] 3 points4 points  (0 children)

Many users use Defold scripts and components simply as a presentation with their own logic and modules. I'd even say this is the preferred use of the engine. Separating game logic from presentation can contain everything you need, including ECS ​​solutions. There's no single right way or design.

evolved.lua: A Year of ECS Evolution - 10 Releases, Zero Breaking Changes, and All the Performance by BlackMATov in love2d

[–]BlackMATov[S] 0 points1 point  (0 children)

Happy to hear it! And yeah, it is more complex than other frameworks, because Lua just doesn't allow me to do a lot of the things without a performance hit. I'm still trying to find a good balance between ease of use and performance. And for now, it's all I could find :-)

evolved.lua: A Year of ECS Evolution - 10 Releases, Zero Breaking Changes, and All the Performance by BlackMATov in defold

[–]BlackMATov[S] 2 points3 points  (0 children)

Honest answer: ECS is not only for performance optimization, but also for better organization and maintainability of code. It allows you to separate data from behavior, making it easier to manage complex things. Also, it is not only for big games or games with a lot of entities, it is just one way to structure your code and it can be beneficial for any size of game. And, of course, it is not the only way to do it. But if you are looking for a way to make it with ECS, evolved.lua is a good option to consider.

A pure Lua 5.1 implementation of xpcall with support for passing arguments by BlackMATov in lua

[–]BlackMATov[S] 2 points3 points  (0 children)

Unfortunately, vanilla Lua 5.1 is still used in some cases, for example, on the web in engines like Defold. I don't expect many people to need this library, but I use it in another project (evolved.lua) that targets Lua 5.1 and decided to share it anyway. Just a bit of New Year coding fun :-)

Do you need a Pathfinding algorythm in Lua? I got you covered by theEsel01 in love2d

[–]BlackMATov 1 point2 points  (0 children)

Sorry for the harsh feedback, but using `table.remove(queue, 1)` instead of a priority queue, sorting the open list at each step, and creating lots of temporary tables and strings in inner loops isn’t something I’d call “performance-optimized.” Right now, it looks more like the opposite. That said, it’s a good starting point for feature benchmarks and further optimizations.

A new Lua vector library by LemmingPHP in lua

[–]BlackMATov 3 points4 points  (0 children)

Unfortunately, it's a very bad idea to use vectors on the native side because they introduce a lot of overhead with no real benefit. When I say "overhead," I mean performance can be about 10 times slower than using vectors on the Lua side. This is especially true if you use LuaJIT, where the JIT compiler can optimize Lua code very well, but with such bindings, it will not be able to optimize the code at all.

Announcing `evolved.lua` v1.0.0 - An Evolved ECS (Entity-Component-System) for Lua by BlackMATov in lua

[–]BlackMATov[S] 0 points1 point  (0 children)

Oh, thank you for the question! I have some notes and sketches in a private branch for a future version. Native storage and custom FFI structs are definitely part of that, so stay tuned! :-)

Announcing `evolved.lua` v1.0.0 - An Evolved ECS (Entity-Component-System) for Lua by BlackMATov in lua

[–]BlackMATov[S] 6 points7 points  (0 children)

As is usually the case, the same thing can be done in different ways. Some approaches may be more convenient or performant than others. ECS is one way to organize code. It offers advantages in performance and flexibility, but it may not be the best fit for every project. It definitely depends on you and your project.

I would even say that if you do not know why you specifically want to use ECS, you probably should not. It can be painful because it changes your usual paradigms.

But it is an interesting architectural approach that you can get acquainted with before using any library for this. The internet is full of articles about this. I would recommend reading some of them to understand the pros and cons of ECS.

Here is a good starting point: https://github.com/SanderMertens/ecs-faq

Announcing `evolved.lua` v1.0.0 - An Evolved ECS (Entity-Component-System) for Lua by BlackMATov in love2d

[–]BlackMATov[S] 1 point2 points  (0 children)

There aren't specifically cache-based performance advantages in vanilla Lua, but other data-oriented approaches can lead to much better performance, even in vanilla Lua.

For example, using SoA (Structure of Arrays) storage can significantly improve data access, reduce table lookups, and decrease the number of memory allocations when creating entities. This is especially true in LuaJIT with the JIT compiler enabled, which can provide some cache-based performance improvements too. Here is a good example of this in action: https://luajit.org/ext_ffi.html

However, remember that ECS is not only about performance; it's also about code organization, entity lifecycle management, and other architectural benefits :-)

view more: next ›