Log In  

I was just wondering everybody's opinion on the limitations of pico8?

right now there isn't really much we can do with it besides make very simple 1 level games.
pico8 could do much better if code limitations weren't so harsh.

also it seems people smash all there code together to preserve tokens which is not good
for example..
this takes up more space

local var = 0
      var = var + 1

then this

local var=0 var=var+1

which makes no sense

if code limitations were removed and cart loading time was reduced significantly
then pico8 could make much larger games while still saving to a small cart size.

what would even be better if pico 8 carts were separated into 2 parts

  • the compiled game
  • and the dev files

so what do you guys think?

keeping the games small maybe be fun but you can only do so much with it especially with the severe limitations of pico8.

P#48908 2018-02-02 20:59 ( Edited 2018-02-17 20:56)

I think it sounds like you have the beginnings of a spec for a really great new fantasy console. You might consider making it open source so others can help you by contributing to its creation. Some of the other fantasy consoles that have been created to have fewer limitations than PICO-8 also do this and they're doing well in that regard.

P#48912 2018-02-03 01:42 ( Edited 2018-02-03 06:43)

The limitations of PICO-8 are what define PICO-8.

Basically, what you want isn't PICO-8. If you want something less limited but similar, maybe try Löve2D.

P#48917 2018-02-03 03:54 ( Edited 2018-02-03 08:54)

I'm all for the limitations. In fact I believe they intentionally encourage more creativity & ingenuity than if they weren't there, just as 'real' systems did back in the day (& still do today).

However as someone with a project that bounces up against the compression & token limits regularly I do find myself wishing for a relaxation of the token limit for 'development-only builds' as it would really help with debugging. The perennial dance of finding & commenting out non-critical sections of code so that you can fit a print or assert statement in to figure out what's going on with some value or what have you can become slightly tedious after a time, especially as there's no built-in debugger.

For example; while in .p8 form, having a couple of hundred extra tokens available, while still retaining the current limit for png & html carts would make working near the limit a much more pleasant experience.

Before anyone grumbles about that, I'm aware of the debate on tokens & I can see plenty of arguments for why it should not be a thing. It doesn't help my situation though :)

...perhaps a set of 'debug-use only' instructions that don't contribute towards the token & compression count, but are also stripped out of the exported cart to prevent abuse (or have to be removed manually before it'll let you export) would be a nice compromise.

P#48920 2018-02-03 13:07 ( Edited 2018-02-03 18:14)

Yeah, with real game consoles your devkit usually has double the memory of the retail box so you can run debug/instrumented builds.

@zep could change it so any cart run from splore or the BBS only gets 8192 tokens but loaded directly gets 16384 tokens. That would require people to publish to "final hardware" while having more leeway while working on it.

Or give us an alternate run command, maybe debug that triggers the expanded memory, but only available with a loaded cart and not through splore or the BBS.

Or just refuse to save a .p8.png or to @clip if it's over 8192 tokens, same as with being over compressed space.

P#48921 2018-02-03 13:28 ( Edited 2018-02-03 18:34)

The trick would be doing it in a way that doesn't provide too much rope to hang yourself with of course.

P#48922 2018-02-03 13:35 ( Edited 2018-02-03 18:35)

"right now there isn't really much we can do with it besides make very simple 1 level games."

You should play more Pico games! Some are surprisingly big. Some are even infinite, procedurally generated.

For example, try this game out, the world is quite large: https://www.lexaloffle.com/bbs/?pid=29009

This RPG is reasonably big for the platform and can take a while to play through: https://www.lexaloffle.com/bbs/?tid=30700

If you can't think of how you might make larger games, look into compression and Pico 8 coding tricks. For example strings are a very efficient method of compressing a lot of data. A string is just one single token, and you can write a routine to interpret the string character by character to build maps. You could use run-length encoding, a very simple form of compression, to keep the size down - essentially instead of storing {1,1,1,1,2,2,2} you store {4,1,3,2} ("four ones, then three twos"). See this thread for info on using strings for compression: https://www.lexaloffle.com/bbs/?tid=28160

Here's a cartridge with 7,500 words stored on it, for use in word games and such: https://www.lexaloffle.com/bbs/?tid=3972

You can fit a lot onto the Pico.

But also remember it's not the only old school fantasy console. If you don't like it, there are plenty of other choices.

P#48923 2018-02-03 14:17 ( Edited 2018-02-03 19:17)

@Felice I don't see any reason that characters should take up tokens.

characters are't memory based or hardware based.
the only reason tokens are limited is because they are stored inside the cart instead of cpu instructions.

dev files or expanded cartridge size specifically for code could fix this.

also it encourages people to do more crazy things with code..
like data banks where tiles, sounds, and maps are stored and loaded from code.

P#48924 2018-02-03 14:20 ( Edited 2018-02-03 19:20)

