Log In  
[New PICO-8 Feature] Enabling more than 16 colors on the screen
by BoneVolt
Custom font: sitelen pona
by rnd

Cart #tetris_1k-6 | 2021-09-28 | Code ▽ | Embed ▽ | No License

Version 1.01: Fixed glitch, improved game over screen, corrected next piece preview orientation

This is basically a full game of Tetris in 1024 characters, featuring:

  • Sprite Graphics

  • Next Piece Preview

  • Score System

  • Left/Right Piece Rotation

  • Pieces can be slotted in under ledges

  • Title Screen

  • Game Over State/Restart


L/R-------Move Piece

O---------Rotate Counterclockwise

X---------Rotate Clockwise

Down---Soft Drop

This is an upgrade of my previous Tweettweetjam version of Tetris, and I was able to add a lot of things due to the extra space. A few things that I wanted to include wouldn't fit, like sound effects, level selection, and a fancier title screen, but this has graphics, solid mechanics, and a full game loop. The scoring system is based on the one in the Game Boy version, but with points only given when lines are cleared, and values divided by 10 to fit in Pico-8's 32,767 maximum. Hope you enjoy playing it!

P#97486 2021-09-18 11:14 ( Edited 2021-09-28 16:42)

I'm currently working on a tutorial for fitting sprite graphics into tweetcarts (https://www.lexaloffle.com/bbs/?tid=44375), but I've run into a problem. I have a lot of text to upload, but the BBS seems to be putting arbitrary limits on how much I can fit into a post, and it's very frustrating.

I'm already stretching the tutorial into multiple posts because for some reason it won't let me add any more text to the intial post, but now it won't even let me upload a reasonably-sized bit of code into a post by itself. I put a similarly-sized chunk of code into the previous post, but in the next one I can only post about 60% of that amount. Any more and the little loading animation just endlessly loops and nothing gets uploaded. If anyone can help me out with this, I'd really appreciate it.

P#96520 2021-08-27 07:15 ( Edited 2021-08-28 13:16)

Since getting into Pico-8 last year, I've enjoyed finding ways to optimize my code and fit a lot in a small space, and this has included making Tweetcarts. Recently, I've found ways to cram detailed sprite graphics into a tweet and have made various animated demos like these:

::_::cls()k=ˇ\2%5memset(26624,204,5^5)n=0for i=1,86do
v=ord("cS2C2Cr232$R$31b1CES2Kc32cKc2#2cK2S2c3K2C2c32KcC23nNfffff6%6565&E&%'575g'%ggggggggggg'",i)-35for j=0,v\16do
sset(n%8,n\8,v)n+=1end z=i%2sspr(0,z*(k*2+6),8,6-z*4,60,65-k\3+z*6)spr(32,i*8-ˇ%8-8,73,1,2)end
ˇ+=1flip()goto _
pal({-4,-5,15},1)::_::cls()for n=1,380do
ˇ+=.5flip()goto _
k=139pal(5,k,1)o=ord::_::cls()for i=0,509do v=o(";C$);C$);C$);C#%+C#%;D$);C$2?D$)?L$2;C$2=S$1[S$A;C$);O(1;C&A/^%//T'#ES&,*&#;737####/+",i\6+1)-35sset(i%40,i\40,o("4?;;333",v\2^(i%6)%2*(i+120)\80))rectfill(0,i*8,k,i*8+7,o('55555::9',i-3))end
spr(ˇ\3%5,ˇ%k-8,64,1,2)ˇ+=1flip()goto _

People have shown interest in learning my techniques, so I decided to make this tutorial. The ideas here could come in handy for tweetcarts, entries for TweetTweetJam or the upcoming 1K Jam, or just fitting more into a regular cart.

Fitting sprite data into strings

In order to fit as much information as we can into a few characters, we'll need to use data strings with the largest possible range of of values, and therefore the largest range of symbols from Pico-8's character set.

