So apparently I'm an idiot...or at least never read this in the manual (never thought to)

When saving in .png format, the compressed size of the code must be less than 15360 bytes. To find out the current size of your code, use the INFO command. The compressed size limit is not enforced for .p8 format. In most cases you don't need to worry about the compressed size, as the token limit (8192) will be reached first.

Given you can upload carts to the BBS by pasting in code, and exporting to HTML is also a separate process...you can ignore/avoid the compression limit entirely unless you want to pass around the PNG cartridge.

Dammit.

Here I spent a ton of time getting my game under that compress limit when I didn't need to. I was within token/character limits just fine. Arg!

Well...lesson learned...and maybe this call out can help someone else avoid the headache.

Any idea if Splore does .p8 files or just .p8.png files?

OT since I have your eyes: I ran across your website entirely by chance while looking up old game counselor photos for a friend. Left a comment but it didn't show up; do you moderate comments or did the comment just not work?

@morningtoast: that limit also applies to html exports. the manual is outdated anyway. I think save @clip should raise an error too, haven't tried though. .p8 is for dev purpose, everything else is for release.

@Felice: splore does show both when browsing your cart directory, with the appropriate icon.

@ultrabrite - good to know, thanks. feels nice knowing i didn’t waste all my effort getting under that limit.

@Felice - saw your comment on my blog and I still need to approve. I moderate the comments. Might shoot you an email too. :)

@ultrabrite: I meant for remote files on the BBS. But I imagine it does, I just haven't checked to be sure.

@Felice: I don't think you can upload a p8 anyway. it's either the old png way or the new (preferred) save @clip & paste.

Ah yeah, I just consider @clip effectively to be a .p8, that's all.

Edit: Apparently I'm wrong. See zep's post.

The way I view .p8 vs. .p8.png is that .p8 is mostly for development and .p8.png is for distribution. Removing the compressed limit on .p8 reduces the need to automatically strip comments etc. every time you run a large program, and/or gives programmers a chance to save an over-the-limit cart before they go about reducing compressed size.

It isn't possible to do anything with a .p8 over the compressed limit: save("@clip"), exporting to html/binary, and saving as .p8.png all require the cartridge to fit into 32k. The text you get from save("@clip") is actually just the png file in hex.

So in other words, morningtoast wasn't wasting his time to reduce the compressed size?

Thanks, zep...good to have an official light on things. Glad my refactoring efforts warranted after all.