I guess the PICO-8 has some kind of CPU limit, but it's orders of magnitude over the 8-bit 6502 consoles it's broadly mimicking. That was sort of disappointing to me.
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.
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.
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 :)
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.