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). Your goal is to guide a laser to the receiver on each of the levels, access to it is blocked until you destroy all pods on the level. Laser overloads when it hits mines or if the emitter gets feedback.
HOW TO PLAY (you can go through this tutorial in the game itself)
CHANGELOG V0.5.5
- 1 MORE LEVEL (now totalling 8)
CHANGELOG V0.5.4
- 1 MORE LEVELS (now totalling 7)
CHANGELOG V0.5.3
- 2 MORE LEVELS (now totalling 6)
- ADDED safety pre-check so levels don't start on full-reflection or overload status
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.
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 ^^"
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?
Hello,
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
Screenshots:
cart: https://www.lexaloffle.com/bbs/?tid=34979
<br/>