As simple as the subject.
- Write a cart that uses btnp().
- Run the cart.
- Press and hold a button to see it repeats.
- Hit esc to stop the cart.
- Enter 'resume' to resume the cart.
- Press and hold a button and see if it fails.
(Either that or key repeat isn't supposed to be a thing with btnp() and it only works right after you resume.)
This code is sufficient to show it:
boops=0 function _update() if btnp()!=0 then boops+=1 print("boop #"..boops) end end
Note: tested on win64 version.
I've invested some time working on a demake for one of my favourite games from the 8-bit era, Deflektor (by Costa Panayi). Most of the gameplya is in place, currently working on the editor mode (it is there but not really functional, does not save or remove objects correctly... hope to have it working for next release)
Still early, single playable level that now can be played in a row...
- FIXED bug with negative angle reflections not causing overload
- ADDED some more basic FX
- EDITOR MODE early version (reqs. mouse)
- ADDED laser loading phase at start level/new live
- ADDED end level scoring
- WIP bgmusic (in the cart but not playing, unsure if it will stay)
- FIXED bug in map loading that made optical fiber to crash (main reason to re-release)
- ADDED some basic SFX
- FIXED optical fiber pair coloring
- some minor token salvaging and code clean-up
- FIXED extra greediness in beam capture at mirror centers causing odd reflexions
- FIXED color error on initial rise for the overload meter
- MASSIVE spr sorting to allow for a reasonable leveldata format
- Level is loaded from data (level info will live in 0x1000 to 0x1FFF unused shared map/spr space)
- Crude leveldata persister as a prototype for leveleditor mode (unsure if editor will be a separate cart)
- Optical fiber interaction
- Laser grid scatter interaction
- Level can be completed
- Interaction with the receiver (connected status to end level)
- Removed displaying laser point debugging
- FIXED metal wall reflexion failing for some situations
- Basic intro page
- Beam generation and reflection
- Player movement
- Mirror interaction and auto-rotation
- Beam interaction with mirrors, walls, mines and pods
- Full HUD control
- Crude live / energy / overload management
- Hardcoded level mapping
- More/Better sound effects
- Intro music
- EVOLVE Leveldata loading (intention is having it compressed in the MAP area outside the working level map)
- EVOLVE Level editor to create / save level data
- Tutorials for the intro screen
- Implement gremlins (enemies)
- Messaging (dialogs, etc)
- Remove a lot of debugging / tracing and dead code
- MASSIVE code cleanup and namespace reorganization
With the launch of PICOWARE, I got many reports from player saying they got a "communication error" when trying to play the minigames. This error was a fail-safe mechanism intended to avoid a situation, wherein someone tries to start a minigame cart in any other way than from the main cart.
The implementation is: on main cart load, zero out the "difficulty" save data. On subcart load, set the difficulty — it's guaranteed to be in range 1..15. In subcart, check if saved difficulty is 0 — if yes, stop the cart and display a message about a communication error.
Subcarts decide what mode/difficulty/minigame will be used based on the data received from the main cart, and so this is to enforce starting from the main cart. Furthermore, after a whole playthrough, subcarts are supposed to return to the main cart and inform it of the score. Can't imagine a situation when the player starts a minigame in a "single minigame" mode, then the subcart starts the whole story mode, and after finishing returns to the story cart which informs the player that they beat the whole stage.
As players started flooding in, I got reports saying they get the "communication error" during normal play. Different browsers, different operating systems, web and standalone, online and offline, and very unreliable. Further investigation showed that indeed — very rarely, with no noticable pattern — the save data in the subcart is zeroed out.
Nothing seems to have any effect on this bug: changed dset/dget to poke4/peek4, tried setting the data a few seconds before the load, still the bug hasn't disappeared. Tried reproducing this with a set of test carts using code below:
function _init() cartdata("foo_bar") -- set to a random number for i=1,10 do dset(0, rnd(-1)) end dset(0, 1337) load("b.p8.png", "breadcrumb") end
function _init() cartdata("foo_bar") -- should fail if dget(0) ~= 0 if dget(0) == 1337 then extcmd("go_back") return end cls() print(dget(0), 1, 1, 7) flip() repeat until false end
I've had this running non-stop for 10 minutes, and… nothing. This just works. I'm lost. This probably is influenced also by something else — PICOWARE cart is so dense (it seems to have broken the cart image somehow), maybe that could be a factor.
Here is a GIF of me reproducing the bug (PICO-8 standalone, offline cart):
And the steps to reproduce:
- Load PICOWARE (e.g. load #picoware)
- Start story cart (any mode, any cart)
- If cart was loaded and started correctly, go back using the breadcrumb menuitem and try again until bug occurs
Also, one thing I noticed personally — this never happened the other way around, that is when returning from a subcart. Although communication data in the subcart is set instantly right before returning, there never appears any problem with the main cart receiving this data — which, if happened, would appear as the main cart showing the title screen first instead of the cart view/score screen (cartdata is used for this too).
This seems like a very peculiar bug, nonetheless one that affected many PICOWARE players, and I'm lost trying to figure out the root of this.
EDIT: Additional updates in comments below.
I am coming back to Pico8 after a few month pause just to find that I still cannot fix a problem I have with my platformer project. I would appreciate any help on it.
what I have:
The camera follows a point offset from the character.
I achieved a rubberband effect with
v = (cam.aim-cam.p)*0.1 cam.p += v
where cam.aim is a vector with an offset from the players position vector and cam.p is the current camera position.
When using the parachute this is only true when the character has a certain distance form the camera position. Also there is a different behavior while the parachute is opening.
While the camera is totaly fine while running and jumping, it becomes jittery when the character is mid air and moving really slowly. That's because, I think, the camera cannot decide if it is one pixel away from it's destination or not.
Whatever I do .. It stays that way. or doesn't work at all ^^"
How can I force it to stay at it's destination position when moving really slow?
Has anyone got Pico-8 working on Raspberry Pi 4? Specifically under Raspbian Buster, console/terminal mode?
I've got it running in the Desktop, but there are graphics issues (tearing, non-smooth scrolling) so want to run it from the console. I have done this in the past on Pi 1/3, but am having trouble with the Pi 4...
Launching Pico-8 give me the following error:
SDL Error: Could not create EGL window surface ** FATAL ERROR: Unable to create window (SDL restoring keyboard) Segmentation fault
(pico8_dyn gives the same error)
Anyone know what I need to do?
I'm getting a text selection the web-player. It's not 100% per click, but fairly easy to reproduce (button-mashing does the trick)
Pico-8 version: 0.1.12C
Device: Sony Xperia Z5 Compact, Android 7.1.1, Chrome 76.0.3809.89
If you want to be able to record the screen and use it as a static image for your games, you can do so fairly easily as long as you don't need more than 128- 8x8 graphic characters and don't need the mapper space at all.
With this out of the way you can use
to record the screen, and
to recover the screen. See the source code for the cart above for the code to do so.
This is useful if you are doing more than just a few simple images that can be redrawn, especially if they are elements that are randomly placed. Using memcpy() will be a lot faster and not require you to use arrays to redraw everything exactly like it was. You might even be able to use this method in your current and future projects.
Now I remember QBasic had this good command called PCOPY() which would page copy any graphics you had up to 16-pages via a number 0-15 so it would be
. Perhaps in the future PICO-8 will have this ability ?
HOPE THIS HELPS !
There's a sinister secret that the toaster industry doesn't want you to know. Toaster technology is not what you think it is. There is, in fact, an enslaved fire magic-wielding fairy trapped inside each and every one. Obviously, most of them don't like it, but some of them do for some reason. This is the tale of one of the fairies that seems to enjoy what they do. Weird, I know. Welcome to the world of Toaster Fairy™!
- Fly around with the arrow keys
- Aim with the mouse
- Shoot fire with the left mouse button
- Toast the bread as evenly and perfectly as possible (without burning it!) for maximum points! Fairies use points to buy groceries and pay toaster rent.
- Beware of the live wire! toasters have live wires in them for security just in case anyone tries to infiltrate them with forks.
- There is a limited amount of time until the toast-making human gives up and eats crackers...
- Keep an eye on the clock icon in the top left corner. When it turns red and starts blinking...
- Hurry to the red lever on the bottom right and press the right mouse button to pop the toast!
- Please to emjoy!
Why not? The whole point of this game is toasting bread evenly for points. Toast points? No, just pointless points.
There's just one level and you either complete it by dying 3 times, running out of time, or pressing the red lever with mouse 2 at any time.
The BBS PICO-8 player is showing up blurry in Chrome on macOS.
This seems like it might be a bug with Chrome, not this site, but I'm posting it here just in case...
The other puzzling factor is that this started happening all of the sudden, without updating Chrome or anything, e.g. I had the same Chrome session running and at some point this started happening. I then tried restarting my computer and it's still happening.
A Workaround (as a user)
- Use "inspect element" on the canvas (e.g. push Option + Cmd + I, click the hover tool thing, and then click on the canvas)
- uncheck image-rendering: pixelated
- check it again
That fixes it for some reason :| It makes no sense, which makes me think it's Chrome's fault.
(EDIT: actually sometimes unchecking/checking that CSS rule makes the canvas start flickering like crazy...uggh)
- It works fine on the big TV player on the front page (in macOS Chrome)
- It works fine in HTML exports of carts (in macOS Chrome)
- It works fine in Firefox on macOS
- It works fine in Chrome on Linux
- It works fine in Chrome on Android
anyway this is lame and I hope it magically starts working again soon :p