Log In  

Just another mad coder.

We're all mad. I'm mad. You're mad, you must be - or you wouldn't have come here.

Find my books and biographical works HERE:

Cart #cc-0 | 2019-12-10 | Code ▽ | Embed ▽ | No License
TO LOAD THIS CART IN PICO-8, in immediate mode type:

load #ctc

UPDATE: Forgot to put in the changing wind direction, added now.

VVhat's new ?

LAST MINUTE ADDITION, Gruber the resident Pico-8 musician came through, was very kind to me, wrote to me on his page, and offered what I could use for my Christmas project here. How wonderful !

-- 12-08-19
-- + added changing wind
-- direction.

-- 12-09-19
-- + added 3d card opening
-- graphic. tricky stuff.

The music that I wrote I am keeping (the post after this one). It's a curious method to be sure where all notes are the same length and some are repeated in different octaves to maintain the flow of the song.

Who knows ? Perhaps in the future someone might be interested in this style of music. :)

This code is very reminiscent of what I wrote back in QBasic with a few exceptions. Back then I had access to 256-colors for the palette so I neatly encoded it all by only animating the palette I could have snow fall, glitter the 5-pointed star on the tree and of course turn off and on the ornaments/lights with 8-different colors.

You can also now press (O) to pause the music, and (X) to hide the text. Hit again to continue them.


Hope you like it, it's the best I can do for now. Have a great holiday season everyone !

P#70710 2019-12-08 21:55 ( Edited 2019-12-10 05:36)

Cart #sst-0 | 2019-11-28 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

TO LOAD THIS CART in Pico-8, type:

load #sst

Use the ARROW KEYS to navigate and the (O) key to flip back and forth between 2D stars and 3D stars.

Sphere Stars as I call them has always been something to elude me. While I spent literal months on and off years ago back in QBasic trying to reproduce the "bowl" effect, I was never entirely successful.

Thanks to @freds72 he showed me it is indeed possible to reproduce. And maybe that was the push I needed to try one more time using a method I knew would benefit me later.

What method is that you ask ?

I have remapped every single pixel on the screen to a circular bowl. So when you plot on the screen instead of a rectangle you are actually drawing in a bowl and you get that nice curved effect when you navigate around the 2D star array.

I first saw this animation on a NES cart called, "Star Voyager." I remember renting it at the time and being utterly fascinated with how the stars moved in it, even being late in returning it even though I had no idea how to play the game. :)


And now I have mastered it. So what's next ? Well since I finally have star movement code the way I want it I can start working on a good space-shooter game. I may even incorporate my HYPERSPACE effect as part of the game. :)


P#70319 2019-11-28 02:32 ( Edited 2019-11-28 02:46)

Cart #p8r-4 | 2019-11-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
TO LOAD THIS GAME in immediate mode, type out:

load #p8r

It seems a shame to leave ZEP's own marvelous JELPI sprites behind on just his opening demo cart, so I borrowed them for my latest game, Pico-8 Roadway !

Based upon the Atari 2600 game called FREEWAY:


To move the 1st player forward, press (O) or equivalent.

To move the 2nd player forward (if desired), press the 2nd player (O) key, usually TAB.

Uses my collision function:


Game saves CARTDATA high-score.

Note: if you have any suggestions or ideas on making improvements in this game, please let me know and chances are - it will happen. :)

P#70263 2019-11-27 01:25 ( Edited 2019-11-27 05:21)

Cart #ccm-0 | 2019-11-26 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

TO LOAD THIS CART in immediate mode type:

load #ccm

I have need of this function for a different game I'm working on - so you get a chance to enjoy and make use of it for your own projects.

Today most games in Pico-8 use what is called a HIT BOX to determine if there is a collision between two objects. And while it works fairly well it is not entirely accurate.

For instance, you could have a comparison between two completely different sprites and the hit box area would either be too big where a collision occurs even if they are not touching, or the hit box could be too small where you must run right up against the target and even though you are touching it, it does not register.

While this is good enough for most games, let's take a rare example of a game called VENTURE.

Venture was a challenging and interesting game in that the very pixels made it difficult to complete a level.

