Log In  

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

P#110097 2022-04-12 04:17 ( Edited 2022-04-12 04:33)

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

P#110150 2022-04-12 21:01
2

this is wild! head left to -928,0 -- the circles stop drawing fully

Cart #circleexplorer-0 | 2022-04-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
2

edit: oh btw: this is all happening in the local pico8.exe as well -- this isn't unique to web afaik

P#110153 2022-04-12 21:11 ( Edited 2022-04-12 21:14)
3

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.

P#110157 2022-04-12 21:43
1

Same problem for this cart too, @pancelor

Those artifacts where it starts to break down are kind of fascinating!

P#110158 2022-04-12 21:47
2

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.

P#110160 2022-04-12 22:09

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

P#110225 2022-04-14 01:26 ( Edited 2022-04-14 01:46)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2022-11-30 07:03:46 | 0.042s | Q:26