I realize it's not applicable for all games, but would it be feasible to implement screen reader support for PICO-8? I don't know a lot about WAI-ARIA for web or anything about accessibility of standalone applications, so I don't know how such a thing is to be done, but we already have printh() commands sending data to the "@clip"board - adding something like "@tts" (text to speech) seems PICO-8-ish.

PICO-8 already does a lot of accessibility-positive things - the color palette includes a lot of nicely contrasting brightnesses and hues, the controls can already be remapped freely, carts can implement optional mouse and keyboard input - and setting up for speech reader integration would give programmers another way to make their carts playable by everyone.

Polymerase 1.0

by Gan_HOPE326

Cart #polymerase-0 | 2020-02-15 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

3

A game made for Trijam #57. You're a little enzyme, reconstructing a strand of DNA - remember, A goes with T, and C goes with G! Build the complementary of the strand using the pieces you have, and make sure no base reaches the top of the screen without its twin!

Controls:

Up/Down - Move cursor
Z - Place base
X - Discard base (move to next)

tweetbubblewrap

by sparr

Cart #tweetbubblewrap-1 | 2020-02-15 | Code ▽ | Embed ▽ | No License

5

My first tweetcart with sound. Pop all the bubble wrap, then start again!

poke(24365,1)s=stat::r::b={}::m::
flip()cls()for p=0,63 do(b[p]and circ or circfill)(p%8*16+8,flr(p/8)*16+8,7,p%15+1)end
if(s(34)>0 and not b[p])sfx(0)b[p]=1
if(#b>62)goto r
x=s(32)y=s(33)pset(x,y,6)p=flr(y/16)*8+flr(x/16)goto m
__sfx__
000400000e6453667528655126350b624

what do you guys think about a implicit conversion between bools a numbers being added?

it shouldn't hurt existing cartridges but would allow for something like this..

local axisy = btn(3)-btn(2)

normally you would need to write a num function that converts bools to numbers for something like this.

can someone explain to me how to get a sprites bounding box?

I have this code which reads from the center of a sprite and keeps checking above it until the pixel is 0 or its at the top of the sprite.

function boxt(s,x,y,w,h)
	local sx1=flr(s%16)*(w*8)
	local sy1=flr(s/16)*(h*8)
	local sx2=sx1+(w*8)
	local sy2=sy1+(h*8)
	local cx =4
	local cy =4

        //find 0 pixel or top
	while sget(sx1+cx,sy1+cy) != 0 or sy1+cy > sy1 do
		cy-=1
	end

	sspr(sx1,sy1,sx2-sx1,sy2-sy1,x+cx,y+cy)

	return cy+y
end

however it doesn't seem to work

local s,x,y=22,63,63
function _draw()
	cls(1)
	if(boxt(s,x,y,1,1) > 0) then
		y-=1
	end
	//spr(s,x-4,y-4)
end

bumble_bots_re_pair

by eriban

Cart #bumble_bots_re_pair-3 | 2020-05-23 | Code ▽ | Embed ▽ | No License

9

Bumble Bots Re-Pair is a difficult action puzzle game. In the game you need to re-unite (re-pair) bots by fixing the paths they traverse. Can you complete all ten levels?

Credits

The idea for this game was created during this year's Global Game Jam, where the theme was "repair". It's a spin-off of the Robo Re-Pair game that we created during the jam.

The music was created by my brother and first used in my original Bumble Bots game (Low Rez).

Tips

The tiles that you are offered are randomly selected. However, you will always be offered tiles that fit somewhere on the grid. Furthermore, the tiles on offer will be unique. The order in which you place tiles and where you place them therefore matters. Exploit this to increase the odds that you get favourable tiles.

[ Continue Reading.. ]

pushline

by voxeledphoton

Cart #pushline-0 | 2020-02-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

1

(EDIT BELOW) Added COMMENTS to help guide you through a little about what's going on.

pushline

by voxeledphoton

Cart #pushline-1 | 2020-02-16 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

1

------------------------------------------------------------------------
-- takes a string describing a map and the width of the map
-- other parameters reimplement map()
-- example "0123456789abcdef",4 represents this 4x2 map:
-- [[0x01,0x23,0x45,0x67],[0x89,0xab,0xcd,0xef]]
function mapstring(mapstr, mapw, celx, cely, sx, sy, celw, celh, layer)
 -- remove[] to save tokens by making parameters mandatory
 ms, celx, cely, sx, sy, celw, celh, layer =
 ms or "", celx or 0, cely or 0, sx or 0, sy or 0, celw or 1, celh or 1, layer or 0
 for y=cely, cely+celh-1 do
  for x=celx, celx+celw-1 do
   local sprnum = tonum("0x"..sub(mapstr,(y*mapw+x)*2+1,(y*mapw+x)*2+2))
   if sprnum>0 and band(layer, fget(sprnum))==layer then
    spr(sprnum, sx+(x-celx)*8, sy+(y-cely)*8)
   end
  end
 end
end

This might be useful for games that define a large number of small maps (like metroid or zelda screens).

This function uses bresenham's algorithm mirrored to the 8 octants, filtered by angle for the desired arc angles. It's so slow as to be useless; there are much better arc functions on the BBS already. I'm posting it for posterity and future reference, and because it inspired me to come up with a handy octant-range asin() approximation that might actually be useful

-- approximation of asin(d) for 0<=d<=.7071
-- exact at d==0, d==sin(1/16), d==sin(1/8)
-- max error .0021 at d==sin(3/32) in given range
-- error within that max beyond bounds up to d==sin(.137)
function delta2angle(d)
 return d * 0x.29cf + (d > 0x.61f8 and (d - 0x.61f8) * 0x.0785 or 0)
end

function arc(x, y, r, a1, a2, ...)
 a1 %= 1
 a2 %= 1
 if (a1 == a2) pset(x + r * cos(a1), y - r * sin(a1), ...) return
 a2 = a2 + (a1 > a2 and 1 or 0) -- ensure a2>a1
 dx, dy = r, 0
 while dy <= dx do
  a = delta2angle(dy / r)
  for flip_x = -1, 1, 2 do
   for flip_y = -1, 1, 2 do

[ [size=16][color=#ffaabb] [ Continue Reading.. ] [/color][/size] ](/bbs/?pid=73025#p)

Chromakey demo

by packbat

Cart #gipuwesuno-0 | 2020-02-12 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

2

We were fiddling with another project and realized that, because we were using sspr() to resize images, we didn't actually know where all the pixels were - and we wanted to know, because we wanted to cast a shadow that was the colors of what was below but in shadow. And we realized that PICO-8 lets you look at the screen in the code, and then the concept of green screen popped into our head, and then we got to work.

It's not minimized and it's not optimized - if you tell it to chromakey the whole screen, it'll chew through the entire CPU budget with change (ask us how we know!) - but I think it's readable enough that people can hack on it. We haven't tested it extensively, but we made sure it respected the current clipping rectangle and restored it before it exited, because that seemed like the correct thing to do.

[ Continue Reading.. ]

 x,y,w,h=64-10.75,64-10.25,20.5,20.5
 rectfill(x,y,x+w-1,y+h-1,8)
 clip(x,y,w,h)
 rectfill(x,y,x+w-1,y+h-1,11)
 circ(64,64,12,12)

Note that on the top and left the circle extends to the edge of the rect, as is expected since the rect was drawn to match the impending clip region. Note the extra row on the bottom, inside the original rectfill, outside the clipping rectangle.

I think this is a bug. At the very least, it's a place where the documentation needs to be clarified.

(the circle being off center is irrelevant)

I find after I look away from the editor, after using it for a while, I will have a blue bar shape burned into my retina.

I've used the config.txt gui settings but they seem to only change the body of the editor and not the bars at the top and the bottom.

Just wrote my first app that allows to draw like Jackson Pollock by using arrow keys and z/x keys to change the color from predefined palette.

pico_pollock

by alexdeplov

Cart #pico_pollock-0 | 2020-02-11 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Sometimes your cartridge fits in the token count, but not the characters count / compressed size, so you can't export it until you reduce the number of characters in the cartridge. You'd also like to keep comments, meaningful variable names and even debug code where you can, in case you're gonna continue working on the code.

One way to do this is to use a build pipeline:

• copy your source file(s) to an intermediate directory
• process file(s) to reduce code size
• output final cartridge

If you use picotool or work with compiled languages, you should be familiar with that process. It may sound a bit overkill for PICO-8, but is very useful if you're stuck in the case mentioned above.

This is what I do when working with my custom framework pico-boots, but while I don't think many devs would be interested in using a complete framework for PICO-8 written by somebody else, they may be interested in the individual processing steps described below. You can always refer to pico-boots' repository for implementation details.

[ Continue Reading.. ]