You would navigate WINKY your player around opponents and when you shot them while they did die, they also disappeared slowly one pixel at a time.

If the player were to touch any side of a live sprite or even a single dot of the dead one, comparing by pixels, that would defeat the player and they would have to start the level over.

And if you got yourself trapped in a narrow corridor waiting for an enemy's pixels to vanish enough so you could get around, this unstoppable skull comes after you - so it was the player's mission to grab the treasures from each room and leave as quickly as possible, trying not to shoot the opponents especially if they were blocking a door or exit.

Please enjoy this fairly complex function I wrote to do true pixel collisions.

To my knowledge no such routine exists for Pico-8 nor has anyone written one so it is indeed useful for pixel-accurate sprite collisions.

Two sprites are compared in the quickest way possible by determining both size and shape, including for instance a check between 15x4 and 20x18 if you so desire. Every pixel is checked and it does it the quickest way possible as well by determining which sprite is the smallest and largest.

The function itself uses several arguments:

-- sh1=spritesheet source x
-- sv1=spritesheet source y
-- sx1=spritesheet size x
-- sy1=spritesheet size y
-- ph1=screen position x
-- pv1=screen position y
-- sh2=spritesheet source x
-- sv2=spritesheet source y
-- sx2=spritesheet size x
-- sy2=spritesheet size y
-- ph2=screen position x
-- pv2=screen position y

In this demo code above, try going to the sprite sheet and changing the shapes of the sprites to see the collisions truly are being checked per pixel.


P#70253 2019-11-26 18:31 ( Edited 2019-11-26 23:29)

Cart #cs-0 | 2019-11-25 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

TO LOAD THIS CART in immediate mode type:

load #cs

Use the arrow keys to navigate between the 8-images stored. Press (O) to turn on and off the status.

  1. Santa Claus
  2. Rudolph
  3. Christmas Tree
  4. Jingle Bells
  5. Snowman
  6. Candy Canes
  7. Christmas Wreath (turned out nicely !)
  8. Gingerbread Man

Thought I would start a fresh tab for this new code. And there's quite a bit new about it.

While before you could guarantee a compression of 682-chars per picture, now it is based upon the cluster of pixels. So more black or white space means greater compression.

Also it no longer uses the Spritesheet even for temporary storage, it's all self-contained now.

Here is a slideshow using standard _init(), _update(), and _draw() to demonstrate it with the smallest picture being 438-chars and the largest being 592-chars.

And - I think this is as far as I can go in my coding with this particular method of picture compression. It was an interesting run, 2-weeks was it ? And I'm off to work on other things now.

P#70218 2019-11-25 18:31 ( Edited 2019-11-25 19:06)

You may yourself have experimented with the IMPORT ability for Pico-8 to import sprite sheets. However if you tried it inside your own code, it doesn't work, that is until your program ends.

So how can this be accomplished ?

Well first off understand the method I found only works for the IDE, that is, this will not work Online, offline Java or exported to an EXE/Mac. It only works in the IDE.

Here is the code:

-- the power of import
-- written by dw817 (11-24-19)

import "one.png"
if sget(3,3)==0 then

there are no sprites in this
program. what you see was
loaded from an external file.

for i=0,15 do

until forever

Save that as IMP.p8 if you like.

What's happening here ? It's pretty tricky actually. The first thing I do is import a .PNG file sized 8x8-pixels. Naturally it doesn't appear so the next line is TRUE, that is, the pixel at coordinates 3x3 on the sprite sheet is black. So then I RUN the program AGAIN.

At this point the IMPORT is added so the next statement is false. Then just run the rest of the code to show the sprite got loaded.

Here is a sprite to work with. Save it as ONE.PNG. Have it in the same directory as your IMP.p8 file.

Run the code and you will see it will import it after auto-executing it a 2nd time.

If you're content with this then you can indeed IMPORT any number of sprites, 256-at a pop per imported 128x128 pixels .png file if you like.

Perhaps in future Pico-8 you can indeed IMPORT or EXPORT any sprite sheet at any time without such methods, but this is not the case currently.


P#70195 2019-11-24 17:25 ( Edited 2019-11-24 18:16)