Here's a picture from my CHR Printer tool to illustrate (characters 0-15 aren't pictured, as P8SCII control codes and other factors make using them problematic). Of the remaining characters, 34, and 92 cause errors and are shown in red, those which count as two chars on Twitter are shown in blue, and those that count as one are in white. This means the optimum range is the span of 92 characters from 35 (#) to 126 (~). #92 (backslash) can cause errors, but there are a couple simple ways to deal with that which we'll get to later.

Important: if you're not actually going to post your code to Twitter, you can use all the characters that come after the white ones, giving you 221 to work with.

Really important: Since the range of characters we'll be using includes those for Pico-8's Puny Font, Pico-8 must be put into "puny font mode" by pressing ctrl+p before pasting your data strings into it, and you must be in puny font mode when copying from Pico-8 to paste into a tweet. I've had errors pop up many times because I forgot to do this. o_O

Anyway, to turn our string into values, we'll use Pico-8's ord() function, and since the characters we can use start at #35, we'll need to correct for this by adding 35 when encoding. When decoding, we'll subtract 35, like this: value = ord(string,character)-35

Now we can find the maximum number of pixels that each string character can hold. So far I've used two different methods for encoding pixels into characters: directly encoding values for a number of pixels, or a simple version of Run Length Encoding (RLE). RLE is more efficient for sprites with lots of single-color spans, while direct encoding is better for more detailed graphics. For both types, there's a tradeoff between range of possible colors and how many pixels can be encoded within our character range. Here are some examples of different combinations:

Direct pixel encoding (92 possible characters)

6 2-color pixels (2^6=64)
3 4-color pixels (4^3=64)
2 9-color pixels (9^2=81)
1 16-color pixel (16^1=16)

Run-Length Encoding (92 possible characters)

1-46 2-color pixels (2x46=92)
1-23 4-color pixels (4x23=92)
1-10 9-color pixels (9x10=90)
1-5 16-color pixels (16x5=80)

Decoding strings

Once we've encoded our strings, we need to decode them back into images. The most straightforward method would use a few nested loops-- two outer loops for horizontal and vertical position, and an inner loop to iterate through the pixel values described by each character. It would take up a large chunk of a tweet just for these loops, though, so we've got to condense things. Fortunately, we can do this using math, specifically the floor divide () and modulo (%) operators. The modulo operator lets us loop through a specific range of values, while floor divison lets us switch to a new value at a specific point. Used together, these can have all kinds of non-linear effects and replace various conditional logic. Here, index_variable%width gives horizontal position and index_variable\width gives vertical position, and the operators are also used along with ^ to iterate through the color values in a single character for per-pixel decoding, or without to separate the color and run length values for an RLE decoder. In both cases, v equals the value derived from each character of the data string (represented by empty double quotes).

Here's the basic setup for a direct pixel decoder, where:

w = image width in pixels
h = image height in pixels
p = pixels stored per character
c = possible colors per pixel

for i=0,(w*h-1)do v=ord("",i\p+1)-35sset(i%w,i\w,v\c^(i%p)%c)end

The expression v\c^(i%p)%c, which I guess I'll call the pixel value, is where v, the value of each character, is separated out into its component values for each pixel. For instance, if there are 4 possible colors, the value for each pixel will be found by separating out the multiples of 4^0, 4^1, and 4^2,-- AKA 1,4, and 16.

And here's the basic setup for an RLE decoder, where:

t = total characters in string
w = image width in pixels
c = possible colors per pixel

k=0for i=1,t do v=ord("",i)-35for j=0,v\c do sset(k%w,k\w,v%c)k+=1end end

Here, the run length is stored as a multiple of the total number of possible colors, and the desired color is added to that value. At decoding, we get the pixel value v%c by using modulo, and the run length by using floor division. An inner 'for' loop then sets the specified number of pixels to the correct color.

Encoding sprites

Now we need some encoders to build strings for our decoders. The following two encoders work by scanning the top left portion of the spritesheet left to right and top to bottom, and storing either direct pixel values or color and length values in each character. They also automatically determine the largest color value present, and use that to determine how many pixels can be contained in each character. Since color 0 (transparent) is used, the total number of colors will be 1 greater than the highest color value, so if color 9 is used, there are 10 potential colors. If you aren't posting to Twitter and want to use the most possible characters, set the 'value_range' variable to 221.

Direct pixel encoder

for i=0,width*height-1 do
while colors^(i+1)<value_range do
while i<width*height do
 for j=0,pixels-1 do
 if(val==57) val=-2

?'string pasted to clipboard',12,60,11
?colors..' colors/pixel',36,68,13
?pixels..' pixels/character',28,76
?#str..' characters total',24,84,6

RLE encoder

for i=0,width*height-1 do
 local n,len=0,0
 while n<width*height do
  local val,nxtval=sget(n%width,n\width),sget((n+1)%width,(n+1)\width)
  if nxtval==val and len<(max_span-1) then
   if(v==57) v=-2
  end n+=1

?'string posted to clipboard',12,60,11
?colors..' colors/pixel',36,68,13
?max_span..' pixel max span length',18,76,13
?#s..' characters total',24,84,6

Optimizing for encoding

To make the most of your data strings, you'll need to optimize your spritesheet. For example, here are the raw spritesheets for the demos I showed earlier (well, half of the frames for the Lemmings one).



While Jelpi uses colors from Pico-8's full palette and works better with RLE, the Lemmings and Pitfall Harry sprites only use 4 and 2 colors respectively, and both are stored more efficiently using direct pixel encoding. Because of the math involved, if you want to restrict your palette to save space, you'll need to draw the sprites using the lowest-numbered colors. With 4 colors we have to use colors 0-3, and with 2 colors, we use 0 and 1. It looks weird, but we'll fix it later.

In addition to this, the Lemmings sprites aren't laid out horizontally as you might expect, but vertically. That's because they're only six pixels wide, so placing them side-by-side would take 1/3 more space than necessary. You'll also notice there aren't full frames of animation for Jelpi's run because there wasn't enough space. Because Jelpi's head is the same in each frame and only the position of the legs change, I just drew the head once and stored stacked animation frames of the 2-pixel high leg area, which will be displayed using the sspr(). Jelpi does move up and down a pixel during the run cycle, but that can be added at runtime by altering the vertical sprite position based on the current frame in the animation cycle using '%' and '\'. As you can see, even with efficient compression, it takes some thought and ingenuity to squeeze graphics down to a few hundred characters.

Now let's deal with the problematic backslash character. If we left this in our strings we'd get an error at runtime, but the encoders above will look for the value corresponding to a backslash and replace it with the value for an exclamation point. This will cause some slight graphical glitches, but not an error. If, after encoding, you notice any exlamation points in your string or glitches in your sprites, you can either slightly rework them to avoid this, or use this bit of extra code.


Just place this right after "-35" in the decoder to intercept the incoming value, and if it's -2, it will be set to the correct value of 57. It basically does the same thing as "if(v==-2)v=57", but in fewer characters.

Sprite recoloring

If you restricted your sprites' color range to save space, you'll need to set the pixels back to the right colors. There are a few different ways to do this, but each one takes around a dozen characters or more, so experiment and compare how many chars it takes to recolor vs. just encoding the right colors in the first place.

Using the Lemmings sprites above as an example of recoloring indexed color sprites, I've come up with two main solutions for this. The first lets you recolor using Pico-8's standard palette, as you can see in the second lemming , and the second lets you use any mixture of colors from the standard and dark palettes, which can be a better fit, as seen in the third lemming.

The standard color method uses a small extra string placed inside an ord() function to act as a lookup table. Place this into the sset() command in the decoder as the third input, with the pixel value v\4^(i%3)%4 used as the string position input. It will intercept the pixel values of 0-3 which the output of the string produces, and instead of using it to color the pixels directly, it will use the small string as a lookup table for the corrected colors. Note that you only need 1 less than the number of colors in your palette, (e.g. 3 string characters for a palette of 4 colors). This is because there's no entry 0 in the string, so color 0 will remain unchanged and transparent, which we'll want. As for which characters to use, you can use any which are in the correct column of the character set, though I like to use chars 48-63 as shown in green below, because it makes things more intuitive for 10 out of the 16 colors. Using these characters, our lookup string will have characters from columns 13,11, and 15, or "=;?".


for i=0,380do v=ord("",i\3+1)-35

For recoloring using mixed standard and dark palette colors, the most compact way I've found is to declare a small table at the beginning of your code instead of using a lookup string. Like the standard color method, this won't effect color 0, just keep in mind that colors 1-whatever will have those new values wherever they are used. The dark palette colors are usually called by their color palette index number+128, so for medium blue we'd add 12 (light blue) and 128 for 140. I've found that the same effect can be had by just subtracting 16, though, instead of adding 128, which can save a character. So, to get medium blue, we can use 12-16= -4. Likewise, for medium green, we can use 11-16= -5.


Now, the Pitfall sprites are more of a special case. They're one bit, or just 0 and 1. This saves space and allows 6 on or off pixels per character for a 92-character range, or 7 if you're using a range of 221 characters, but by default everything will just be dark blue. I've come up with two main methods for dealing with this as well. The first is just setting every 'on' pixel to a certain consistent value, and the second recreates the look of Atari graphics by recoloring the 1-bit sprite on every scanline.

For a starting point, this is what the code looks like to paint Harry in basic dark blue.

for i=0,509do v=ord("",i\6+1)-35

Changing the sprite color from dark blue to a single other color is very simple. Since every non-transparent pixel equals 1, just multiply the pixel value v\2^(i%6)%2 by the color you want. In the case above, I used 11.

for i=0,509do v=ord("",i\6+1)-35

For colors that vary per scanline, we'll need another small lookup string, but this time we need more math. Specifically, we'll take the pixel value and multiply it another expression, (i+120)\80.

for i=0,509do v=ord("",i\6+1)-35

The 80 here represents twice the width of pixels of all our sprites, which are 40 pixels wide, and the floor divide means this value will count up by 1 every time i increases by 80, or every two rows, so each character in our lookup string will color two rows of pixels. If we replaced 80 with 40, we'd be able to color each individual row with a string entry. An offset (120) is added to i here because if not, no color would be assigned until two rows had been completed, cutting of Pitfall Harry's head (yikes...). The offset here is 120 specifically because that means the pixels will be set to the color of the first symbol only for the first row, (80 to get to 1, plus 40 so the value will change to 2 after 40 pixels, or 1 row), which is helpful because his brown hair is only one pixel tall.

Note, these recoloring methods should also with an RLE decoder, just make sure you have the right number of entries in any lookup strings and plug the pixel value of the decoder into them or multiply it by a constant in a similar way. The one possible exception is the per-scanline color trick, haven't tried that with RLE yet.

Animating Sprites

Finally, here are a few tips for animating your sprites in very few characters. First of all, since your animations will probably be just looping a set pattern of sprites, we can do that easily with the modulo operator (%). You just need a variable that increases or decreases every frame, what multiple of this you want the animation to update at, and a modulo value to make it loop through a certain number of animation frames. Here are a couple different ways of doing this for the Lemmings sprites, using this expression as the sprite number input in the spr() function.


The variable t() is an abbreviation for time(), and will give the time elapsed since startup. By itself this counts up tiny fractions of an integer every frame, and by 1 each second. Neither of these are useful, but floor dividing it by .1 means that the the animation frame will increase by the integer 1 every 10th of a second, or every 3 frames, which is a good speed. This expression is then run through %8, resulting in a sprite number that cycles from 0-7, but then we also need to multiply that by 16 to match up with the right sprite numbers (0,16,32,...), because the sprites are laid out vertically.

Since it might be a good illustration and starting point, here's a complete, simplified version of the Lemmings tweet.

pal({-4,-5,15},1)for n=0,380do v=ord("+%K%C&S2_$?$7(2_C%K.[2S$_$?$:(&2K-K&S2S$S$3&?$S&C-K&S2S$3&3V7/_#+%K%C&S23&307(2_C%K.[2S$S$3&:(&2K-K&S2S$S$3$?$S&C-K&S2S$?$?T7/_",n\3+1)-35sset(n%6,n\6,v\4^(n%3)%4)end
poke(24364,3)::_::cls()spr(t()\.1%8*16,29,28)flip()goto _


Next up, here's how the animation code works for Pitfall Harry.


Here, we use a similar structure, an iterating variable run through a floor divide to determine animation speed, then a modulo to control the number of animation frames. Here, we have a new sprite used every 3 frames, and the there are 5 sprites in the run cycle. The same iterating variable is also used in the x-position, along with a modulo. 'k' here is an alias for the constant value of 139, and combined with a modulo, this is what makes Harry's horizontal position loop. The expression ˇ%k, which means position%139-8 makes his horizontal position cycle from -8 to 130, so he keeps running by.

As a side note, the symbol I'm using there, ˇ, is character 149 from Pico-8's character set, which you get by pressing shift+v, and looks like two little birds. I'm using it because it has some unique properties. It only counts as one byte in a tweet, but like the other glyphs, it has a default value before being assigned one (in this case it's -2624.5). Because we're running it through a modulo, it's exact value doesn't matter, so we don't need to intialize it, which saves 3 characters =).

