LÖVE 11.4 - out now!

[ivan]

Congratulations on the new release. Just upgraded and everything seems to be working fine.
Looking forward to built-in SSL support in the next version!

[gcmartijn]

Upgraded and worked without any issue.
And for the first time I did compile on the M1 mac to a Ipad , and it is working.
Thanks for your work !

[Jasoco]

I'm having some weird memory weirdness with 11.4 on my 14" M1 MBP. It's hard to explain.

First I'll set it up. I've been toying around with g3d, which does take up some memory to hold all the vertexes in the meshes. So yes I'm aware it's pretty much pushing Löve passed what it's supposed to do. But the thing is, this doesn't happen with 11.3 running in Rosetta. (Basically macOS emulating Intel so older apps can run) It does load the models and run slightly slower because of the translation, but it never has the same issues.

Now to explain the issues. There's a couple. First is sometimes when the game is loaded, the frame time is much slower for no explained reason. Loading takes longer, updating takes longer, drawing takes longer. It's like Löve just decides to go into a lower power mode or something. It's just weird. Usually a quit and relaunch fixes it back to its normal super speedy self.

Second issue. Using the actual built-in "restart" command forces the above issue to happen on subsequent launches most of the time. So I never bother using restart anymore.

Third issue is a sudden crash I get randomly while testing the level. I don't know if it's just too big of a level or what. I mean it does generate a lot of vertices for the mesh. But the thing is this crash doesn't happen at all, so far, with 11.3. So I don't know if these are issues with the M1 port or just results of me trying to push Löve too far. I do have a copy of the crash log if it's useful at all to any of the devs. And I can provide a test copy of the project to someone who has an M1 to test on maybe? Thing is it's not a predictable crash. And I'll probably be reducing the size of my levels anyway to keep the vertex count lower. Maybe that's the issue. Too many vertexes. (My test level is way bigger than anything should be just because it's a stress test. Normal levels would be smaller and have a lot more filled in space thus reducing the number of wall, floor and ceiling triangles of course.)

Either way, even without that third issue, the first and second issues are still valid even with other projects so there's still that. I suspect the third is probably just too much memory usage. Thing is I generate everything at once. And I've had projects where the memory usage creeps up into nearly a gigabyte before being collected. But who knows.

[pgimeno]

The random performance could be a JIT issue. Note that 11.4 is the first version that includes LuaJIT 2.1. Random performance issues like the one you're reporting are common. On top of that, there's the extra memory taken by the JIT traces, and from what you're saying, that could be an issue at play. Do all issues disappear when you place 'jit.off()' at the beginning of main.lua? (the performance will drop of course)

[MrFariator]

I, too, ran into some various slowdowns and frame jitters. Not outright crashes, but noticeable lag spikes in places where there was none before. Disabling JIT is the quick and easy method, but tinkering with some values I just wound up increasing the memtrace and maxmcode options:

Code: Select all

if pcall(require, "jit.opt") then
  require("jit.opt").start(
    "sizemcode=64", -- this is the default on windows, but I'm just enforcing it
    "maxmcode=65536", --previously in löve 11.3 this was 8192
    "maxtrace=16384"  --previously in löve 11.3 this was 8192
  )
end

Those numbers may seem overkill, but I gave myself a plentiful margin just to be safe. When running on OSX though, I just disable JIT outright, until the issues with running LuaJIT on M1 Apple devices are fixed.

[Jasoco]

The random performance could be a JIT issue. Note that 11.4 is the first version that includes LuaJIT 2.1. Random performance issues like the one you're reporting are common. On top of that, there's the extra memory taken by the JIT traces, and from what you're saying, that could be an issue at play. Do all issues disappear when you place 'jit.off()' at the beginning of main.lua? (the performance will drop of course)

I've already cut down my project memory usage but I bet it would probably do it. So if I run into that issue again I'll try it and see. But it's probably the issue.

Hopefully all the memory things can be solved. The crashing I can avoid with smaller levels. But those other issues where it just decides to run slower with longer frame time even when nothing in the code is really causing it to happen, and then it just doesn't happen again next time, are just too weird to keep using 11.4 for testing. And just turning JIT off is probably not a solution as JIT is just sooo much faster it's crazy not to use it. Using jit.off() does seem to get rid of those longer frame time issues. At least from what I can tell using restart a bunch of times.

Shame, hopefully it is remedied soon? Or at some point at least.

I, too, ran into some various slowdowns and frame jitters. Not outright crashes, but noticeable lag spikes in places where there was none before. Disabling JIT is the quick and easy method, but tinkering with some values I just wound up increasing the memtrace and maxmcode options:

Code: Select all

if pcall(require, "jit.opt") then
  require("jit.opt").start(
    "sizemcode=64", -- this is the default on windows, but I'm just enforcing it
    "maxmcode=65536", --previously in löve 11.3 this was 8192
    "maxtrace=16384"  --previously in löve 11.3 this was 8192
  )
end

Those numbers may seem overkill, but I gave myself a plentiful margin just to be safe. When running on OSX though, I just disable JIT outright, until the issues with running LuaJIT on M1 Apple devices are fixed.

What exactly is this doing? And are there drawbacks? I might just manually create a large level with a lot of triangles in memory just to see if it does anything.

[MrFariator]

Those flags are optional optimization flags you can pass to adjust the size of machine code areas, total machine code in areas, as well as the number of traces in the luajit cache, respectively. Basically, given large enough code base, you can use those flags to allocate extra memory to luajit, which might help with some performance issues.

Of course, this doesn't solve the issues on Apple side.

[Jasoco]

Another issue I'm having is when going into fullscreen (desktop) on macOS at least, and using the mouse capture feature love.mouse.setRelativeMode() it works, but the mouse isn't "locked" into place. Instead if I move it far enough to the edge of the screen, say the left side where my Dock is or the top where the menubar is, it'll make the Dock or titlebar appear and the mouse will become visible, but Löve still has it captured. I've confirmed it doesn't happen on 11.3.

[knorke]

Short notice:
In the "Software Manager" of Linux Mint there is still only Love "Version 11.3-1"

...and long mildly interesting story how I wasted a whole night with a crash in v11.3:
I tried via console:
sudo apt-get update
sudo apt-get upgrade
It updated dozens of other software but not Love:

Code: Select all

The following packages have been kept back:
  linux-generic linux-headers-generic linux-image-generic love

I tried

Code: Select all

sudo add-apt-repository ppa:bartbes/love-stable

as seen on https://launchpad.net/~bartbes/+archive ... ove-stable but it changed nothing.

then I did
sudo apt-get install love
and it installed.

---

Now the good news:
11.4 actually seems to fix a crash that happend in 11.3
(Love just closes with exit code 134 in terminal)
My game was basically a scrolling tilemap and everything was being drawn by graphics.rectangle/line/circle, no real graphics yet. Also everything was rendered multiple times because splitscreen mode. Sometimes it randomly crashed, it seemed to crash less when the tilemap was smaller or when removing some drawing stuff...but 100x100 array is not that large.
After a night of looking for errors in my code I thougt "Hmm how about updating Love?"
And oooh there was related-looking fixes in the changelog!
Now the tilemap can be over 3000x3000 tiles large without crash.

Not sure crash stacktrace of v11.3 is still relevant:

(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff74b6859 in __GI_abort () at abort.c:79
#2 0x00007ffff4044498 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3 0x00007ffff4d30ac8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4 0x00007ffff40b1cbd in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5 0x00007ffff405561f in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#6 0x00007ffff5ceed27 in glPrimitiveBoundingBox ()
from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7 0x00007ffff5ce1615 in ?? () from /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#8 0x00007ffff7f39307 in ?? () from /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#9 0x000055555577c337 in ?? ()
#10 0x000055555562af38 in ?? ()
#11 0x00007ffff7a5ffb7 in ?? () from /lib/x86_64-linux-gnu/libluajit-5.1.so.2
#12 0x00005555555b2bc2 in main ()

It seems graphic related from the text fragments.
Anyways, thanks for making this lövely framework.

[GVovkiv]

In the "Software Manager" of Linux Mint there is still only Love "Version 11.3-1"

Yeah, mint/ubuntu/debian repos often have outdated and/or broken packages, especially for smaller and less popular packages, such as love, so, for future, on ubuntu based systems, it's better to use repo https://launchpad.net/~bartbes/+archive ... ove-stable, then system provided. I learned that hard way, when i was on pop_os, so i ended up with flatpak version instead, lol.