this post was submitted on 14 May 2025
433 points (99.5% liked)
PC Gaming
10995 readers
400 users here now
For PC gaming news and discussion. PCGamingWiki
Rules:
- Be Respectful.
- No Spam or Porn.
- No Advertising.
- No Memes.
- No Tech Support.
- No questions about buying/building computers.
- No game suggestions, friend requests, surveys, or begging.
- No Let's Plays, streams, highlight reels/montages, random videos or shorts.
- No off-topic posts/comments, within reason.
- Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Correct!
So, here's where you make me go find some actual benchmarks, because you obviously have no clue what you are talking about, and have likely never written any serious code in your life.
https://programming-language-benchmarks.vercel.app/lua-vs-cpp
Take a look at the nbody benchmark scores. nbody is a simulation of Newtonian physics for a 3d point cloud of n number of objects.
When n is 500,000, standard Lua takes about 1145 ms, LuaJIT takes about 75ms, C++ takes about 20ms. to 35ms.
So thats in your two orders of magnitude ballpark range.
When n is 5,000,000, standard Lua just crashes, C++ evaluates it in about 160ms to about 315ms, LuaJIT takes about 715 ms.
So thats uh... infinitely worse? Standard Lua can't even do it.
...
Or take a look at the spectral-norm benchmarks, which show how performant a language is at manipulating matrices and vectors... the kind of calculation core to a 3d physics simulation.
Base Lua can't even complete any of the inidcated benchmarks at all. Times out, crashes, for each given n benchmark.
LuaJIT ends up being about one order of magnitude slower than various C++ compilers.
So these show you Lua doesn't scale well and crashes, because Lua is far less efficient with memory usage than C++ (or C, through LuaJIT)... when it comes to trying to perform the kind of calculations that would need to be performed in a 3d physics engine.
...
I am saying that standard, non LuaJIT Lua is indeed too slow for this, because that is true.
All of that is infact true.
I know this, because I have tried it, I've done it.
Lua is too slow, and all of those things I mentioned are indeed what happen if you try to implement 3d physics entirely within it, instead of using a game's actual, native, almost always C++ physics engine.
...
You don't seem to get what I am saying.
If it is the case that your scripting language, whatever scripting language there exists a plugin for, for whatever game... if that scripting language doesn't have an API method of referencing or manipulating an actual collision mesh or hull... then that doesn't have anything to do with that particular language itself, it means the API is insufficient, the method of communicating between the game's core library and the added in language is insufficient.
What I am saying is, is that this isn't specifically a problem with whatever language you are writing your modifications in.
It is a problem with the API, the injection and interaction system/method/layer.
Thus, the problem you are pointing out as specific to Lua in this instance... isn't even a problem with Lua per se. It would be a problem with any language that is using that particular interaction method.
...
You could compile a .dll that overrides or injects into or otherwise manipulates or interacts with the core game code itself, and then also possibly provide a custom .exe that uses the custom .dlls and the base game .dlls and other files.
This is what many ENB Shader mods do (complex lighting is a different kind of physics calculation), its what Skyrim Script Extender, New Vegas Script Extender do.
Those kinds of mods represent basically a better, more thorough or more powerful API, roughly, as compared to your theoretical example... because they directly manipulate the core game code, have access to more of the core game's function libraries.
NVSE can do things like manipulate the world's gravity, manipulate friction values between different classes of physics objects, manipulate how ragdoll tensor and flexor limits operate, etc.
It can and does directly manipulate the core game physics code.
...
Also I am.... fairly confident that embeddeding a scripting language into a game that doesn't normally support said scripting language... I don't see how or why a VM would be involved in that at any point... unless you're talking about the entire modded game being run in a VM?
I don't know why you would need an entire virtual machine, a virtualized entire operating system... to add Lua into a game. That makes no sense.
...
Nope, I am not bullshitting.
I have never seen or even heard or a 3d, rigid body physics system that is performant enough to run in a 3d game, that just runs in standard Lua, that doesn't pass it to C as LuaJIT does.
There are many games that have their physics engine done in another language... usually C++... which expose an API that parses Lua, such that custom scripts or mods can be written for that game... but that doesn't mean the physics engine of the game itself is somehow now written in Lua, it just means you are using Lua to instantiate and perhaps provide basic initial position, rotation and velocity vectors to an ingame object... and then the physics calculations are handled by C++.
I asked you to provide an example of an actual 3d physics engine running in Lua, because I am calling bullshit on you.
I have never heard of one, I don't know of one that exists, yet you just confidently claim 'oh actually this is totally possible and would be comparably performant!'
You... seem to admit you are bullshitting with these statements:
Yes, 3d Lua physics examples do exist, but as you say, they are mostly gimmick, proof of concept things, where someone mocks up a 3d physics engine in Lua, and would then presumably later learn how to port that code over into a more performant language like C or C++ or Rust... so that they could actually be used in a releasable game... because Lua is too slow to be useful as a core language for a physics engine, unless its translated into a faster language and then compiled, as is done with LuaJIT.
You do not seem to realize that that literally is the more technically worded version of the exact point I am making: Lua is slow, no one has figured out how to code a 'more mature and feature-rich' 3d physics implementation that is comparable to C++ physics implementations, which actually runs in Lua, and doesn't pass it over to C and run the actual code in C, as LuaJIT does.
...
In summation, you yourself claim that a performant and fast Lua physics engine could exist, and when I ask you to provide an example, you stammer and waffle about with claims about theoretical ones that could exist, and then in the end of your post you admit that the only Lua physics engines/simulations you know of are basically little toy ones that are not efficient or fast enough to be used in a game.
... But thats after you say that I am bullshitting by saying the thing you just said at the end there.
Do you even realize you are contradicting yourself and being a hypocrite?
You remind me of the edgelord script kiddies I used to run into on Facepunch all the time.
All talk, no walk, and the talk is all nonsense.
Please either actually learn how to code, or go back to reddit with your baseless bullshitting.