Bizarre crash when moving camera by a fraction?

General
1

Hi

I’ve encountered a really odd crash with the 2.5D game I’m working on. It’s turning into something of an epic, thousands of lines of code, and getting very sloppy round the corners. But it was pretty stable until today, when I started to adjust the way that the camera moves around.

This had the effect of making another part of the code, the explosions routine (or the score update routine, object cull routine etc etc), complete crash the Codea app (ie exit to the iPad home screen). i.e. This happened every time and was completely reproducible.

After going back over what I’d added, I eventually isolated one line that was causing the crash:

cam.offset.y = cam.offset.y - cam.velc.y

I eventually managed to fix this by making sure that the camera only moved by integers, using math floor and ceiling:

if cam.velc.y>0 then cam.dy=math.floor(cam.velc.y)
elseif cam.velc.y<0 then cam.dy=math.ceil(cam.velc.y) end
cam.offset.y = cam.offset.y - cam.dy
cam.velc = cam.velc - (cam.velc*0.2)

(At the moment, I’m just doing vertical scrolling, but it might end up scrolling in all directions, especially on a smaller iPhone screen)

Anyone have any idea why this is happening though?? The fix also is not ideal, as the deceleration of the scroll is not smooth anymore.

There must be some kind of interference or cross-talk with the explosion/cull/score routine, as the crash only occurs when that routine is called. It’s tricky though as the complete app crash means you don’t get a report from codea about what is going wrong

Is it worth syncing the iPad to iTunes and having a look at the codea crash log? Or are they tricky to decipher? Anyone had experience of a routine causing a persistent codea crash?

2

Can you share a small bit of code around the camera() and perspective() functions? Also, make sure you never look directly up or down, or use a perspective with an FOV of 0.

3

Very strange. It’s hard to say without seeing what your explosion/cull/score routine does

Can you build a very simple version that crashes? Then you could post the code.

4

@SkyTheCoder - I don’t think it’s related to looking vertically, given that integer adjustments work fine, but it’s hard to be sure without seeing code.

5

@yojimbo2000 - You need to figure out whether it is the actual value of cam.offset that is causing the problem, or the size of the change.

This is hard, because if it crashes, the debug info gets lost. However, you could make a string that stores a history of the value of cam.offset each time it changes (and anything else that might be relevant) and stores it on your iPad using saveLocalData. Then when it crashes, you can read the string out of storage and see what the last values were. If you do this a few times, you may start to see a pattern.

6

@SkyTheCoder this is the camera code (yup, it’s sloppy!)

perspective ()
...
camera(cam.p.x,cam.p.y+cam.offset.y,cam.p.z, ori.gin.x,ori.gin.y+cam.offset.y,ori.gin.z, 0,1,0)

@Ignatz you’re right, I think getting to the bottom of this would involve constructing a minimal working example (minimal crashing example?), which could take ages, as all sorts of things happen in this game when items explode (new items & pickups spawn, chain reactions trigger etc etc).

It’s just weird because there’s no obvious connection between the camera and the explosions routine.

Your idea about using save local data is a good one though

7

I know that Codea crashes if the camera’s upX, upY, and upZ are all 0.

8

Thanks everyone for all of your suggestions, I have now zapped the culprit. It wasn’t in the end much to do with the camera really, just very sloppy handling of the cam.velc variable by the touched routine. On touch ended I average out the previous 10 touch deltas to get a representative amount of delta for the scroll deceleration. I forgot to check whether there were any variables in this table though, resulting in cam.velc being set to vec2(0,0)/0 if there was an end event without a moving event. Division by zero results in (nan,nan).

So my code above, producing a separate integer cam.dy, was really just shielding the cam.offset from arithmetic with (nan, nan). I haven’t checked to work out which command was actually making Codea crash, as the cam.offset variable appeared in lots of things (as well as the 3d camera, it was used to translate back to 2d, to line the 2d and 3d up, and to offset all touches and coordinates. So it could have been any number of things causing the app to crash)

Here is the corrected code for averaging out the velocity from the touch routine (with a check whether the table is populated):

if #cam.vel>0 then --avoid dividing by zero
local vel=vec2(0,0)
for i,v in ipairs(cam.vel) do
vel = vel + v
end
cam.velc = vel / #cam.vel
cam.vel={}
end

Sorry for cluttering the thread with a stupid error!