Finally, Here's the code for displaying the Jelpi demo sprites, showing some more advanced tricks.


To start, k gives the animation speed (new sprite every 2 frames) and cycle length (5 sprites). With the variable z here I create a value that cycles between 0 (for the head), and 1 (for the body). This is for two reasons. First, it lets me co-opt the same loop that I'm using to set the sprite pixels, to also display all the sprites. The single sspr() function here draws, by turn, both the head and body. The horizontal spritesheet position starting is always the same, but vertical is adjusted by the z variable to be either 0, or cycle through the values 6,8,10,12,and 14. z is also used to cycle sprite height between 6 pixels for the head and 2 pixels for the legs. For vertical position, this is increased by 6 for the legs to put them just below the head, but both head and legs are also modified by -k\3. This is what creates the up and down motion for the animation. Because k cycles between 0 and 4, the value will be -1 when k is >=3, so Jelpi will go up one pixel for the 4th and 5th animation frames. (It's so simple o_O).

The spr() function draws the ground layer by setting several sprites side by side at 8-pixel increments, and it creates the looping effect by performing a, you guessed it, modulo operation on the position variable, represented by our bird glyph, while 8 is also subtracted to make sure there's never a blank space on the left edge of the screen.

Wow, we got pretty far in the weeds there, didn't we? Hopefully you were able to get through that and it made sense. Anyway, that's all for now. I hope that gave you some good tools and ideas, and that you have fun squeezing graphics down to an absurdly small size. I look forward to seeing what you come up with. =)