I was trying out the one of the BBS carts in the Leapdroid for Windows. While running a cart does indeed go full-screen and put a nice control interface for touch-screen which does work BTW, the game screen itself flickers from sharp pixels to blurry pixels very nastily and seemingly randomly back and forth.

This does not occur with any other APKs I've installed.

Something else to consider.

P#70168 2019-11-23 17:25 ( Edited 2019-11-23 21:32)

I can tell there are new changes in the Lexaloffle BBS by the appearance of this underneath carts now:

" Code ▽ | Embed ▽"

With the new images of the down facing triangles.

If you are editing your message (or any previous message you wrote) and preview and attempt to click play your cart from the message editor - it will not work.

You click on the right-facing Play Triangle in the center of your cart preview and it acts like you did not click at all.

This proven to exist now in Firefox, Opera, and Google Chrome browsers.

P#70117 2019-11-22 19:22 ( Edited 2019-11-23 04:28)

Cart #ha-1 | 2019-11-20 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Having been experimenting with compressing screens of pixels I was wondering if it were possible to write a compressor that returned the results of a dithered image. That is, where the output results would be difficult or impossible to compress effectively using standard methods of image compression.

And this is a 1st stage. Tomorrow if I have time I'll work on and post the 2nd stage. If it's successful it will also dither an image but in a third of the current compression space (less than 512-chars) yet still span the full screen.

For instance this particular image compresses from 16384-chars (raw image) to 1457-chars. Obviously it does not include all 16-colors and instead relies on a black and white table that is a size of 5. Five because I want to have both solid black and white in it.

Yet I think this is useful, especially if someone wants to include a large number of "clipart" images in their cart and for them to be dithered, perhaps for an adventure or mystery game that relies on many pictures.

P#70058 2019-11-20 05:05 ( Edited 2019-11-20 05:08)


As Tweets seem to be of interest, I thought I would share some shortcuts I have found over my time programming in Pico-8 which may save you vital characters to getting that desired 560-characters.

Let's look at some of the commands first:

Can be abbreviated as ? if first character on line

Not well-known will clear your variables and run your program again from the beginning.

Leaving out c and d will draw line from last drawn position using default color.

RECT(a,b,c,d) and RECTFILL(a,b,c,d)
Leaving out c and d will draw hollow or filled rectangle starting from coordinates 0,0, default color.

By itself will choose color 6.

Instead of creating tricky timers, just force your code to run at this FPS, can be higher than 60 too, 120 is possible !
Test that with this code:

for i=0,127 do
  for j=0,127 do

Can be abbreviated as T().

Use ::_:: and goto _ to GO TO a part of your code. Takes less space than REPEAT UNTIL false-condition.

if A==8 THEN A=0 END
Can be abbreviated:

To cut additional corners you can always cut spaces BEFORE any opening or AFTER ANY ending parenthesis ( ).

Likely there are other short-cuts of interest too. What are some you use to minimize your tweets with ?

P#70023 2019-11-18 19:43 ( Edited 2019-11-20 07:23)

Cart #hs-0 | 2019-11-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

TO LOAD THIS CART in immediate mode, type:

load #hs

Hyperspace or falling into a black hole. Whichever you think it might be. In any case, thought I would create a new post for this example. Earlier I was explaining some of the interesting things you can do with the PALETTE.

Here is a small example using all 15-colors of the 16-total. It uses the exact same principle you see as the snowflake animation found HERE:


So in the animation itself, no pixels are actually being drawn or moved. Only the palette is manipulated. Two per animation cycle at 30fps and likely using zero CPU if any at all despite how many sprites "appear" to be moving.

-- falling into a black hole
-- written by dw817 (11-15-19)

-- standard ⌂ pico-8 license

function main()-------------->>

for i=0,127,2 do


for i=1,15 do

until forever 


-- get random # from a to b
function rand(a,b)
  if (b==nil) return flr(rnd(a))
  if (a>b) a,b=b,a
  return a+flr(rnd(b-a+1))

