Pichrome-8
I've made a Chrome Extension for discovering Pico-8 carts
Hi everyone,
as part of my Cs50x Harvard Course, I had to make a Final Project and I decided to create something about Pico-8 (which I love).
I always felt like there were so many games and that it would be cool to have a random picker that would let me discover carts.
I think a Chrome Extension is perfect for that: let you disctract from working or from boring webcam meetings!
Your next Pico-8 game is just one clik away into your browser! :)
Link to the Chrome Webstore page: Chromepie-8
Features:
- One click to the extension icon open a small card that automatically load a random carts from the first 500 featured one
- You can play usign standard keyboard keys or with mouse input (when supported by the carts)
- Click wherever out of the card to just stop the game and close the extension (Safe For Work!)
- If you like the game, click the download button to have easy access to the .png cart
--> It's my first piece of "software" ever released, so any suggestion on comment is appreciated!
Thank to Lexaloffle for making Pico-8.

When I go to view the source code for carts, I keep seeing "I=1" pop up, and I can't figure out what it is referring to. Also, I'm not really sure how functions for a variable are created. When the code is using If...Then...Else statements I can generally follow along, but looking at the functions they're assigned to I'm just very lost. To me, it just looks like random words and numbers strung together with no correlation. Thank you in advance, I'm really looking to learn :]





Here's some code:
poke(0x5f5e,0x11) --only enable bitplane 1 sset(0,0,15) --edit sprite 0 |
I would expect the sset() call to set the spritesheet's corner to color 1 (dark blue) because of the bitplane setting. However, this instead sets the corner to 15 (tan).
I can workaround this for now by using pset and then memcopying the screen to the spritesheet, but that means my decompression code (which wants to call sset with bitplanes active) will need to either take less than a frame to run, or show artifacts onscreen while it runs.


This game is a remix of the adventure game tutorial by @MBoffin.
About my game:
Collect axes and reach the goal.
To reach the goal, you must break the door. To break the door, you must get more than one axes.
Thank you for playing.
Collect all the chips! Move through series of mazes with the arrow keys and try to get to the finish as soon as possible. In Chip Rush, you have a 10 second time limit, and collecting one chip will give you a bit of extra time. But be careful, colliding with a wall will make you lose one second, and if you run out of time it's game over!
Screen fade effect from http://kometbomb.net/pico8/fadegen.html




.png)
Colour Walker
This cart was created as an experement at seeing if I can acomplish animated sprite movement, and to see if I could acomplish having the colour pallette change to the secret pallet on a special interaction with the player
Controls
arrow keys to move around, X to swap the colour that the player is standing on
Other
turns out the pal function is a silly billy pain in the butt! this was a real tricky one but im glad i completed this little idea c:
Credits
me! me! its all me!
follow me on twitter @caittastic_ i make lots of pixelart
.png)
Hi guys:
This is kinda embarrassing but I'm not 100% sure how ELSE works.
If an if condition is originally TRUE, does the ELSE say "Well I'll do this is it's FALSE"?
c="ORANGE"
IF c="ORANGE" then print "YES" (This is definitely true)
ELSE print "NO" (Somewhere in the code, c changes to APPLE)
But what about OR comparisons?
c="ORANGE"
IF c="PLUM" OR c="GRAPE" then then print "YES"
ELSE print "NO" (It does this line because c is NEITHER PLUM or GRAPE)
I think that's correct so far. But I get a bit stuck on ELSEIF
c="ORANGE" b="APPLE"
IF c="PLUM" OR c="GRAPE" then then print "YES"
ELSEIF b="APPLE" print "THIS LINE!"
Does the psudo code above confirm the fact that c is NOT PLUM or GRAPE but sees that b is APPLE so runs that and prints "THIS LINE!"




