I ran the Dank Tombs demo cart on my PocketCHIP to find it really grinds...almost to a halt. I know the cart is pushing limits technically and the PocketCHIP isn't for every game - as much as I bang the PocketCHIP drum, I get it.

However, through that brief discussion, I learned that the PocketCHIP doesn't/can't run Pico-8 at full speed...??

Totally sucks given that PocketCHIP really pushes Pico-8 hard. And double stinks because as more people get their hands on Pico-8 and make great, top shelf games (like Dank Tombs) the PocketCHIP won't be able to keep up.

I had plans to make a console for Pico-8 using the Next Thing Console Bundle or maybe try to roll my own with a Raspberry Pi or something...however, if the PocketCHIP can't run things at full speed, does that mean these other devices can't either?

I want to play Pico-8 on my TV instead of on my computer so my kid and I can play without having to be in the office all the time. I've seen a lot of others post Pi consoles and such, which look like a great little project, but I want to make sure things will run as they should, unlike the PocketCHIP apparently.

Any thoughts, insight or first-hand stories is appreciated.

Not sure if this helps. I saw your post and tried the Dank Tombs tech demo on my Pi 3. I ran the static library version of PICO-8, full screen in 1600x1200.
From the CPU meter in the game it mostly sat I'd say in the high 60% to low 70% range. maximum was about 93% when I took the player character off the top of the screen and the game was rendering long shadows.

@ImmortanJoe: stat(1) is only relative to pico8's virtual machine. on my phone it stays under 97% while running two or three times slower...

Related: what is the status of a native pico build for android? I would love to be able to play pico games on my GPD XD.

@ImmortanJoe - What's the static library version of Pico8? Is that different than the client I'm running in Windows?

I guess Dank Tombs is really unique in what it's doing. Even the 3D engines of PICO-8 are unlikely to be as demanding of raw Lua execution speed, limited more by the PICO-8's simulated fillrate.

As much as it pains me to say so, I wouldn't worry about going the Raspberry Pi route on account of a single game (even if it's mine). I'd bet 99% of PICO-8 titles will work flawlessly.

@ImmortanJoe: The CPU meter from stat(1) is useless when Lua itself is the bottleneck. What's more important for the OP, did the demo work smoothly?

It's not really Lua, it's the implementation, since it's running on a custom interpreter. LuaJIT, for example, supposedly has speeds that are actually comparable to native compiled binaries. I don't think we'll ever see PICO-8 moved to using LuaJIT though, unless zep wanted to either forego backward compatibility with his custom interpreter or hack backward compatibility into it (which would mean even every little quirk, and would be difficult). I think the best we can hope for is improved performance with the existing interpreter, but it's unlikely it'll ever rival native binaries in performance.

If the custom intepreter outputs normal Lua bytecode and then runs it, it doesn't sound too impossible to combine that with an existing JIT compiler. Not sure if that makes it impossible to count executed tokens to take care for the tokens per frame limits and so on. Or that if there's any real benefit except on the most limited platforms.

It would be very cool in any case!

wouldn't the easier thing be, tag the carts that don't run too good on a target with a certain flag ? somme little icon that says "needs a powerful desktop" .

@toto - That's a good idea. Like a "PocketCHIP Ready" type of label. Given the PocketCHIP's hype of Pico-8, probably a good idea.

Although I have some concerns with the overall organization/labeling on carts within the BBS anyway, that goes beyond just PocketCHIP worries. I know work is being done so hopefully sooner than later we'll see some changes.

hrm I was planning on purchasing a PocketCHIP primarily for Pico-8... so I guess uh, 'thanks' for the info.

on the other side, what non-desktop systems would be best? just go the raspberry pi route?