-- draw a line from point to
-- point, starting with a
-- random color and stretching
-- it the further it travels.
function pline(a,b,c,d)
local px,py=c-a,d-b
local ax,ay=abs(px),abs(py)
  if ax>ay then py/=ax px=sgn(px) else px/=ay py=sgn(py) end
    a+=px b+=py
  until abs(a-c)<1 and abs(b-d)<1


Now imagine if Pico-8 could work with 256-colors for their palette instead of this simple 15 ? :)

P#69932 2019-11-15 23:35 ( Edited 2019-11-27 16:36)

Cart #gt-1 | 2019-11-15 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Wait a minute. Strike that.

Reverse it. Thank you.

Actually this should be titled, "A Tribute To Glowing."

Standard graphics on modern computers today do NOT have a palette. So - what exactly is the difference between graphics that use a palette and that which does not ?

Well generally one that does not means you have total freedom. That is if you can have 256-brightness levels for Red, Green, and Blue, why then you have a total of 16,777,216 colors available per pixel to you !

Nice indeed. So how does this differ from a system that uses a palette ?

well it all started years ago. Let's go back to QBasic for the IBM-pc which would let you have a choice. A 640x480 B&W pixeled screen, a single 320x240 256-color screen, or sixteen 320x240 16-color screens.

Let's go through each of these.

The 640x480 B&W is pretty easy to understand. You have high detail but can only use 2-colors, black and white. And while you can change the palette for each of them, it's not very useful.

Then we have the 320x240 256-palette screen. Let's cover this now.

In your graphics you can set a single number from 0-255 per pixel. This is NOT a true Red, Green, Blue representation as if it were you would only have up to 216-colors available as 6-levels of Red, Green, and Blue total 216. No, it's not that.

It's more an ID code stating that at this exact pixel location you want to plot the color that is from the original PALETTE table, zero usually being red zero green zero and blue zero and 255 being red 255 green 255 and blue 255. In this you could specify exactly which of the 16-million color choices you wanted to have appear for that single ID of a number from 0-255.

You choose the pixel to plot on the screen and THEN you can use POKE() to change what the color actually appears as, and then you can select any of the 16 million colors. So - how is this useful in animation ?

You can for instance make a water pattern using one color, increase that color by one and continue to draw in the same tile the water pattern were it to move. When you're done, using 8 or 16-colors or what have you, you CYCLE the palette. That is let's say you are using colors #1-8 to represent animated water.

Then color #1 would be the brightest color, white, then start to get darkest at #4 and start to get bright again at #8 but not as bright as #1. Then you rotate the palette like this:

1 2 3 4 5 6 7 8
2 3 4 5 6 7 8 1
3 4 5 6 7 8 1 2
4 5 6 7 8 1 2 3

And it would appear as if the water were MOVING, shifting from bright shades of blue to darker shades, all using only one graphic tile and 8-colors of your available 256 to create the animation effect.

The last QBasic mode gives you 16-screens to work with at 16-colors per screen at a resolution of 320x240. While you would use up half of your entire available list of colors if you tried to use 8 for water, you can do what I did here, which was to make color #15 cycle from black to red and back again.

As it is a single color and we are merely changing the color on how it appears, I included a few additional high-colors (>128) to give a nice animated glowing effect.

Here is the table for it, with the lowest # being black and highest being full red.

0, 1, 2, 3, 4, 3, 2, 1, 0

So after 4-machine cycles the red will be the brightest. The cycles after that it starts to get dark again, finally black, and repeating itself.

And this is not an uncommon programming and animation technique. Many Commodore Amiga demos and games used this color-method to animate. For instance let's try a different type of 8-color set. Let's say the first is white and the remaining 7 after it are black. This can be accomplished with the current code for the cart above. In the sourcecode, change MODE to zero instead of one.

1 0 0 0 0 0 0 0
0 1 0 0 0 0 0 0
0 0 1 0 0 0 0 0
0 0 0 1 0 0 0 0


In this you could have rain coming down from a black sky, flittering snow, or show complex movement like gears, electricity, or anything else that would use a black background and has 8-animations included into it by using each animation step per color used.

Heck I remember years ago I wrote a program called "Seaweed." In it, it drew water, bubbles, and the seaweed both above and below the screen.