P#96437 2021-08-25 06:20 ( Edited 2021-09-05 15:39)

Cart #floppy_bird-0 | 2021-06-28 | Code ▽ | Embed ▽ | No License

This is a clone of the infamous Flappy Bird, scrunched down to under 560 characters. I wanted to see if I could fit a game with actual graphics within the limit, and I'm happy to say that it worked. Any feedback about the controls and physics is welcome.

Controls: Press any button to fly upward/restart

P#94162 2021-06-28 01:10 ( Edited 2021-08-24 16:28)

Cart #tjlr01-0 | 2021-06-16 | Code ▽ | Embed ▽ | No License

This is the full level 1-1 from Super Mario Bros., graphics and all, contained in 3 tweets, or 840 bytes. The first 280 bytes contains the actual level data (including level-specific graphics), and the next two contain the rendering engine and the main tileset. I'm thinking about making some more add-on levels, which should each fit in a single tweet.

I've made a number of Tweetcarts, and also worked on systems to efficiently compress graphics and level data to fit more on a PICO-8 cart, so this is kind of the logical combination of both. I'm not going to try and fit a full NES game in tweet form, but it's a neat demo that helped me learn some new optimization strategies.

P#93586 2021-06-16 02:30 ( Edited 2021-06-20 04:55)

Cart #picomap-2 | 2021-07-28 | Code ▽ | Embed ▽ | No License

