Hello.
@zep, this one is for you.
Could you please NOT count inside memory any Pico-8 carts that have CRs or any lines that contain remarks.
This will be beneficial in two ways.
It will encourage coders to use multiple lines for their code with no penalty of adding CRs in them.
And two it will encourage coders to go crazy and REALLY give super-helpful hints, documents, and information on their carts and the functions that run in them.
For instance, this code.
--[[ Apple-Palooza written by dw817 Please consult the website at: http://applepalooza.com for more details regarding this. ]] |
Would in fact take zero bytes of space at all. Only true code like cls() megaton=1000 and pset(x,y) would take up your valuable 8192 of tokens and 65535 characters of space.
I am aware that code written like this may not fit neatly into your compressed *.p8.png code, but saved as a normal text file, *.p8 or even posted online, you could definitely take any code size at all and just skip around the CRs, --, and --[[ statements.
Would anyone else like this coding freedom ?
> Would anyone else like this coding freedom ?
Nope.
(Holding my remarks, as requested.)
As far as I can tell, the multi-line comment is already 0 tokens. At least it is when I try it. The compressed/actual character limit - eh, they're still characters, so I think you have to count them. I don't feel too strongly about this one way or the other though. The character limit is not something I've ever come close to hitting and likely never would as my games just aren't that big.
As aren't mine, @2bitchuck, however with the discovery and usage of Shrinko8, I am determined now to always write code that includes documentation as to what is going on. So when I post a new cart for anything you'll get two versions. The main is Shrinko8 for maximum speed and efficiency whereas the other will always be the decompressed and heavily documented educational release.
I believe it is entirely possible for me to run out of coding space for the mere fact I am documenting every command and line now.
I type 135wpm. Might as well take advantage of it. :)
... trying to give this some thought, guys.
Actually I don't think it's possible. It may be more of a metaphorical and imaginative challenge and debate rather than an actual and possible one.
It strikes me that ZEP limits to 64k when online additionally and someone could and probably would take advantage of all that space and wreck the good concept of limited 64k coding - despite its best intentions for design.
Certainly if =I= wrote a Fantasy Console, there would have to be limits, especially if that self-same code was to be saved into a finite sized PNG image.
Yet, as the Klingon commander Kor said to Kirk when he was denied starting a war against the Federation in, "Errand of Mercy."
"A shame, captain. It would've been glorious."
I'll repeat something I said from a previous suggestion to not count certain types of characters: On average, the compressed char limit roughly corresponds to the uncompressed char limit of the same text. In the general case, you can't allow more uncompressed chars without allowing more compressed chars. Compressed chars are a physical limit (albeit an arbitrary one) established by the fixed size of the .p8.png file. If you want to allow more chars of any kind, you'd need to increase the physical size of the .p8.png. Personally, I consider that a line not to be crossed when it comes to raising limits.
Comments already get a discount towards limits to encourage their use: they do not count toward the token limit. Beyond that, there's no getting around the fact that anything you want distributed with the final cart needs to be stored in the cart.
I suppose there's a broader question we could consider: A dev uses a minifier like shrinko8 to get a small amount of additional character space at the very end of a large project. Minification comes at the cost of making the shared code unreadable, but this is typically an unintended side effect. Most devs would be happy for others to be able to learn from their well-documented code. Should PICO-8 make it easier to claim the benefit of minification without the cost of obfuscation and hassle of third-party tooling?
This is technically equivalent to suggesting that PICO-8 drop all character limits and only use token limits. Minification effectively reduces code to its tokens, with a char size equivalent to a (rough average) constant multiplier of the token count. PICO-8 would have to drop the steganographic storage method for .p8.png files and switch to text segments and arbitrary file sizes. Worth it? Maybe.
As is, devs of large projects can always publish their .p8 file separately to Github. It's debatable whether anyone has seen major benefit from being able to read the code of large projects. When a dev sets out to publish a large cart with readable code like a tutorial, they can usually manage to stay within existing char limits. The benefits of minification can seem like a big deal to a dev at the end of a large project that nearly misses the original size target and needs just a bit more character space to finish. It's difficult to imagine that the extra chars make a qualitative difference in the kinds of carts you can produce for the platform, and so it's not necessarily a benefit that needs to be built in.
One might even consider it a detriment to the dev process of large projects! Apparently it's easy for a large project to hit the code size wall unexpectedly. Maybe devs need the bit of squish at the end that minification provides. It's also possible that it's not a big deal and devs can just remove features when they're out of tokens. ;)
Wow ! Quite a bit of good information you have there, @dddaaannn.
As for the age-old question, minification versus well-documented code. With Shrinko-8 now working properly for me, I choose BOTH.
Any time I post a cart now, especially if it is a useful function, I will include a Shrinko-8 version that fits neatly into someone's code and the well-documented version that would just clutter someone's code.
[Please log in to post a comment]