Then the actual program only cycled the colors. The water moved, the bubbles churned from the bottom to the top and the seaweed shimmered and seemed to move as brightness layers were both added to and removed from it. All entirely by cycling a palette. No pixels were plotted nor were any moved or shifted. Just - changing the palette.

I did this for a hyperspace effect too, using all 255-colors in this case for the star patterns.

Now if Pico-8 ever does go 256-colors where you can change the palette for each, I could easily write code to demonstrate these advanced animation methods.

As it is we are limited to 16 but you can definitely see how changing one color gives it a glow effect. And you can use that single color on any other tile you draw. With the code provided it will always pulse from black to red and black again.

Same with the 8-colors for the "snow" effect. Have one of those colors lit all the time with the others black or dark and you will get the movement effect.


P#69928 2019-11-15 20:50

Cart #hg-6 | 2019-11-12 | Code ▽ | Embed ▽ | No License

Hold (O) to see the cycle of life.
TO LOAD THIS CART in immediate mode type:

load #hg

While the cart I'm working on now (and have been for several days) is quite a bit bigger than 560-bytes (hundreds of lines), seeing Conway's life program reiterated reminded me of my Father.

For years ago he wrote a program in Turbo Pascal he called the "Cycle Of Life."

In it, he had 3-different colored pixels randomly appearing on the screen in a 640x480 screen.

He told me that one pixel chases the other and the last chases the first. I really didn't understand him so he explained it to me.

Red chases yellow.
Yellow chases green.
Green chases red.

I thought about it for a-while and thought that was a pretty nifty thing. He later went on to make a very complex program he simply called, "LIFE." where there were gray dots all moving on the screen. If one got boxed in though he would turn red and start killing the gray.

If enough people saw red dots (bodies), they would take it upon themselves to become a policeman (turning blue), and running into the killer would apprehend him. (turning him into a white pixel), imprisonment my Dad said. Where he could not move from that spot but could still be seen by other citizens.

Then if they moved for a long time without finding any killers (red dots), they would revert back to gray (citizen) and the life program would continue, although the prisoner would remain.

At the time I thought it was a very complex thing and really beyond what I could code.

But I did understand the earlier program he wrote where 3-colors chased each other.

Thinking to the chess game, the foxes and the geese, I thought it would be interesting to change it from colored dots to actual pictures. Where red was the fox, yellow was not geese but rabbits as I liked drawing rabbit icons back then (S1), and the green was the grass.

So the new cycle of life was:
Foxes eat rabbits.
Rabbits eat grass.
Grass eats foxes.

When I wrote this back in QBasic so many years ago, someone questioned how the grass could eat the foxes. A valid question !

I told them that the foxes were carnivorous and grass means no meat, so they die out if it encroached on their territory. Ah, a good enough answer for the time I thought. :D

And thus is what you have here, tweetable, meaning it is 560-characters or less.

I think it demonstrates an interesting idea that is quite a bit different than "Conway's" game of life.

It also includes the sprites for the grass, foxes, and rabbits, as part of the source-code so it runs right out of the box ! I call it, "The Hunting Grounds."

Here is the source-code, exactly at 560-chars.

-- hunting grounds
-- written by dw817 (11-12-19)
for i=0,167 do sset(i%24+8,i/24,"0x"..sub(s,i+1,i+1))end
for i=0,224 do mset(i%15,i/15,r(3)+1)end
if m(h,v)==e[w]then n(h,v,w)end
c=(c+1)%32if c==31 then cls()map(0,0,4,4,15,15)repeat flip()until btn(4)end until z

Hold down the (O) key and watch the CYCLE OF LIFE ...

VVhat's going on ?

Random foxes, rabbits, and grass are drawn first on the playfield.

A random position is chosen.

A random direction is chosen. One of up, down, left, or right.

If that random spot can "eat" in that single direction chosen, it will convert that food to the same identity as itself thereby "spawning."

Then the cycle is repeated.


  • The foxes will win if the rabbits eat all the grass.
    [Predator] Foxes
    [Food] Rabbits


  • The rabbits will win if the grass manages to push out all the foxes.
    [Predator] Rabbits
    [Food] Grass


  • The grass will win if the foxes eat all the rabbits.
    [Predator] Grass
    [Food] Foxes (They encroach on their area and drive them out).