Version 0.30-- Added support for parallax scrolling backgrounds, added eraser tile functionality, made repeating pattern size adjustable, revamped architecture to handle future added features, sprite flags now export along with sprite and map data, various optimizations and bug fixes.

Version 0.21-- Updated appearance and changed name to something simpler and (hopefully) more appealing, misc. bug fixes.

Version 0.2-- Reconfigured repeating pattern object types for adjustable pattern size, added level delete option to editor menu, and changed a few design elements to improve usability

PicoMap is a graphical map editor that allows creation of large game worlds hundreds of screens in size that fit in a single Pico-8 cart. It does this using a version of metatiles, a compression technique used commonly with retro systems like the NES. Basically, levels are stored more efficiently by being built from groups of tiles instead of single tiles, just as images are stored more efficiently when built from tiles rather than single pixels.

To give you an idea of how efficient the scheme is, I built a playable demo of all Super Mario Bros. level maps with an earlier version, and they fit in just 3.9KB, about 1/3 of the storage space the system makes available.

I've worked hard to minimize the system's footprint so it's easy to add to game carts. It's very CPU-efficient and well-suited to 60fps games since map decompression is done only when loading a new level, and the core functions take about 650 tokens and 9% of compressed file size with comments, or about 6% without. You can use PicoMap in any project you want and modify the code to fit your application, just be sure to include attribution somewhere in your cart. Hopefully this will enable people to make some cool larger-scale games like platformers and action-adventures.

System outline

PicoMap lets users create levels from metatile "objects", like a tree, a hill, or a building, each of which is basically a reference to a rectangle of tiles in Pico 8's map area. In the editor, levels are stored as lists of objects in string form, but when exported to a separate cart, these are condensed into raw binary data and stored in its spritesheet and map areas. Meanwhile, three strings are output to the clipboard-- compressed sprite and map area data strings, and a string-based lookup table for the location of each level's data in cart memory.

When the destination cart is run, the binary level data is transferred to a table in Lua RAM and the spritesheet and map area data are decompressed to the proper areas in cart memory. On loading a level, a second table is created to contain its map, and this is filled using instructions from the main table. A portion of the level table slightly larger than one screen is then copied to the top right corner of Pico-8's map area once each frame and mapped to the display. This allows each level to be any width or height, and up to 256 screens in size.


--Editor controls
Left Mouse btn.-----Select or place object/bring up object placement preview
Right Mouse btn.---Click and hold to drag view (turns off object placement preview)
Directional keys----Move view
Scroll Wheel--------Select object number
Z--------------------Toggle object editor screen
X--------------------Delete object when mousing over its top left corner (a white 'x' will appear)

--Editor shortcut keys
V-------------------Change variance type (when in obj.editing mode)
M-------------------Change mapping pattern type (when in obj.editing mode)
G-------------------Toggle grid
S-------------------New level string submenu
Q-------------------Previous level map
W------------------Next level map
E-------------------Export level map to cartridge
A-------------------Export all level maps to cartridge

--Viewer Cartridge
Directional keys---Move camera
Z-------------------Previous level map
X-------------------Next level map

Using the editor

Creating a new level

Once you've started the editor, if you want to create a new level string, open the menu and click on the 'new level map' icon. Select your desired background color, level type (work in progress), level width and height in screens, and press the checkmark icon to create the new level string.

Creating Objects

Since your maps will be made from tile patterns in Pico-8's map area, you'll need to draw each object type there before you can use it. Due to the way the system works, you'll need to keep a couple of limitations in mind.

Also, to increase compression, object positions are stored as position on the screen, and the level is built screen by screen, left to right and top to bottom, so when exported levels are viewed in a separate cart, objects with starting positions on a screen further to the right or further down in the level will always be drawn over ones that start on an earlier screen.

To create objects to populate your level map, select the object category using the icons on the top right, then the object number either by clicking the thumbnail and selecting a slot from the drop down menu, or by using the mouse wheel. To create an object, go into object editing mode by pressing 'Z' and outline the rectangle of tiles that defines the object's default (minimum) size.

Object settings

Each object type can be made to have a variable size. This is done by changing two properties, its variance and mapping pattern. These are represented by icons in the lower right corner of the editor, next to the object's ID number.

