Update: tweaked the cooldown
just a simple demonstration of the undocumented feature of stat(x)
using the demo musics of course
feel free to use it in your music carts :D

I'm not a lua expert, so I can be totally mistaken on this - please correct me if so.
I can't see any reason why a variable should be global in pico-8... Defining as a local outside any functions, makes it accessible from that file (or module? or what is the correct lua terminology for this?) and since pico-8 only has one code file, that is essentially makes it global.
And as far as I know locals are way faster in lua than globals.
So I suggest just removing the keyword, and making everything local by default.
If there is a reason for globals, I would still ask for local-by-default, and suggest introducing a "global" keyword - just to save on the code size.
Again, I don't know much about the inner workings of lua/pico-8, so just ignore this if it doesn't make any sense. :)

Update: Actually, why not go a bit further, and create a code viewer. Includes a custom font by me.
A quine is a non-empty computer program which takes no input and produces a copy of its own source code as its only output.
This achieved by having the program modify it's own source and re-launch via the "run" command.
Essentially it does this:
print([[ (original program source here) ]]) |

-- GOAL
Can you bring the wolf, the goat, the cabbage, the hunter, the gun, the monkey and the washing machine on the other side !?
-- RULES
- You can only get one of them in the boat at a time.
- You can hide one object in the washing machine.
- When you re not around your folks will interract this way :
you can learn these rules by playing or read them by clicking the 'show' button
I've been looking at a few carts and most of the closest to being actual games are right on the Lua code limit (but they have plenty of graphical / map space.) It seems that the real major limitation is the code size and not the sprite limit.
The code size limit is causing hard to read code and ugly shortcuts. I absolutely understand the reason for the limit, but I think it should be raised considering the code isn't compiled or compressed and a lot of carts have vast sprite spaces but no more code space. In most applications the code text doesn't cause any appreciable size increase. It's always the graphics and sound assets.
That said, I think there might be some interesting ways to fit more code in the size of that space but at what point does it circumvent the spirit of the Pico-8? Cutting variable names and comments doesn't make a game easier to write or eliminate design fatigue. It just makes it more difficult for difficulty's sake.
I'm not sure if the text size limit has anything to do with the .png cart format though.
One of the things I love about PICO-8 is the flexibility of input devices; I love that a keyboard is just emulating a virtual controller that has only 4 directional buttons and two other buttons, and that I can use any controller I want (thanks largely to SDL2). That combined with the cross-platformness makes the whole thing feel very inclusive and welcoming.
However, this presents a problem for in-game button prompts or manual text: what should the buttons be called? The directional buttons are pretty standard, but it's the other two buttons that present the biggest issue.
Depending on the input device, the two non-directional buttons could be called lots of different things:
| Keyboard | Z/X or N/M |
| Xbox 360 controller | A/B |
| PlayStation controller | cross/circle |
| etc. | etc. |

Got the controls sorted out, and redid how I store the block shapes. My original idea about a piece rotating about a point didn't match up with what Tetris did. Started playing around with animations a little bit. More to think about on that one.
Works on my machine - crashes here saying a syntax error on Line 12. Looks like some kind of preprocessing found a -- inside a string and tried to comment out the rest of the line.

Thought I'd start a thread for other azerty users documenting what works and doesn't, and let Zep knows he has at least one guinea pig handy for testing :D
So, what works:
- code input is mostly fine, keyboard is recognized in azerty mode with a few caveats
- "game mode" (when running cartridges) changes the input to qwerty (Z is remapped to W, Q to A...) which is actually cool since we get the same layout as qwerty users for playing.
What doesn't:
- accented vowels ("é","à","è"...). Those glyphs aren't available in pico-8 anyway afaik.
- several potentially useful glyphs: "&", "#","|","`","\","@","$",";". Those can be cut/pasted from a text editor.
- curly braces "{}" and square brackets "[]". Can be cut/pasted as well.
TL;DR: Pico-8 is mostly usable for AZERTY-using devs (as long as you don't mind a bit of copy/pasting), and you can play the games without issues.

While experimenting with translating some "Zelda - Link From The Past" tiles into pico, I noticed that a lot of sprites save memory by mirroring the left half to the right one.
While the API allows drawing sprites mirrored along the x-axis, the map editor only permits one tile direction.
Would it be possible to add the ability to mirror sprites to the map editor as well?

Because PICO-8's Lua has no standard library, there is no way to get the length of a string, which means there is no way to (dynamically) center (an arbitrary string of) text when printing (unless I'm missing something :)
It would be nice to have either a len() function to get a string's length, or a way to ask print() to center text.






2 comments