And WHO WILL WIN ? Will it be the foxes, the rabbits, or the grass ?
It is entirely possible for one to fill the field entirely.

P#69852 2019-11-12 20:31 ( Edited 2019-11-13 02:05)


You may have seen a few carts show impossible logos both in the BBS and in Splore. Impossible in the fact that you scan both code and memory to see where the logo is but it's nowhere to be found.

So - just how did they get that logo on there in the first place ?

Well, with a little bit of trickery, actually. You can do the same thing in truth.

Load up your cart. In immediate mode type:

export spr.png

to export your tiles to a temporary file.

Then type:

import logo.png

The 128x128 logo that you want.

At the bottom of your code or the first lines in _init() add:

repeat until forever

Run that. when the logo appears, press F7 to save that as the logo for your cart.
Press [ESC] to exit.

Then return back to your code, remove those two lines of code and back in immediate mode type:

import spr.png

To recover your original sprites, and you are done.

Save your program if you like and of course to export to the BBS use either SAVE "@CLIP" or save your program as a .PNG, and you are done.

When a preview of your game appears, it will show the logo you imported that for both the code and images that are no longer there.


P#69767 2019-11-09 23:52 ( Edited 2019-11-10 02:15)

Cart #sa-0 | 2019-11-05 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

To load this program in Pico-8, type:

load #sa

Shuffling a deck of cards on a computer has come a long way, hasn't it ?

The classic method is to go through each card one at a time and shuffle them by taking the index card and swapping it with a random card anywhere in the deck.

The problem with this method is that after a shuffle if the first card is say 2 of Spades, then you already know the next card will be Ace of Spades. So, yeah, it's not perfect.

Another way is to create a table picking a random number from 0-51 adding it to an array until the deck is filled. This will work but it can be slow once it gets near the end picking that random number from 0-51 to get that very last card that is not in the deck.

Thus future coding now has two interesting commands, ADD and DEL.

Add will do just that, add a value on to an existing array placing it right at the end. If it's the first item, obviously it goes in the first place. But each new successive item is placed on the end. So if you wrote code like this:


Then a would be an array starting with index 1 and contain 1, 2, and 3.

Now here is where DEL comes in and it's quite powerful what it does. In older code if we wanted to remove an item from an array you would have to create a reverse FOR/NEXT loop to copy all the older items one step above the item you were removing. I did this back in S2 and it was not speedy.

However, you do not need to do this in Pico-8, for instance, let's take our original code and remove the middle item:


Now the results are 1, 3. So with this in mind it does indeed ADD and DELETE items from the array. Doing so we can now make a proper SHUFFLE routine, where every single item in the array can be plucked out randomly, added to a separate array with ADD and neatly sealed closed from the original array with the DEL command.

And it does not swap existing items but actually pulls out each and every single item randomly to be placed in a 2nd growing array.

That is exactly what I am doing in this code, note two functions of use. SHUFFLE() which can shuffle a numeric or string array of any size as well as a function just for this code called PLOTCARD() which draws a small playing card on the screen.

Combining these functions you get a very good card shuffling routine that needs only one pass to make a perfect and completely random shuffle of a deck of cards, using our friend commands, ADD and DEL.

P#69671 2019-11-05 21:42 ( Edited 2019-11-05 22:35)

Was just experimenting with arrays, starting to understand NEW and DEL a little better, when I came across this:

for i=1,6 do

What gives ? The correct answers should be "3."

Normal BASIC with "newset=set" would just copy the array to a new array and let you work with it as a new array. You can't do this in Pico-8 as apparently it's just a shortcut to the original array ?

Is there a way to copy one array to another easily ? Like newset=set{} or something ?

P#69666 2019-11-05 20:27 ( Edited 2019-11-05 20:29)

Cart #dx-4 | 2019-11-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

To load this cart in Pico-8, type:

load #dx

VVhat's new ?

  • Added visible footprints so you can see where you've been.
  • Now does not show maze-drawing process.
  • Fixed up sprites a bit.
  • Am researching recursion as a possible maze-maker.

