In my game Orbital there's a circ() call that looks like this:
circ(ax,ay,(time()*400)%4800,3)
It represents a rapid expansion (approx 13.3 pixels in radius per frame) of a circle until it reaches a max radius of 4800, then it restarts.
It looks like this up close (it's the fast green one at the end):
and it should be able to be seen from 37.5 screens (4800 pixels) away. (The mini-map at the top represents 16 screens width):
However, when playing on the web version, the circle only extends to 1024 pixels radius, then it stops rendering until it cycles around again. It never renders the circle with a radius bigger than 1024. Not sure why this is, but it happens on the Pico-8 BBS and on Itch.io.
edit: limit appears to be 1024 on Firefox 99.0, actually a little bit less ~980 on Safari 12.1.2
I've noticed circ behaving weirdly with high radius too; for example this cart of mine:
https://pico-8-edu.com/?c=YT0wLzA6Ol86OmEtPTNjaXJjKDAsYSxhLGEmOSk-YQpnb3RvIF8=&g=A
(this was made for a demoparty where the .p8 file, including the header, had to be <=64 bytes, so I didn't have much space to work with. in my case it was nice that circ acts weird b/c it gave me an interesting effect without much code!)
That number being printed on the side is the radius. I'm not sure why your circles seem to disappear at high radius - maybe the noise is larger than a screen, so it passes your ship without ever being visible? or maybe things behave strange away from the main axes - my cart is always drawing a circle centered at (0,r), so the part visible is always the very top of the circle
this is wild! head left to -928,0 -- the circles stop drawing fully
edit: oh btw: this is all happening in the local pico8.exe as well -- this isn't unique to web afaik
oh wow, it was happening on all 32-bit builds. This was a type typo: "long" instead of "int64", which only guarantees 32 bits on 32-bit targets.
Thanks @UnitVector -- fixed for 0.2.4d.
It's still disconcerting that different /browsers/ are giving different results, but it's plausible that their JIT compilers are also handling the long ints with varying levels of precision.
Same problem for this cart too, @pancelor
Those artifacts where it starts to break down are kind of fascinating!
Any use of the word "long" outside of a typedef should just throw a warning in C/C++ compilers these days. It's way, wayyyyy too unreliable a type in cross-platform apps.
It works fine in my cart, and on the mac dmg, up to the full 4800 radius, and beyond. I haven't looked at the windows/linux/raspi builds.
Also, thank you! @zep
[Please log in to post a comment]
