During some glitchy sandstorm effect testing for a tweetcart, I managed to hard crash the Pico-8 executable completely. This minimal code reproduction does it consistently on my machine after about 10 seconds of moving around. It seems to be related to the interaction between sin, rnd, and line, because removing those line()s fixes things. Likely a specific hex value in line() blows up somewhere, and rnd hits it occasionally with this setup?
Warning: I have no idea what this code will do on the BBS. Run at your own risk, as it consistently crashes the PICO-8 exe completely in just a few seconds!
Here's a quick OBS window capture to demonstrate the crash. Try walking up and down while moving right, and say goodbye to the window.
I'm using a win 10 64 bit machine. Initial testing on the discord seems to indicate that this crash does not occur on Linux at all.
I'm just gonna guess, you are flipping some variable higher than 32767 or lower than -32767, @shy, and then it flips around completely to the opposite side causing a crash.
Check for that first, see if that is not a problem.
Also I did not see FLIP() anywhere in your code. You normally use this in tweets to show the display.
Good luck ! It looks like it's gonna be an interesting tweet when done !
Maybe this has to do with camera(). If I supply a significantly-high number as the X value, the crash happens more consistently.
With a bit more analysis, @shy, I have isolated the problem.
It is LINE(). You are making use of the draw line from point to point hundreds of times in remembering the point you last drew via:
line(x,y,c) |
I suspect you are overflowing something somewhere.
Try this:
x=24y=444h=0c=camera::_::c(mid(x-64,896),y-85) h=max(x-64,h+.3+min(2>>7,.4)) for i=99,480do line(h-rnd(9*sin(t()+i-y>>4)),i,0,i,4+rnd(4))end map(0,0,0,0,128,64) ?"⁵dcᶜ0웃⁶1⁶cf",x,y b=btn()x+=b\2%2-b%2y+=b\8%2-b\4%2 goto _ |
115-tokens. Here I have changed it so it draws a line from point to point each time. It no longer crashes.
If you can change your code to draw lines from A to B using 4-arguments with LINE without linking them each time through 3-arguments, that should fix your problem.
Appreciate the advice folks, but the point here is that the code crashes the exe. My code isn't overflowing the faked CPU limits, ?"⁶1⁶cf" is tweetcart shorthand for flip() cls(15), via P8SCII codes to reduce size. It only uses 5% CPU/frame, and the PICO-8 exe itself still hard freezes and dies without giving any kind of error message at all.
I think it's more important that this crash is solved than my code is fixed or optimized, as I've already moved on from this little experimental effect anyway. If you want to help, please don't try to fix the crash. Just try to figure out why it's happening, and on what platforms (Linux, Mac, RaspPI, etc).
@shy Your cart causes PICO-8 to dump core after varying amounts of time on my Linux system (Manjaro KDE Plasma, kernel 5.13.19-2-MANJARO, running under zsh). I have the core file, which I'd be happy to pass along to @zep through some secure file transfer mechanism or another. Core dump analysis is not in my wheelhouse, unfortunately, and even if it was, Zep would be the only one actually able to do anything about it :).
Thanks @shy -- I've reproduced this and will get a fix in for 0.2.4. It is indeed an issue with line() caused by bad clipping math.
Awesome! Glad to help, @zep. :)
StinkerB06's comment about camera() with high x values was likely useful info too, then. Might be causing integer overflows/underflows if that x,y subtraction happens before the line draw, especially with very large or small line() args.
[Please log in to post a comment]