An object's variance type tells how its size can be altered when it's being placed in a level.The box that's highlighted defines the default (or minimum) size of an object, but if its size is variable along an axis, the size can be extended up to 15 tiles larger than the default size in that direction. Fixed-size objects take 2 bytes each, while ones whose size can vary on one or two axes take 2.5 and 3 bytes respectively (though it'd be possible to limit this to 2.5 bytes max via lookup tables if you only need certain types in a given level).

--Mapping type
This property controls the pattern of how map tiles are used to build objects in your level. This can allow objects to be made much larger than their representations in Pico-8's map area while still keeping their intended traits.

To change these settings for an object, go into the object editing mode and click on the buttons in the bottom right hand corner, or press the 'V' key to cycle through variance types and the 'M' key to cycle through mapping types.

System Settings

Saving Levels

The system continuously outputs the level you're working on and the list of definitions for all the objects you've defined to the clipboard as strings. To save these to the cartridge, just paste the contents of the clipboard over the current strings in the "data strings" tab, and save the cart.

Exporting Levels

Once you've made some levels, you can export them to a separate viewer cartridge, suitable to be incorporated into a game. To do this, first open a new cart and paste the functions from the "Game Cart Functions" tab in the editor there, and uncomment them. Then save the cart with the same name as the "export_cart_name" variable in the editor cart's _init() function, and save and close the new cart.

Next, run the editor, open the system menu, and click on one of the cartridge icons to export either the current level map, or all level maps to your new cart. Now open the viewer cart, make sure "puny font mode" is enabled by pressing Ctrl+P, and paste the contents of the clipboard into it. Now you can run the cart and view your levels.

As this is an early version of PicoMap, it's missing a few features and may have some kinks to work out, and the code's kind of messy. Please let me know about any issues you encounter, as well as any improvements you might think of. Thanks.

P#91798 2021-05-11 17:48 ( Edited 2021-10-14 22:02)

I've lately been working with image compression routines which output strings, and I've been able to increase efficiency and versatility by using as wide a range of characters to store data as possible. I've grown a bit frustrated at times, though, because any strings which use Puny font characters don't show up correctly unless I go into Puny Font mode. There have been a number of times I couldn't get things to work, and spent time debugging my code, only to realize that the problem was that I forgot to press Ctrl+P.

I know it's not a big issue, and it can be worked around, but it's kind of inconsistent how strings can be created with Puny characters at any time, but you have to enter a certain mode to view the output correctly. Is it possible this could be changed without breaking some other feature? I mean, is there any way to let the program know that a string has been created by Pico-8 and therefore display it as intended?

P#89758 2021-03-30 17:16 ( Edited 2021-05-12 02:36)

Cart #chrprinter-2 | 2021-03-09 | Code ▽ | Embed ▽ | No License

Version 1.1 -- added ability to clear output string by pressing Z
Version 1.2 -- Removed characters 0-15 as Pico-8 0.2.2 made these unusable and problematic, tweaked appearance

This is a little tool for easily selecting and outputting characters from Pico 8's extended character set. You can build strings of any length and paste them as text using Ctrl+V or a right mouse click (on the BBS, you have to press Ctrl+C as well). I had some fun making it look like a version of the Pico-8 code editor with text characters as the icons, and since it's a pretty small program, I squeezed it down to fit in a tweet =).


Arrow buttons---Select character
X button--------Add character to output string
Z button--------Clear output string

P#84578 2020-11-21 21:19 ( Edited 2021-03-09 18:03)

Cart #tidx-7 | 2021-06-22 | Code ▽ | Embed ▽ | No License

Version 1.1 - Reworked code and squeezed in invader animation
Version 1.2 - Invader shots now target player, tweaked barriers, fixed disappearing score glitch

This is a port of the original arcade Space Invaders in just over half a kilobyte. I had to simplify a few things, like only having one invader type, cutting the UFO, and rethinking the lives system a little bit, but most of the major elements are there, and I think it plays fairly well.


  • Score system
  • Level Progression
  • Enemy Animation
  • Enemy Fire with homing shots
  • Destructible barriers
  • Increasing invader speed and fire rate as number destroyed increases
  • Damage system (your laser cannon changes colors after taking a hit, and will be destroyed after 3)


L/R----Move laser cannon

P#84441 2020-11-18 18:23 ( Edited 2021-06-22 07:09)

Cart #ti-4 | 2020-11-20 | Code ▽ | Embed ▽ | No License

This is something I've been working on here and there for a while, but the jam was finally an excuse to finish it. It's a simple space invaders clone in a single tweet. There's no enemy fire or shields, but the invaders do speed up as you destroy more of them, and it's tricky to take the last few out.;)

Version 1.1 - new enemy wave begins when current wave is destroyed

P#83933 2020-11-07 17:10 ( Edited 2020-11-20 14:08)

Cart #tweetpaint1_0-2 | 2020-11-11 | Code ▽ | Embed ▽ | No License

Version 1.1 -- Updated for TweetTweetJam5, added square brush feature and tweaked appearance

