This was made for a college course. There are some known errors, probably a lot of unknown. I don't know if I would call it "complete," but it will still manage to kill some time!
1 comment
My character just moves... the concept was to have him break rides but the collisions are giving me trouble.
0 comments
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.
1 comment
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
11 comments
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.
2 comments
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 ^^"
2 comments
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?
17 comments
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/>
8 comments
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
memcpy(4096,24576,8192) |
to record the screen, and
memcpy(24576,4096,8192) |
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.
0 comments
Story
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™!
Instructions?
- 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.
2 comments
