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:
a.p8.png:
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 |
b.p8.png:
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.
3 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 ^^"
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?
emmmm,just a personal learning produce.
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/>
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.
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
PCOPY(orig,dest) |
. Perhaps in the future PICO-8 will have this ability ?
HOPE THIS HELPS !
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.
- 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?
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.
(version 76.0.3809.100)
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.
Screenshot
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)
More Info
- 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
Around 20 days ago, I dug back through my emails and found I had a code for Pico-8 after buying Voxatron years ago. Since those 20 days, I created three test games that I compiled into one small cartridge!
Game 1: Cavin!
A small game made following Gamedev fanzine by Dylan Bennett.. Still had fun making it, so I decided to include it in the rest.
Press up to jump! Don't hit the sides.
Game 2: Lunar Landar!
Another game created following a tutorial, but with some extra additions such as levels and a bit of animation. This is the game I will return to in the future to add meteors, explosions, and level progression!
Arrow keys to position landar. Land on the target, but don't hit it too fast!
Game 3: Smash Pilot
A game created by scratch (with a little bit of help from ladybenko's "hello world" called Space-8 and DR4IG's Parallaxing Stars Snippet) Made it in about two days, and had a lot of fun experimenting with shooting things!
Arrow keys to move, Z to switch weapon, and X to fire. Survive waves of enemies!
And just for fun:
I made a light reskinned pack that makes the whole cartridge look a bit scummier. Nothings new with the game, just the menu. Enjoy!