This is a fully-functional painting program with image save capability in just 277 characters. It's built entirely around mouse controls, and requires a mouse with a scroll wheel for full functionality. Hope somebody enjoys playing around with it.


Left mouse button ---- Paint
Right mouse button --- Select paint color (hold and move mouse L/R)
Middle Mouse button -- Save drawing to cart
Scroll wheel --------- Change paintbrush size
X key (hold) --------- Use square brush

P#83565 2020-11-01 05:58 ( Edited 2020-11-11 18:17)

Cart #srs1_0-2 | 2020-10-30 | Code ▽ | Embed ▽ | No License

This is a compact and efficient system that enables recoloring of sprite graphics. For just 76 tokens, plus any function calls and data strings, you can easily change the color palettes of level tiles or characters based on an arbitrary number of conditions, and even animate them using color cycling. These kinds of techniques were used extensively in games for consoles like the NES to increase graphical variety while conserving limited memory resources. The cart explains the syntax of the data strings and includes a simple demo of what the system can do.

P#83432 2020-10-28 18:14 ( Edited 2020-10-30 04:04)

Cart #atc1-0 | 2020-10-27 | Code ▽ | Embed ▽ | No License

This is a little exercise in code optimization, a fully-functional analog clock in just 196 characters. I'm thinking I might add some features in the future while still keeping it under the 280-character limit, but for now it works just fine.

P#83389 2020-10-27 01:03 ( Edited 2020-10-30 02:46)

Cart #msd1_0-1 | 2020-09-06 | Code ▽ | Embed ▽ | No License

This is a demo for a system I developed that can store console-size game worlds on a Pico-8 cart. It contains every level and sublevel map from the original Super Mario Bros., and you can run and jump through all of them. There's no level progression, sound, or things to interact with besides platforms, but the map data includes placeholders for enemy spawn points and interactive objects, just uncomment a line in the init() function to make these visible. I'm not planning to release the finished game, as I don't want it to be taken down for copyright reasons, but I wanted to show some definitive proof that large-scale games are possible on Pico-8.


Up/down---Select Level
Up+down---Restart Level

Cart Technical Info:

  • Uses standard map() and sprite flag functions (w/special camera offsets)
  • 60fps w/ CPU usage between 11-25%
  • 1352 tokens, including streamlined platformer engine and graphics/map decompression systems
  • 35% of compressed storage limit
  • All maps contained in 3.9KB of binary data in map area
  • No data stored in the 8KB spritesheet

The big thing is the last point on the list. Instead of storing the nearly-incompressible level data in strings, I instead store the spritesheet in a string because it compresses over 2:1, leaving a full 12KB of potential level storage space. This means that while leaving the majority of compressed data capacity and token count unused, 3 copies of every Super Mario Bros. level could fit on the cart! By my estimates, the worlds of mid-sized NES games like Megaman, Ninja Gaiden, Castlevania, Zelda, and even SMB2 (or original ones with similar scope and detail) could fit within that 12KB limit with some optimization. For instance, I estimate that Zelda 1's whole world could fit in around 6KB.

This demo was built entirely in Pico-8, using a graphical level editor that I plan to release in the near future. It's currently a bit limited due to being tailored to the quirks and limitations of SMB, but I intend to add some more features and make it easy for anyone to build their own large game worlds using a simple point-and-click interface. Here's a little preview =).

P#81450 2020-09-02 18:44 ( Edited 2021-07-11 03:55)

Cart #lgrs2_0-0 | 2020-11-29 | Code ▽ | Embed ▽ | No License

Cart #lrs_1_0-0 | 2020-07-15 | Code ▽ | Embed ▽ | No License

Version 2.0 --New system with much-improved ease-of-use and flexibility in one tiny, 74-token function!

With Pico-8's small spritesheet, many game makers who want a nice title screen are forced to either give up valuable sprite space for a custom-drawn logo, or use a tiny one and zoom in so it but looks very pixelated. Occasionally, someone will use a more advanced method to store images, such as Zep's PX9 or dw817's compression programs. These work well, but the minimum cost of 1000+ characters and 280+ tokens for decompression plus prite sheet rewriting, and/or screen-filling compressed strings can be overkill for many projects, so I came up with my own alternatives.

Version 1.0 encodes logos as 1bpp images into 7 bit-per-character strings, then renders graphical features such as shadows, color gradients, and outlines in real time, without using the sprite sheet. A logo drawing function built with it takes between 85-130 tokens and achieves high levels of compression, though it's limited only to logos, and large ones with outlines can use ~50% of cpu cycles at 30fps.

