LÖVE

modiX wrote: ↑Thu Feb 15, 2018 12:16 am Problem is the luajit does not include love functions. Eventually I understood that luajit is somewhat embedded into LOVE, that's why string.dump can exist, too.

$ cat > main.lua
function love.draw()
  love.graphics.print("Hello, world!")
end

$ luajit -b main.lua main2.lua
$ mv main2.lua main.lua
$ love .

It won't.

pgimeno wrote: ↑Thu Feb 15, 2018 12:29 am That doesn't matter for compiling the code. I've tested under linux:

Code: Select all

$ cat > main.lua
function love.draw()
  love.graphics.print("Hello, world!")
end

$ luajit -b main.lua main2.lua
$ mv main2.lua main.lua
$ love .

and the code runs. The reason for having LuaJIT is only to ease compilation, allowing it to be automated with batch files or the like. Maybe you manage to install two versions, in order to package for LJ 2.0 or 2.1 at will.

raidho36 wrote: ↑Thu Feb 15, 2018 6:43 am Replacing dll's for the more efficient ones is a common practice, such as replacing openal32.dll by Creative to the ALsoft one. Linux and Mac do it automatically when new versions of dynamic linked libraries come out. By using bytecode you specifically make it impossible to do an upgrade this way. In case of Mac and Linux, the game will just break and won't work again, not without having user to compile old versions themselves and then also write launch scripts that override system libraries. Can't vouch for Mac, but on Linux you can do all-in-one distributions, however while isolated from system dependencies, it's prone to breakage the same way if any part of the OS changes and those are not Linux-friendly in general.

zorg wrote: ↑Thu Feb 15, 2018 12:54 am It won't be faster just because it's compiled / dumped using any method.

raidho36 wrote: ↑Thu Feb 15, 2018 6:43 am The bytecode will not run faster - it's the same code as Lua generates when it loads source code file as normal. It may be parsed faster because it needs no text processing, however as a bigger file it takes more time to read its contents. In practice the difference will be marginal as the script loading times would be well within a fraction of a second. Just like with other types of compiled code, you will have to produce its own binaries for every single target platform and version you intend to support, and distribute them separately. Also I don't believe minor Lua versions are compatible either, as well as major versions. Lua bytecode is not defined and every implementaiton is free to generate whatever code it pleases (or none at all), so it can change without notice.

The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess. However the bytecode compatibility versions must match.

coffeecat wrote: ↑Fri Feb 16, 2018 3:43 am Bytecode as generated by LuaJIT string.dump() is portable:

The generated bytecode is portable and can be loaded on any architecture that LuaJIT supports, independent of word size or endianess. However the bytecode compatibility versions must match.

If you always bundle the LuaJIT library with your game (may require custom build of LOVE), bytecode compatibility is also not a problem.

slime wrote: ↑Fri Feb 16, 2018 9:51 pm love must use LuaJIT 2.1 on iOS and Android, in order to support 64 bit devices. It uses LuaJIT 2.0 on desktops but you can swap it out for the 2.1 beta if you want.

luajit 2.1 bytecode that works with 64 bit ARM is incompatible with 2.1 bytecode that works with 32 bit, as far as I know. The page you're quoting from only pertains to LuaJIT 2.0 which didn't have this split (GC64 versus not).