LÖVE

I'm having real REAL trouble here. When the camera shakes and the player attempts to go to the next room (sometimes they don't even need to do that) the camera position flies off and then the game freezes.

From what I've found the game freezes because of a mixture of bump.lua (kikito's collision lib) and when I use getVisible on the Stalker-X camera. Apparently the camera x (or y sometimes) goes to a really high value like 1.29472929e+17, so bump.lua does its best to iterate from something like 0 to that number, which understandabley takes forever hence freezing/slowing down the game

The camera shakes when the player gets hit. So movement with w-up, s-down, d-right, a-left.

The main suspects I've narrowed it down to are:

toybox/libs/camera.lua (update method is where camera shake is updated)
soulp/level.lua (lines 151 - 239, update method)
soulp/level.lua (last lines, ~729 where camera shake is called)

This happens when follow_style of the camera is "LOCK_ON" (and anything besides"none","",any other unspecific style and "no_deadzone"(I think) which don't allow shaking.)
The camera also follows something called cameraMan in level.lua not the player directly (for a zelda like room-by-room camera).

Not that important, but soulp/game.lua has the player and soulp/entity.lua is the class most things are derived from.

The love file might error with "free" or something like "5,6" at first, but please just run it again....and again...and again until it will eventually work.

The file is in lower case.

I can't follow the program flow. This does not follow standard Löve conventions. You don't expect most people to try to learn your coding conventions and the LGML library in order to help you, right? I don't even know where the main loop is.

I had to disable fullscreen to make it easier to switch windows. After doing that, camera shake crashed less often. But what did crash, almost always, was changing screens.

The crash in this case is an infinite loop, but I can't tell where because I can't narrow it down. I tried disabling JIT and that made no difference, so it does not appear to be a LuaJIT bug.

pgimeno wrote: ↑Fri Aug 05, 2022 6:06 pm

Code: Select all

Error: toybox/libs/tools.lua:12: module 'soulp.Gun' not found:

The file is in lower case.

Thanks for fixing . Normally the when I run the love file it tells me these errors.

I can't follow the program flow. This does not follow standard Löve conventions.

What do you mean ? Is it the way I packed the love.load,draw,update,etc ?

You don't expect most people to try to learn your coding conventions and the LGML library in order to help you, right? I don't even know where the main loop is.

I had to disable fullscreen to make it easier to switch windows. After doing that, camera shake crashed less often. But what did crash, almost always, was changing screens.

The crash in this case is an infinite loop, but I can't tell where because I can't narrow it down. I tried disabling JIT and that made no difference, so it does not appear to be a LuaJIT bug.

Thanks for looking.

Sorry for all that (the LGML lib is kind of my lib, just that one thing is named LGML). I wouldn't have asked if I didn't try really hard before. I pinned down the problem and where the issues come from.

I also tried to pin down where the problem came from 'cause I can understand it's hard to look through someone else's code (especially mine )

Gunroar:Cannon() wrote: ↑Thu Aug 04, 2022 11:56 am
From what I've found the game freezes because of a mixture of bump.lua (kikito's collision lib) and when I use getVisible on the Stalker-X camera. Apparently the camera x (or y sometimes) goes to a really high value like 1.29472929e+17, so bump.lua does its best to iterate from something like 0 to that number, which understandabley takes forever hence freezing/slowing down the game


The main suspects I've narrowed it down to are:

toybox/libs/camera.lua (update method is where camera shake is updated)
soulp/level.lua (lines 151 - 239, update method)
soulp/level.lua (last lines, ~729 where camera shake is called)

This happens when follow_style of the camera is "LOCK_ON" (and anything besides"none","",any other unspecific style and "no_deadzone"(I think) which don't allow shaking.)
The camera also follows something called cameraMan in level.lua not the player directly (for a zelda like room-by-room camera).

Not that important, but soulp/game.lua has the player and soulp/entity.lua is the class most things are derived from.

I think I'll just make shake a different function so the camera doesn't mess it up.

What confused the hell out of me was the redefinition of print(). Once that was sorted out I was able to see where it crashed and why. Your diagnosis was more or less correct, poor bump.lua can't deal with numbers that big. This patch makes it throw an error instead of hanging: I dont' think the only problem is camera shake. Changing rooms also triggers the problem.

Oh, I changed print to log into a file, sorry.
Thanks for looking deeper.

And yes, it happens when rooms are changed (though a rare few times just when you get hit) so shaking itself is not the problem but from what I can tell if shaking is disabled and you change rooms everything works fine so I believe it's the root of the problem when I try to move the cameraMan.

pgimeno wrote: ↑Mon Aug 08, 2022 12:18 pm

Code: Select all

   for cy=ct,ct+ch-1 do
+    assert(cy < cy + 1)
     local row = self.rows[cy]
     if row then
       for cx=cl,cl+cw-1 do
+        assert(cx < cx + 1)
         local cell = row[cx]
         if cell and cell.itemCount > 0 then -- no cell.itemCount > 1 because tunneling
           for item,_ in pairs(cell.items) do

Also could you explain how the assert works. Shouldn't cx/cy be always smaller than the value + 1?

Gunroar:Cannon() wrote: ↑Mon Aug 08, 2022 1:25 pm Shouldn't cx/cy be always smaller than the value + 1?

Not anymore when the 64-bit floating-point numbers used in Lua are so large that they've lost enough precision that every whole number cannot be represented anymore and gets rounded. The asserts would also trigger if cx/cy was infinite.

ReFreezed wrote: ↑Mon Aug 08, 2022 3:31 pm

Gunroar:Cannon() wrote: ↑Mon Aug 08, 2022 1:25 pm Shouldn't cx/cy be always smaller than the value + 1?

Not anymore when the 64-bit floating-point numbers used in Lua are so large that they've lost enough precision that every whole number cannot be represented anymore and gets rounded. The asserts would also trigger if cx/cy was infinite.

Ah, okay. Thanks for the explanation of the assert.

Though pgimeno, I did already spot this part of the problem after a long time of observation before I posted. What I'm still wondering is ... why?

Anyways thank you for the assert function and info. It's nice to learn new things.

I don't have an answer yet. It's a lot of code to wade through. Maybe with Zerobrane and stepping I can see where one coordinate starts to grow exponentially, because that's what's happening.