There are 2-ways you can navigate this maze.

  1. Just using your footprints as a guide.
  2. Press (X) to turn on the auto-mapper and use that as a guide.

This is not so much a game (although you can play it) as a proof of concept.

Something I've wanted to do is have code that automatically builds a fairly large dungeon, in this case 125x125 tiles is a fine testing area and build a maze that cuts the edge of the walls intelligently leaving space for the player to move around, so the corridors are not 1x1 tile in size but actually 3x3 floor space and 2x2 walls.

When you start getting down to having a regular sized dungeon you'll find that the mapper space provided really isn't very big, a maximum of 128x64 and that's only if you sacrifice some of your sprite space for it.

What better way to use the mapper then to create an array for what you need in the map, in this case 125x125 and then draw only the bits you need to the mapper and then just use the MAP() command for that particular area only.

Then intelligently draw black edges around the walls to separate them from the floor, something the default Pico-8 mapper cannot yet do but is included in this code.

Then you get to explore using the arrow keys. Hold two arrow keys to travel a bip-bopping diagonal.

Hold (O) to run instead of walk, and tap (X) to bring up a map of where you've traveled so far or again to hide it so you can focus on the full display.

Your mission is a fairly easy one. Locate the nice cottage in the center of the dungeon and touch it to complete the quest. Know well though that from where you start, there is only one guaranteed path to reach it. And that path is randomized every single time you start a new game.

Also includes torches that flicker, view the code to see how it's done.

Also see unique code of:

  • Constants, _1=true, _0=false.
  • Correct sgn() function where 0 returns 0.
  • Range function where a number is checked to be within a range and returns true if it is.
  • Good generate random number within set range. Negative number ranges are also acceptable.
P#69643 2019-11-04 23:22 ( Edited 2019-11-24 18:18)

I was just watching a video about Loot Boxes and how Online games charge players real money in order to gain these items, which apparently are random items that can benefit the player to progress further in them.

Outlawed in several countries apparently.


And this is new stuff for me, the first I've heard of it. I know, now you can think on that a bit if you like. Sometimes I get so wrapped up in coding I'm unaware of the world around me.

However, I was thinking this might be something good and nice to have for Pico-8.

Not real loot boxes, not the ones that cost money anyways. But no, perhaps missions a player could go on in some of these advanced Pico-8 carts. The reward ? A loot box, completely free, earned by the dedication (and perhaps perspiration) of the player to go beyond the call of duty on side-quests and other items that the average player may skip over in their haste to see the ending to the game.

It's something to consider, and would definitely be icing on the cake of very fine and excellent Pico-8 carts already produced and written or in the process of being written.

There was something existing like this with the Gacha game by the very talented, @enargy.


And while it's grand fun, unfortunately that's all it was, a bit of a loot box. Where you get a new card every hour or so but no actual gameplay otherwise to earn them.

I think this could be worked into games where you play, you work at it real hard, and congrats, you finally won the game. But that's not the end of it. As you went through the game you did not see all the secret paths and secret doors that opened up the rest of the game. Or perhaps you saw them but could not access them. Playing and winning the game might get you 25% of finding everything in the game.

It's up to you to play multiple times to find every and all secrets.

And of course for locating one or more of these hard-to-find secrets, you are rewarded with ? A Loot Box.

The Loot Box might have items that let the player jump higher to access areas they could not when they went through the first pass on the game. Perhaps swimming gear so they can finally dive in the water and not drown. Special boots to let them cross hot lava. Special weapons and/or armor, new playable characters, new NPCs to meet, new story paths to follow, you name it.

It could open up paths previously locked but now could be opened since the player has the matching key.

It could have collectable sprites that you can bring up to put on a shelf to view them in detail (with accompanying description) later. I think Brave Fencer Musashi has this ability.


Just like we collect prizes from Cracker Jack or a cereal box, they are collectable.

The Loot Box would have something in it, whether it's a platformer, racer, shooter, fighter, battler, RPG, puzzle, whatever it might be. It might have something in it that would help the player and encourage them to play your game "Just one more time" so they can explore that new area they couldn't earlier.

