[derefr]

I believe that, rather than a CPU usage limit (which would require some kind of CPU-cycle accounting tracking, which would impose a high overhead on a system that's based on high-level source-code interpretation rather than on a bytecode virtual machine), the PICO-8 chose instead to go the route of limiting code complexity by just limiting (Lua source) code size. So your code can go as fast as you like — you just can't have very much of it. Which seems to result in practice in games that have similar features and play-styles to retro-games, despite the constraint coming from a different direction.

Like I said: fantasy-console abstract machines don't aim for technical limitations; but rather, for stylistic limitations. They don't want to impose upon you low-level technical barriers, for you to just treat those limitations as implementation-time programming puzzles to be overcome or worked around. (If you want that, just write games for an actual retro console!) Rather, they want to impose high-level constraints that influence your design-time choices. Less like typing on a broken keyboard; more like writing a poem with constrained rhyme-scheme and meter.

That's why these are "fantasy" consoles — their particular lack of technical constraints means that they can actually require a decent modern CPU/GPU/etc to run; and so could never have actually existed in the era they borrow their aesthetics from.

[chrisallenlane]

> So your code can go as fast as you like

I've been working on an (IMO) sophisticated tactical game with strong AI in Pico-8 for just about two years now, and I can say that this is not true.

> which would require some kind of CPU-cycle accounting tracking

This is pretty much what it does.

Pico-8 tracks an arbitrary "cycle" budget, which is used to calculate how much computation you're allowed to perform per frame. You're absolutely not going to compute at "bare metal" speed.

Here's some info in the (community) docs:

https://pico-8.fandom.com/wiki/CPU

I don't know how this does/does not compare to the 6502, because I unfortunately don't have any experience there. But you're absolutely not going to get bare-metal performance inside of Pico-8.

You're right about limiting code-size, though. For my own project, the code size limits have proven far more difficult to work around than the performance limits.

Tangent now, but these are some of the Pico-8 limitations:

- screen is 128x128 pixels

- only 16 colors are available (sort of... there's a "hidden palette" too)

- cartridge size may not exceed 32 kb

- cartridge may not exceed 65k characters

- Lua AST may not exceed 8192 tokens

That last one has been the hardest constraint for me to manage, by far.

Anyway, Pico-8 is a ton of fun. Try it out if you're inclined :)