Log In  


Following on from the 'some carts kill the browser tab' thread, those carts are no longer hanging for me, but there's still something funky going on in some of them compared to the desktop version.

It's most noticeable with https://www.lexaloffle.com/bbs/?pid=16351:

edit: background differences are more obvious at full res, sorry for the poor vertical alignment.



Okay, it might only be this one cart. I haven't managed to find any other examples so far, including other 3d carts from the same person.


I tried to see what could be wrong with that cart and one problem I found is that in some places it uses “if (something) do”, which is kinda illegal, but is accepted by PICO-8 because due to the “short if” statement rules that replace it with “if (something) then do end”. But I don’t think it could be the reason for the rendering issues.


Looks like something mathematical is definitely different now. Note the shape of the rear windshield especially.

I suppose it could be a flow thing, as @samhocevar said, where code is taking the wrong path through the poly rasterizer or something.

Actually, now that I look at it, the shapes are consistent even when the polygons are moved around on screen, so maybe it's a parsing issue with the polygon data, maybe something changed in the back end that's causing the numbers to come out differently from however they're packed?


Okay, it's not the "if then something end" vs. "if() something" flow control tweak that PICO-8 allows, since I just made everything absolutely correct and it still works locally on 0.1.11g and still renders incorrectly on the BBS.


tagging @zep

Okay, I found the problem. The author wanted to shift a value right by 16, so they did val/65536 (which, interestingly, they typo'ed as 63356). I changed it to multiply by 0x.0001 instead, and now it works on the BBS:

Cart #dibogomuyu-0 | 2018-12-07 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

So, zep, I assume you changed something in the number parser to deal with out-of-range numbers differently, and since 63356 isn't a legal PICO-8 number, it affected this title, which somehow was working in spite of using an illegal value. I think maybe this is okay and you don't need to do anything. It's on devs to use the platform correctly. At most, maybe point it out in some errata when you get around to releasing 0.1.12 in 2026, or whenever it finally ships.


As an aside, remember when I offered myself up as a free resource to find bugs in the source code under an NDA with you? This is what I'm good at. Think about it. I can help make PICO-8 a lot less buggy. I'm no good for architecting engine-sized code anymore, but obsessive bug-seeking is something my brain still seems to work well at.


Couldn't reply yesterday due to the site issues, but thank you for the investigation Felice & Sam. & Great spot too!

I guess it's not technically a bug (except in user space), so I'll resolve this.



[Please log in to post a comment]