Also on the subject of your other example...

also it seems people smash all there code together to preserve tokens which is not good
for example..
this takes up more space

local var = 0
var = var + 1

then this

local var=0 var=var+1

I don't think you have a really good understanding of Pico-8's limitations?

Both of these examples take up the same number of TOKENS. Tokens are words and symbols, like the equals sign or number 1. Both statements are 8 tokens.

The second one takes up slightly less COMPRESSED CHARACTERS, which is a different limitation altogether. The first is 33 compressed characters and the second is 21.

There is also a very good reason behind the compressed character limit, which is that it is required in order to fit the whole cartridge into a .png file. For posting games and passing them around as images, the limit is what it needs to be. Tokens are a bit of an abstraction from that but you tend to run out of them at the same time as the character limit.

@Felice I don't see any reason that characters should take up tokens.

characters are't memory based or hardware based.
the only reason tokens are limited is because they are stored inside the cart instead of cpu instructions.

dev files or expanded cartridge size specifically for code could fix this.

Characters don't take up tokens. Individual words and operators do. And characters are absolutely memory-based...they take up memory, like anything else. And the limit is fixed because it's what you can fit into a .png cartridge (due to png specifications).

also it encourages people to do more crazy things with code..
like data banks where tiles, sounds, and maps are stored and loaded from code.

Those aren't crazy things! Those are fun things. Programmers often love doing stuff like that.

P#48926 2018-02-03 14:34 ( Edited 2018-02-03 19:38)

IMHO, the most fun to be had with any scenario is being given rules and then bending them so hard that they almost break, but don't.

But that requires rules.

And the stricter the rules, the more impressive it is when you can bend them to your will.

But of course if they're too strict, that's no good because even what you can do when you bend them is too limited.

PICO-8 strikes a good balance between the two. For me. YMMV.

P#48931 2018-02-03 16:13 ( Edited 2018-02-03 21:14)

Re: dev files, note that .p8 (non-cart) files are allowed to exceed the character limits, just not the token limits. If characters are the issue for a large cart, you can continue to develop your game, then use a Lua minifier to squeeze out comments and variable names (at the expense of readability). My picotool suite has a minifier:

https://github.com/dansanderson/picotool

Don't forget Lua's multiline comment syntax, which is handy for commenting out blocks of debug code. Run the result through luamin and it's not included in the final cart.

--[[
...
]]

My original post on picotool includes a graph of chars vs tokens for all carts published up to that point, my attempt at demonstrating empirically that minification is not necessary in general. Tokens are a reasonable measure of the semantic size of code, and with the current limits, tokens tend to dominate characters.

It actually turns out there are a few edge cases where you hit the uncompressed char limit first and the minifier comes in handy after all. The fastest way to do this is to encode extra graphics/sound data as Lua strings. :)

P#48951 2018-02-04 02:10 ( Edited 2018-02-04 07:10)
1

I don't know about anybody else, but the token limit is the only thing allowing me to actually finish anything. I've completed two projects and am working on my third. As a parent with a fulltime job this has been a godsend to me.

I suppose I might feel differently if I were still in my teens or twenties and had much more free time than I do now. But those days are long past :)

P#48957 2018-02-04 09:54 ( Edited 2018-02-04 14:54)

Pretty much what @arashi256 said. It helps you to do manageable game dev while the rest of your life is happening!

P#48965 2018-02-04 11:02 ( Edited 2018-02-04 16:02)

+1 for @arashi256 - having a full time job + familly, I stopped never finished project on Unity the day I discovered pico (+ I can code during commute time thanks to pocketchip)

+1000 for @dddaaannn toolset. I couldn't have completed Nuklear Klone without picotool minifier!

P#48970 2018-02-04 16:17 ( Edited 2018-02-04 21:17)

I think the argument is that if tools like "minifier" are required to get it working... why not just allow the space you're using without it anyhow?

I'm not saying it has to go too much bigger in scope; but what projects I've done, I've hit the token and/or char limit about 75-80% into... and that feeling SUCKS.

P#49148 2018-02-10 22:45 ( Edited 2018-02-11 03:45)

Because with those requirements relaxed, then people would just be making yet more slightly complicated games and request that THOSE requirements be relaxed. You're going to bump into the platform's limits either way. Pico as it is occupies a very specific space in what games can be created for it. In fact I think it encourages "sketches," just little fun programs that don't even use half the space for prototyping effects and code exercises.

P#49149 2018-02-10 22:59 ( Edited 2018-02-11 18:12)

With a set unyielding, immutable limits to how much content you can stuff into a PICO-8 cartridge, it's interesting to see what people can do within those confines. Everybody is working with the same rulebook and that's what makes things like PICO-8 interesting. It makes it easier to judge your own work :)

P#49158 2018-02-11 08:14 ( Edited 2018-02-11 13:14)