Someone on Twitter asked for this, and this seemed like the easiest place to share the code.
function preplace_in_circle(centerx,centery,radius,checkcol,newcol) local topleft={x=centerx-radius,y=centery-radius} local bottomright={x=centerx+radius,y=centery+radius} for x=topleft["x"],bottomright["x"] do for y=topleft["y"],bottomright["y"] do if (x-centerx)^2+(y-centery)^2<radius^2 then if (pget(x,y)==checkcol) pset(x,y,newcol) end end end end |
function psetin_circle(centerx,centery,radius,checkcol,col) local topleft={x=centerx-radius,y=centery-radius} [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=98594#p) |

I'm tying to build GOL on PICO-8, but the per-pixel manipulation is just too slow. Anything more than about 48x48 is unacceptably slow.
Initially I was reading/writing into temporary tables but that was really slow. This approach keeps all the state on the screen and in a sprite so there's about a quarter of the work from the table approach, but it's still slow.
I've started another experiment with peek4/poke4 but the coordinate wrapping is a total pain.

DOOMY (overdue Pico-1k jam)
DOOMY, a tiny first person shooter in 1024 bytes, with collision detection, arbitrary walls, texture w. fog, sound effects, a couple of baddies and a death screen πΉπΊπ₯
Controls & Goal
Move around with the Left, Right and Up arrow keys. Shoot with X or C.
You start with 10 health points, and need to shoot as many baddies until they get you good!
Inspiration
Seeing great and cute entries closing Pico-1k jam was inspiring. That's when I got an idea: "all things SSPR" to balance this cuteness with DOOMY pointless violence and big pixels.
Technical details
In a nutshell DOOMY is a rotozoom (the effect you get when rotating and zooming an image) laid down flat and rendered with scaled sprites.
Setup
The textures, sprites, and the base of the level are rendered as a group of rectfill and text in the first 3 lines of code, with first two textures of 8x8 for the walls, then 2 baddies, and finally the base of the level.
In the following 4 lines, the base of the level is expanded and some diagonal walls are added.
Every "thing" in DOOMY goes in the β₯ object which contains the x,y,t,w properties for the x,y position of the thing, it's texture index t and width w (nil or 1 for walls, 8 for the baddies)
Game loop
In the game loop the things in β₯ are rotated and moved into another object, π±, if they are in the visibility fustrum. The baddies move erratically towards the player.
The things in π± are then sorted and rendered back to front, if one of these thing is large, it means it's a baddy and we render a shadow with an ovalfill
Collisions and baddies hit
For the collision detection, we check the distance of the last thing we drew. Blocking the way forward if it's very close.
We check the color of the pixel under the crosshair to know if it's a baddy. If you shoot we play a noise, increase the score and respawn it at a random location. Otherwise there is a 10% chance it will shoot you with a red flash and some noise.
You know the baddies are bad because they keep shooting you even when you're down!
Source code
u=.2v=1.5a=0p=0h=10β₯={}r=rectfill f=add cls()r(0,0,15,7,13)f(β₯,{x=3,y=4,t=24,w=8})?"#%$3αΆ9μαΆ8] [ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=98580#p) |








Hello,
I have a problem with some code in version 0.2.3 that worked up to the previous version:
if stat(30) then local k = ord(stat(31)) end |
ord(stat(31)) always returns null but was returning the correct value before.
It works if changed to:
if stat(30) then local k = stat(31) k=ord(k) end |
The RoboZ

Hello,
while trying to compact code to save tokens I ran into an issue when trying to use split with strings containing escaped numbers \0, \1, etc.. (to store binary data that will be converted with ord()
s="abc\0def ghijkl"
split(s," ")
This seems to stop at \0 and the string part after " " will not be in the resulting table.
Is this intended behavior or a bug? With other escaped characters as \n \r \t the splitting works fine.
If this could be possible it would help me save additional tokens.
Thank you,
TheRoboZ



Ever wish PICO-8 had dual analog stick support? Me too, so I wrote Pinput. Pinput is a Lua library and suite of external helper apps to provide XInput-like gamepad support to PICO-8, without requiring binary patching. The library and helpers use the GPIO area of cartridge RAM to communicate, making Pinput a sort of virtual peripheral plugged into an imaginary expansion port. (The P8T Twitter client uses GPIO the same way.)
You can try it now if you have a gamepad that works with your browser. (You may want to test it first with this gamepad test page.)
Demo video:
What do you get?
- Up to 8 players