Version 2.0 uses a version of Run-Length-Encoding (RLE) to compress full-color graphics into strings. It's based on this system here, originally devised by @spellcaster, but I was able to shrink the core functionality down to a fraction of the size and token count while adding a few new features. Like version 1.0 it doesn't use the sprite sheet at all and can handle images of any pixel dimensions. It offers a slightly less compact data footprint, but is far simpler to use, uses less CPU, and can handle any kind of graphics you want. There are 3 versions:

  1. Core version --the one demonstrated in the cart (74 tokens)
  2. Version with pre-conversion of strings to tables (104 tokens, lowers CPU usage about 40% further on average --could be useful for 60fps games)
  3. Version with pre-conversion and real-time vertical and horizontal flipping (161 tokens)

Both 1.0 and 2.0 include instructions to encode your own logos or images, but version 2.0 is much simpler to use, just import or paste an image into the top left corner of the spritesheet, specify its size in pixels, run the cartridge, and follow the icons to encode the image and output a compressed string.

P#79345 2020-07-15 02:27 ( Edited 2020-11-29 08:04)

Lately I've heard bits here and there about a new function called unpack that seems to have some significant benefits, but after searching the BBS, the Pico 8 Wiki, and Google, I've barely been able to come up with any solid infomation on it or how to use it.

If someone could point me in the right direction, I'd much appreciate it.

P#79144 2020-07-11 00:50

Cart #sia01-0 | 2020-06-16 | Code ▽ | Embed ▽ | No License

Yes, this is yet another version of Space Invaders, but with this one I'm going for a direct port of the original arcade game. It's mostly complete, with functional gameplay and a working high score save system, but it needs some gameplay tweaks and a few graphical elements, and the sound effects are very much unfinished (I'm working on a version of the 4-tone march using subtones, but haven't ironed out the glitches yet). Anyway, in addition to going for authenticity, I also tried to code this very efficiently, and the whole game (including all graphics and sound), takes under 3KB and only about 1100 tokens.

Any constructive criticism and general feedback is welcome, thanks.

L/R------Move cannon

P#78157 2020-06-16 18:22

Cart #cbex-2 | 2021-06-22 | Code ▽ | Embed ▽ | No License

Version 1.1-- Managed to shrink code to under 560 characters, making this a tweettweetcart
Version 1.2-- Fixed game over glitch, improved HUD

Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.


Z------------------Small bounce
X------------------Regular bounce
Z+X--------------Super bounce

This is the deluxe version of my single-Tweet platformer Cloud Bounce. The gameplay is essentially the same, but in just two tweets it has a lot of important game features added, including:

  • Animated title screen
  • Game over screen with restart
  • Lives system
  • Checkpoints
  • An improved ending (the original was by necessity super abrupt)

There's no sound or music, and no enemies, but overall I'm pretty happy with how much of a full game I managed to fit in a little over half a Kilobyte. I'm interested to see how complete a game I could fit in 2 or 4KB using some of the optimization techniques I've learned.

P#77005 2020-05-22 09:24 ( Edited 2021-06-22 06:21)

Cart #tweetris1_1-3 | 2021-09-06 | Code ▽ | Embed ▽ | No License

Version 1.1: Fixed game over glitch that could occur when pieces were rotated the moment they appeared, pieces can now be rotated clockwise and counterclockwise.

This is a fully playable version of Tetris in fewer characters than a moderate-length email, including:

  • Line removal
  • Level progression (speed increases after every 10 lines cleared)
  • 'Lines cleared' display
  • CW and CCW piece rotation
  • Soft drop button (with slight delay when next piece appears)

L/R-------move piece
Down------soft drop
X-------rotate piece clockwise
O-------rotate piece counterclockwise

Fitting everything in this small a space was pretty tough. I had to cut a few corners, like leaving out the next piece preview, as well as logic to allow movement of blocks once they land, so overhangs are a nuisance. With all that said, though, I worked hard trying to make this an actually decent version of tetris and not just a technical curiousity, so hopefully somebody actually enjoys playing it instead of just staring at the indecipherable souce code. Shoutout to 2dArray, whose Tweetjam Tetris and its genius piece indexing system I built on for this project.

P#76116 2020-05-08 08:53 ( Edited 2021-09-06 20:20)

Cart #avalanche_02-0 | 2020-05-06 | Code ▽ | Embed ▽ | No License

Version 0.2 - Now has definite fail state with timer stop, and recolored graphics


You are a ground-based defense drone at a top-secret research base inexplicably located by a mountain prone to avalanches. When a tidal wave of snow and ice rushes toward you, you must use your cannon to vaporize it, keeping it at bay for as long as possible so the base staff can get to safety. How long can you hold out?

L/R------Move drone
X--------Fire cannon

This is the unintended result of trying to cram a minimalistic space invaders clone into 280 characters. I couldn't figure out how to fit code for individual enemies, but an advancing amorphous mass was just doable. Hopefully it turned out alright on its own terms, and I welcome any feedback or criticism. Warning, though, this can get a bit nerve-wracking. o_O

P#75452 2020-04-26 23:42 ( Edited 2020-05-06 06:03)

View Older Posts
Follow Lexaloffle:        
Generated 2021-10-19 20:29:47 | 0.169s | Q:85