So I finally had some time to play with Pico-8 yesterday, and wrote two tiny cartridges, and instead of spamming zep on Twitter I thought it would be more useful to post my thoughts here, in order of appearance.
-
Jelpi is a pretty impressive demo, i love everything about this handheld console that never existed :D
-
There should be a version of the manual that looks like a 90's devkit manual black & white hardcopy, with a serious layout like the devkit cost $10k. But this is a bootlegged copy of the manual, so it got xerox smudges, is not fully level and is obviously copied right out of a bound book, and right on the first page it says stuff like "FOR YOUR EYES ONLY. YOU ARE CONTRACTUALLY BOUND TO NOT DISCLOSE ANY INFO" etc. On the second page there's a pompous introductory text from the company founder that flaunts the pico-8's luxurious capabilities, telling you how you can be proud to be able to develop for this console and how it's lightyears ahead of the competition. The manual is not even a full copy, it seems like it's just the most important pages copied out; the pages are numbered like 110-112, 351, 430, with paragraphs that make reference to appendixes that don't exist ("see Appendix E for chipset layout").
-
It's obvious that this pico-8 firmware is the devkit, which starts with a prompt. I imagine a "consumer device" would boot right into the cartridges. :-)
-
First I thought Lua's numeric type had been downgraded to signed short, but then I realized it's actually fixed point 16bit for both integer and fractional part. Very cool.
-
I'd remove all references to Lua and give this language a different name, e.g. Picoscript or Picolua; otherwise I'd just expect everything to work the same way; it's sufficiently different, i think. Considering how all the commands are named, PicoBASIC seems most fitting.
- I thought that it would be more useful to arrange the palette in a way that makes the 4-bits more significant (e.g. LRGB), similar to how the default EGA color palette is arranged. In EGA, bit 3 effectively changes brightness (sort of) without altering hue, that allows for very easy lighting tricks. The numeric bits correspond to RGB, so you can fake additive light effects with simple bit twiddling. Here, i'd ultimately do it with a lookup table; I guess it's too late to change it anyway.

Hello!
This is the prototype version of:
---- The Aggressive Botany League ----
a local multiplayer plant based deathmatch
Plant seeds into walls to push your opponent into the ocean (or to squish him!)
--- Controls ---
-
Movement
Player1: arrows
Player2: EDSF -
Wall breaking:
Face a wall and press Z (player2: TAB) 3 times to break it - Plant seed:
Face a wall and press X (player2: Q) to plant a seed into it
There are 4 types of seed (green, yellow, red and black) each with a different effect
You can carry only one seed at a time
best played with 2-4 gamepads
enjoy!
A toy that pokes the sfx RAM full of random garbage and lets you play the results on multiple channels. It'll mostly sound like generic computer ambience from an old educational film.
The randomly generated sounds will be stored in the ROM on startup, so comment out the cstore() at the end of the _init() function if you want to save your sounds for posterity's sake.
Disabling a single channel should technically stop playback on that channel, but it occasionally won't. This might be due to the weird looping points that the program generates for each sfx.

Feature request: Have control-click act as right-click, to better support Macs with one-button mice.
There are two controls that use click and right-click to increase and decrease a number, namely sfx speed and music pattern selector. Macs usually come with one-button mice or trackpads, so right-click actions are often also available as control-click (hold Control, click). In 0.1.0 control-click acts as "fast increase" instead of "decrease." It'd be great if control-click were "decrease" in these cases.
I notice shift-click is also "fast increase," so there's no loss of a feature. Shift-control-click could be "fast decrease."
Thanks!
-- Dan
So I'm getting ready to make a new game, in which the player will be able to push other objects around in an AOE.
I have a table, ACTORS, which will hold all my actors; each one will have x/y coordinates.
So, to get everything within radius R of point X, Y:
function get_near(x,y,r)
for i in all(actors) do
--use some math to get the hypotenuse
vx=i.x-x --get the distance on X
vy=i.y-y --same for Y
--SOME TRIG GOES HERE
--Sorry, still a little fuzzy on my trig
if(result<r)then
add(list,i)
end
end
return list
end
|
Which would return a list containing...what, exactly? This is where I run into the problem.
If adding an item from one list to another copies the original to the new list, then I get a list of actors that's basically useless--I can't push them around, because if I do anything to list, it won't affect actors.
However, if adding an item from one list to another creates a pointer to the first list, then I'll be able to use this to conveniently push stuff within a certain distance.






16 comments














