Log In  

Pico-8 is a great tool, and for many reasons. The main reason I believe Pico-8 is so awesome is because of its restrictions. Limited palette and resolution inspires creativity, limited memory and computational power inspires optimization, and limited data values inspires frustration.

Yes, frustration. What I'm talking about is the 16.16 fixed point that only allows number values to go up to 32,767. I've only just started using Pico-8 but this is such an infuriating detail to me, which is why I've made this post in favor of allocating just a little more space for numbers. Something like 48.16 fixed point instead, or even 32.16 or 24.16 if possible (I'm not too knowledgeable on binary storage).

Yes, I know, there are several solutions to this problem. I've researched many and even came up with one of my own, but when you're just trying to throw together a game that for whatever reason requires values higher than 32,767, it's a total pain! On a recent game (where I first encountered the number limitations), I found myself spending more time fixing and optimizing this problem then I did working on the gameplay. That said, I'm not very good at math, but I still believe that it should be easier than this.

Anyways, that's my rant, I would love to hear other people's opinions.

P#88484 2021-03-03 21:30 ( Edited 2021-03-03 21:32)

That sounds really frustrating, I'm sorry.

I ... wish I had something helpful to say? Like, I can think of a couple bits of code people have written to get around the size limit - Felice had a great function for printing PICO-8 numbers as signed or unsigned ints where 0x0.0001 is treated as 1 and JWinslow23 wrote a floating-point arithmetic library a little while back - but I feel like an actual change to the spec isn't going to happen. That size restriction usually isn't a problem for ordinary-sized numbers - like, if you want to calculate the distance between two points on the screen, you're very unlikely to have an issue doing a naive Pythagorean Theorem calculation - and for anything else ... I mean, in the PRACTICE-2018 about PICO-8, zep said that it was a relief to be solving comp sci problems instead of writing glue code. And bignum is a classic comp-sci problem.

(It looks like this PICO-8 cart from 2017 had some functions for doing bignum with strings?? I didn't find a library function for it with a quick web search.)

I wish I had something more positive to say, but this feels like exactly the kind of frustration that zep was saying PICO-8 was about: figuring out how to overcome a restriction or finding someone else's code to do so.

P#88501 2021-03-04 01:22

I've actually looked at both of those BBS posts and I even received several helpful suggestions from @JWinslow23 himself on Discord! I have found several solutions to this problem, it's just that most are cumbersome.

Anyways, personally, I think when solving math problems in code, the problems shouldn't be backend. The interface between the client and the user should be smooth. I get what you're saying with Zep creating restrictions to incite that variation of problem solving, but I feel like there's still so much room for that rush of arithmetic adrenaline on the frontend, creating cool visuals and gameplay and what not. Optimizing with Pico-8 isn't always easy, after all.

P#88510 2021-03-04 03:07 ( Edited 2021-03-04 03:09)
1

...I don't know what you mean by frontend and backend at all, but it feels like you hate this restriction and I simply don't. I think 16b.16b is the correct size for PICO-8 - like, literally exactly the correct size, it's twice 128 squared, that's exactly enough to Pythagoras any distance that fits on the screen - and it's so small that I can just write numbers as 0x3243.f6a8 or whatever and it only takes eleven characters. And it's symmetrical, which is beautiful, and it's 32 bits which is a standard size in computing. I actively like PICO-8's number format.

I think it would be a gigantic nightmare to change and also break at least some old cartridges - there are bitwise operators for rotating bits that necessarily assume 32 bits, and those would break. It would introduce a gigantic heap of bugs and break compatibility with old cartridges, and I don't think it would make PICO-8 any more PICO-8. I think it would make it less.

In my opinion, PICO-8's number format should be kept. And I hope you can find a solution to your problem that you don't hate.

P#88512 2021-03-04 04:40

Perhaps I'm using the words backend and frontend incorrectly... Anyways thanks for the input!

P#88514 2021-03-04 04:53 ( Edited 2021-03-04 04:54)

Just as a fun thought experiment, it wouldn't be that difficult to add bignums as a separate value type while preserving backwards compatibility. New literal syntax, defined behaviors for all of the built-ins and operators, upcast and downcast rules. The neat part is that access to addressable memory is mediated by functions (peek, poke), and Lua memory is not addressable, so there's opportunity to add stuff. It just couldn't be an expansion of the default number type, is all.

I agree that the built-in number type is (kind of surprisingly!) well suited to what PICO-8 is normally used for. Maybe it cripples math-y doodles which might otherwise be a compelling use case. But I also agree that the small screen size makes a counterargument in that case.

P#88553 2021-03-04 22:42

Yeah a secondary number type would be awesome as well, although a bit weird for Lua as it's meant to be really lightweight. Really any solution that addresses the problem would be nice. For example, adding built in math functions for numbers that have been shifted to 32bits instead of 16.16bits would be a great solution I think would satisfy a lot of people.

P#88596 2021-03-05 19:29

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 14:34:36 | 0.016s | Q:18