What are your thoughts ? And are there any existing Pico-8 games that do in fact have Loot Box prizes for outstanding ability or perseverance in gameplay ?

P#69573 2019-11-01 22:27 ( Edited 2019-11-02 18:04)

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

TO LOAD THIS CART, type the following in immediate mode:

load #dt

You've probably seen some pretty amazing things in graphic demos done for Pico-8, none to me more satisfying than the dither effect I've seen between two colors, where one side of the screen is black, the other white, and a complex and beautiful pattern between both showing a kind of fade ability using only the same-color pixels.

The fill pattern is by @Megus, and you can find his demoscene cart HERE:


Now while he and his crew have made an amazing demo, this tutorial and focus will be only on the dither technique used to create a division between two-colors. While it looks great on 3-dimensional models, it is also quite a thing of beauty to appear even on the screen just by itself.

So, exactly how is this being done ? And why is dithering an important element in graphics ?

First off, Pico-8 has an ability to "shade" pixels automatically with the FILLP() command, so that is how it is being done. Why is it important ? They give the illusion of varying degrees of shade between two colors. Let's take this picture for instance:

Now let's first off convert it to Pico-8's palette:

Obviously it loses some of its quality. But what about this ? Where the picture is comprised of only two colors, black and white ?

While you can adjust the brightness to show more detail, you are still limited to the lost pieces that are too dark or too light to show.

So, how can dithering help this ? Let's see a few. Here is a dither using what is called, ORDERED. It's good, fast, certainly better than straight out B&W, but could be improved upon.

In fact improving this default has always been a bit of a science and artistic thing. Perhaps the most common and popular is the Floyd-Steinburg method thus:

A dramatic improvement. You can find more about this favored method of converting multi-color pictures to a smaller palette, or even just B&W as seen HERE:


For further research there is also the Burkes and Stucki method, both included on this page:



But now let's get back to the code here.

What this does is create an array that holds 16-numbers. The dither table itself is stored in Sprites comprised of 4 8x8-pixeled sprites altogether. 8 4x4 patterns across at the top, and 8-more 4x4 patterns at the bottom, yielding 16 in all.

Each of them represent a "winking out" of each of the 4x4 pixels, where the BLUE pixel represents the pixel being added to the total "wink outs" so you can easily track them, or even develop your own. The background colors are there for a guide only.


The current selection of pixels and which are added at what position are done SO in such a precise and perfect way that when spread across the screen, creates a beautiful dithering effect. Which of course can be used to render 3-dimensional objects in Pico-8 with varying degrees of shades to emulate the lack of hardware colors inherent to Pico-8, or can be used simply to create a nice transition between two colors.

See the sourcecode for more details, chock full of remarks on how to code and write your own rectangular dithers and to fully understand the command FILLP(). Thus ends the tutorial.


P#69408 2019-10-28 20:00 ( Edited 2019-10-28 21:11)

Cart #nine_keys-3 | 2019-10-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

TO LOAD THIS in Pico-8 type:

load #nine_keys

I am not at all certain if Pico-8 runs 100% correctly on Android and cellphones. I would like to think that if it is not, that @zep is certainly doing his level best to ensure that it can.

This program is fairly simple but opens up input, especially for a touchscreen Android and touchscreen cellphone.

I had originally worked this into a complex cellphone driven programming language earlier with 15 buttons in a 5x3 format, but the language is cumbersome, slow, and not at all user-friendly.

So I have put it here. You can test it with the mouse if you like.

6 buttons are already active.

  • Press the middle up for UP.
  • Press the middle left for LEFT.
  • Press the middle right for RIGHT.
  • Press the middle bottom for DOWN.
  • Press the top-left for INCREASE FOLLOWERS.
  • Press the top-right for DECREASE FOLLOWERS.

Press (X) by itself to swap between showing the nine buttons or hiding them.

And of course this program is using standard _init(), _draw(), and _update() chock full of remarks to guide you. So you can reconfigure all 9 of these buttons for your use and their definitions and actions.


P#69369 2019-10-27 20:49 ( Edited 2019-10-28 04:21)

View Older Posts
Follow Lexaloffle:        
Generated 2019-12-10 18:55 | 0.165s | 2097k | Q:204