LÖVE

So I'm developing a visual framework for a project I'm making. It has containers with parent childs relations like in CSS and stuff, then you have elements you can add to the containers like buttons which spawn a parent in the parent you add them to. Now the Views are where you can create different containers, and elements and load the view with the GUI manager. Then they get displayed on the screen.

The super weird problem I have is that I noticed I couldn't click on any of my buttons to go to a different view. Element collision (and so buttons) is calculated by adding the elements/containers you're hovering over to a container compare and element compare table to see for what element or container collision should be on by returning winning element and winning container as a variable.
The reason I couldn't click on the buttons was that sometimes multiple of the same buttons containers and other random containers got updated more than once a frame. That confused my colision checker, I tried adding every created container and element to a table with a key that is it's own element or container number to always iterate over the update and display table from the elements and containers in order. This didn't stop them from being updated more then once a frame, so I guess order wasn't the problem. I decided to make a if else statement to block off the update function of a container if it's called more then once a frame by putting its name in a containersupdated table that gets empties every new frame. This works. Now that's nice, but it also works when I'm only iterating over the containersupdating table without even then blocking off the child updates in the container afterwards, but when I don't iterate over the containersupdate, the problem occurs again. I disclosed some pictures of when it works, and when not. Also if and many times it repeatedly gets updated depends on RNG, since the code should execute the same every time (no time used, no RNG number are generated, not pulling data that different from a random source, so basically no possible RNG way except for for loops iterating over tables in different orders).

Hopefully, someone can explain what the hell is going on, and why calling a simple for loop fixes it.

The view "Taakweergave" gets loaded by default BTW. The subviews that are called are the Notificatie (notification), and Topbar

The update happens in the Container file from line 513

Sorry, I can't run the code from your screenshots. Please make the .love file for it.

darkfrei wrote: ↑Sat May 06, 2023 12:38 pm Sorry, I can't run the code from your screenshots. Please make the .love file for it.

There is a rar archive attached, although it should be zip for more compatibility and easier handling since that would only need to be renamed to .love...

Looks like a LuaJIT bug.

I tried to print how many times the loop executed, so I added a counter, and that "fixed" it: The unindented lines are the ones that I added. If the increment was moved one line up, the problem was still reproducible.

From the description, I had a hard time understanding what the problem was and what the expected behaviour was, so here are some indications for others who want to try:

Edit "GUI/Container [Obj].lua" around line 512 as I did above, except for adding the cnt variable; i.e. just comment out everything related to obj.donotupdate. Then start the application. It works normally for a while; then all of a sudden, in the debug lines to the left you can see that something has changed and the ButtonElementContainer lines appear duplicated, and then the top buttons stop getting activated (hovering still highlights them, as does clicking, but they don't get active). It doesn't happen always, but for me it happens in more than 50% of the times, after about 15-30 seconds.

Hi thanks for all the replies : ). I didnt get notifications that someone answered the post. Thanks everyone for the replaies about how to send the code for debugging next time. I use a batch file on Windows to run my code and zipped it with .rar. For pgimeno, thanks for looking into the problem! It indeed happenw at random. You are correct when trying to understanding the problem. Duplicate versions off the containers appear. The more container objects are ther, the more it goes wrong and happens at random time intervals. I also know that no new containers are created which why I blocked the update if it wanted to update multiple times.

If it is a LuaJIT bug, what do you think you know what causes it? A memory overload? With the garbage collector off memory keeps increasing when I look in task manager. Also I think the fps is really instable because of this bug. It fluctuates a lot.

It might be an issue similar to the one in this thread viewtopic.php?f=4&t=92944 - or even have the same cause. There was an array initialization problem in LuaJIT when I looked back then, which was fixed later.

If you read starting here: viewtopic.php?p=248393#p248393 you'll see that I compiled Löve using a newer LuaJIT than the one shipped with the standard Löve distributions, and the problem was apparently gone.

Oh and you can get notifications for a thread by subscribing. The subscribe link is at the bottom, contained within the button next to the "Post Reply" one (hard to find if you don't know how).

Thanks for the details! What's in this post: viewtopic.php?p=248393#p248393 exactly discribes the issues I was having when debugging, since sorting the tables didn't even matter, so that also answers that

Is there some tutorial/post out there that explains in detail how Love2D works so I can compile my own version of LuaJIT with it? This also has to do with another question of mine which is that I don't fully understand of how packing LuaRocks with a project works.

You think that v12 Love will include the new LuaJIT?

Also thanks for the notification explaination!

Fabimawn wrote: ↑Tue May 23, 2023 5:22 pm Is there some tutorial/post out there that explains in detail how Love2D works so I can compile my own version of LuaJIT with it?

I can't give you a detailed step-by-step guide. You'd need some familiarity with the tools. The big picture is that you first need to compile LuaJIT (which only uses a Makefile to build) and then you need to tell `configure` to use the LuaJIT version that you've compiled.

There are compilation instructions in the README: https://github.com/love2d/love but they don't get into details of configuration options. Try `./configure --help` and see if you can work out how to change the LuaJIT library path.

Fabimawn wrote: ↑Tue May 23, 2023 5:22 pm This also has to do with another question of mine which is that I don't fully understand of how packing LuaRocks with a project works.

Are you sure that's what you actually want?

Fabimawn wrote: ↑Tue May 23, 2023 5:22 pm You think that v12 Love will include the new LuaJIT?

I can't speak for the maintainers but I'd say it's quite likely.

I can't speak for them either, although i will mention that as far as i know, 12.0 is going to use whatever the latest version of luaJIT is... of course, that doesn't mean that other jit related bugs don't exist, but older ones should be fixed if they were reported and mike found where things went wrong.

What i'm not certain about is whether a new luaJIT will be included in the 11.5 version or not that might come out as well.

zorg wrote: ↑Wed May 24, 2023 6:40 am What i'm not certain about is whether a new luaJIT will be included in the 11.5 version or not that might come out as well.

It will - in fact that's the main motivation for having a 11.5 release instead of just 12.0.

(We're working on a few more fixes before 11.5 is done, but you can download prerelease builds from here - right now the Windows and Linux builds use the latest LuaJIT version including fixes for pairs. macOS will be updated soon.)