Specific to the question of whether a minifier ought to be necessary, that's primarily the point of the token limit. Pico-8 painted itself into an interestingly shaped corner historically, beginning with only an uncompressed character limit, then adding compression to the format of the steganographic .p8.png format. Coding to a compressed char limit is unpredictable and punishes good coding practices like comments and variable names, so Lexaloffle introduced the token limit and doubled the char limits.

The compressed char limit is still necessary because of the fixed-size .png cart format. Some char limit is still necessary because without it people would just encode graphics etc. as strings. In general, the token limit dominates. The minifier still turns out to be useful in edge cases to squeak out those last few chars ahead of the token limit.

I think the code size limits get the most attention because of the developer experience. It's easier to account for, say, the size of the sprite sheet in advance than it is the code size, which can still sneak up on you even with careful planning. I like the blinky warning indicators in the built-in code editor, though they're still a surprise when using external editors.

I've not personally had the experience of filling available space on an actual retro platform, but I've heard the stories. Packing raw assembly code into a tight space sounds like a specific kind of fun, doubly so when using a compiled language. Lua tokens feel like an arbitrary substitute for assembly instructions, especially when the char limits are still present. But they do the job.

P#49222 2018-02-12 13:32 ( Edited 2018-02-12 18:32)

I'm not a PICO-8 user but I'm looking through the documentation and it seems like the token limit is trivially bypassable?

Can't you load your program into RAM as a pre-compiled long string of data and cstore it into to ROM before executing the program? It seems like it should be simple enough to write a loader that does this. The token limit therefore becomes merely an obnoxious little snag that you have to work around by introducing an awkward external build step between writing and running your code.

Please correct me if I'm wrong!

P#49349 2018-02-16 19:50 ( Edited 2018-02-17 00:50)

I think cstore() can only access certain parts of the cart, not including the area reserved for the Lua program. Self-modifying code would be cool.

From the documentation - "The code section ( >= 0x4300) is protected and can not be written to."

P#49350 2018-02-16 20:41 ( Edited 2018-02-17 01:44)

elnil: Thank you for pointing that out; I missed that in the documentation.

So we just have to embed a lua interpreter into the cart's code and pass it the game's source as a string! I fear in that case that the compressed code length limit might be a problem :)

P#49355 2018-02-17 01:42 ( Edited 2018-02-17 06:42)

You could, I suppose, write a VM and use the data section to store code for that, but that seems a bit silly.

P#49360 2018-02-17 09:50 ( Edited 2018-02-17 14:50)

Well I mean that's kind of my whole argument. If you can effectively bypass the token limit by adopting some awkward coding style then it no longer serves to help guide the aesthetic of the carts and merely becomes an annoying roadblock. It only takes one person to write and optimize and document a VM and then anyone can use it to bypass the token limit if they have a high enough tolerance for coding to a weird new style (and potentially limited API).

I'd be interested to see if someone could make this work with a small enough section of VM code to allow sufficient space for a program that's actually bigger than the current limitations allow for.

P#49362 2018-02-17 13:55 ( Edited 2018-02-17 18:55)

Domain-specific VMs for game engines are an entirely appropriate way to structure your game code. They're not silly in general, and I would consider code-like data in the addressable region to be a valid technique for very large Pico-8 games that span multiple carts.

Remember that multi-cart games cannot currently be uploaded in whole to the BBS. Also remember that reload() introduces an artificial delay and loading indicator. You can't stream gfx/sound/virtual code from other carts to pretend they're all one cart.

If the concern is that the multi-cart feature would guide developer behavior in general, keep in mind that this feature has been around for a very long time and almost nobody has used it. I can only think of a couple of examples of multi-carts and they're not finished games, IIRC. (Maybe people are publishing to itch.io and I'm not paying attention.)

Encoding data into Lua strings is also quite common. I often do it when I don't need the flexibility of the map region to define a level, e.g. a level map is just a grid of wall/space/object 1/2/3, and it's more compact to use a tool to make levels into encoded strings than to use the map editor directly. Yes, this impacts the compressed char count such that this is not generally useful for hiding full-res graphics/map data.

I fully agree that "loopholes" that encourage dysfunctional developer behavior across the community as a whole would be detrimental. I think actual community behavior has shown that the possibility of alternate ways to encode behavior is not a real issue, and we have a good balance with the token limit, the compressed char limit, and the various features surrounding the addressable memory region.

P#49365 2018-02-17 14:17 ( Edited 2018-02-17 19:21)

We used to tokenize high-level scripts into custom formats on SNES. You couldn't run the whole game on them, because they were slow, but they were great for saving space on high-level logic code that would otherwise have taken 10x the asm space.

P#49369 2018-02-17 15:56 ( Edited 2018-02-17 20:56)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 14:28:48 | 0.055s | Q:49