Log In  


my turn to be that whiner guy I guess but here we go:
is there really a point to limiting compressed code size in html exports?

in my understanding exporting to html is a one-way street anyway, so why not just have the same limits as the exe? (of course I'm only asking this because I'm finding it really annoying and unfunny right now)

3


Lol I can relate.

Is the html export size limit the same as the compressed png size limit?


yep, that's where it comes from AFAIK.


That limit seems to apply to binary exports too.
No error raised though, the binaries are generated but then the cart won't start.

Once again, should that limit be enforced outside of pngs and the bbs?
Those exports are more akin to "fantasy custom boards" than "fantasy standard cartridges" after all.


> No error raised though, the binaries are generated but then the cart won't start.

I had some trouble with that, told zep about that and he said, that that is fixed now.


I think I saw this on another post or somewhere, it was an interesting thought...

Would you rather have compression limits or token limits?

I know it's not an either/or in the real world but it was an interesting debate (in my head, at least)


The size limits feel nonsensical to me.

Don't get me wrong. We need size limits.

These just feel like they were chosen based on vague notions of what a real cart would be limited by, but completely disregard that the corresponding concept on a real cart doesn't work the same way it does on PICO-8.

Like, the token limit I complained about a while back. Yeah, you'd only have just so much space to load your tokenized code on an old home system. But your tokens would be a byte each in pretty much every BASIC interpreter ever made. Not 4 bytes each like a Lua token, which in Lua's real world has to be able to handle much bigger programs and address spaces and so on. So you'd get like 32K of 8-bit tokens, not 8K of 32-bit tokens.

Look familiar?

Of course, unlike Lua, those tokens included string data and the leftover space was your garbage-collected heap, so it's still not a 1:1 comparison. But if we got 16k tokens it'd probably average out. Plus the overall cart size limit takes care of trying to overstuff your cart with string data.


As for the compressed size limit... I dunno, I think what we have there is that zep is saving most people from having to compress their own code and data to fit on carts. Maybe he should allow us to say a cart is not auto-compressed, or only certain sections like code are auto-compressed and let us do whatever compression we want elsewhere. I dunno. Then we'd have to spend more of our precious tokens on decompressors. Meh.

Again though, the compressed size limit is awfully low. Even NES carts were typically 128Kbytes, and functionally a PICO-8 is somewhere between an NES and a SNES, where I personally worked on a 3Mbyte cart.


Honestly, I kinda feel like the limits remain what they are because zep doesn't want to mess with the code surrounding them, and not because those numbers are actually the sweet spots, carefully tuned over years, as he has claimed. Feels more like the standard "I'd rather not f*** with that code because I'm afraid I'll break it" programmer reaction to a feature request.

As it stands, the token limit primarily makes this platform less fun without really being justified in my eyes.

The compressed limit is probably the closest PICO-8 comes to emulating a real cart's limit, since it's the actual number of bytes delivered to the user, based directly on the data given by the dev. I dunno about the number chosen, and it would be nice to have control over the compression, but at least the concept is realistic.


Same page here - It’s getting a bit depressing to win the fight on token count to be told ‘sorry cart is still too big’.
Something has to give if we want games with a bit more depth/play time.


I'm not nearly as technical as any of the rest it seems...I don't know how arbitrary the limits are or not. Doesn't really matter to me. Just thought it would be interest to hear insight.

As far as making games with more depth and such...well, I guess my attitude there is, don't use PICO-8. I've started to look into other setups because I do want bigger games but have come to really enjoy Lua.

To me, the whole point of PICO-8 are small games. I can replicate the pixels, resolution, etc with any platform, there's nothing unique there. But that doesn't mean I don't find the P8 limits a tad frustrating...however, I tend to roll that up into the "design challenge" of the whole thing. I know for sure that many of my P8 games have turned out better because the limits forced me to strip things out and redesign a bit.

Anyway...good discussion topic either way and it's not likely to end anytime. PICO-8 is certainly a great intro for games but people will no doubt "graduate" to other things.


One thing to note is that we're slowly getting to the point that multi-cart games will be easier to make and put up for people to play.

Given that, the limit on cart size seems a lot less significant. At that point, the 8k-tokens and 64k-source limits are really the only true limits.

I can understand why there might be a 64k source limit, given that we're editing on-target. It's typically one addressable bank of memory on an 8-bit machine and I can imagine an editor putting the entire source in a bank of its own.

I just can't get over that 8k token limit. It doesn't make sense to me. Not technically, not conceptually, and not from a fantasy console design standpoint. It's just too low. It causes too many people too much pained time dicking with their source code in stupid ways to make it fit, rather than just writing games. I just can't believe zep actually wants that.

There's got to be some other reason why that's the limit, something due to code choices under the hood.



[Please log in to post a comment]