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.

deflektor

by slainte

Cart #deflektor-18 | 2020-08-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

7

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

CHANGELOG V0.5.2

• FIXED tutorial can be run multiple times

CHANGELOG V0.5.1

• FIXED bug duplicating player cursor entity...
• FIXEX tutorial scrambled if you play before running it

CHANGELOG V0.5

• Massive rewrite (almost 80% of it is new...)
• ADDED a few more levels
• REMOVED editor mode... it is now it's own cart... was too big
• ADDED Tutorial, Intro screen, proper game over and End Game sequence
• FIXED a few nasty reflection bugs for the laser beam

CHANGELOG V0.3.5

CHNAGELOG V0.3.1

CHANGELOG V0.3

CHANGELOG V0.2

CHANGELOG V0.1

PENDING

• MUSIC: title music from the original and maybe a bg loop while playing
• SOUNDS: laser connection sound
• VISUALS & GAMEPLAY:
  • live lost sequence
  • level transition
  • extra detail in end game sequence
  • gremlins from the original game... unsure if I will be adding those
  • a few more levels... the plan is get around 20-30 levels in place
• CODING: even if I refactored a lot, there's still quite some junk... could be I do some more

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:

1. Load PICOWARE (e.g. load #picoware)
2. Start story cart (any mode, any cart)
3. 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?

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/>

cart: https://www.lexaloffle.com/bbs/?tid=35018

Static Display

by dw817

Cart #wadesupuso-0 | 2019-08-10 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

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 !

Toast Fairy

by Smaft

Cart #toast_fairy-2 | 2019-08-10 | Code ▽ | Embed ▽ | No License

2

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.