v1.1: Fixed occasional impossible jumps
This is a little endless runner game featuring Pico-8 mascot Jelpi in just 500 characters of code. I tried to cram in the best graphics and parallax scrolling that would fit. Hope you enjoy it.
(Submission to TweetTweetJam 8)
Controls:
Jump----Any button
Restart--reset
5 comments
This is a work-in-progress demo of my Pico-8 port of the original NES Mega Man. I made a small initial demo stage to test out my platforing engine, then made some level maps to test out my PicoMap level compression system, and after some success tinkering with a low-token entity system, I figured the whole game looked feasible. It's going to be a longer-term project for sure, but I figured I'd put out some demos as I finish parts of it.
Version 0.1:
- Full platformer engine w/climbing and shooting
- Eight selectable weapon types
- Working Pits & spikes w/level restart
- Level select screen
- All 6 robot master stages available to explore
- No music or SFX
- No enemies
Controls:
Dpad-----Move
Z--------Shoot
X--------Jump/Select stage
Enter:
Tap------Select weapon
Hold-----Menu
Just updated to v0.2.5e, and found that it breaks a number of my tweetcarts.
The issue specifically seems to be that this shortcut is no longer supported:
if(...)do --thing1 --thing2 --etc. end |
Now to make things work, I have to replace the "do" with "then". Not a huge change, but it does require a couple more characters, and every one counts when dealing with strict character limits.
This is a playable version of World 1-1 from Super Mario Bros. in just 1KB of compressed code. It's basically a proof-of-concept for a number of super-condensed game systems that I've been working on, but hopefully it's fun to play around with, too.
Controls:
Arrow keys: Move
X button: jump
I've been working on a platformer game engine for a little while, but I'd only made a basic run-and-jump. This was an excuse to develop something more capable. While I'm not immediately planning to demake an entire Mega Man game, with PicoMap, my metatile-based map system, it seems possible. I've been working on pixel art and layouts for some levels, so I'll see where things go.
Changelog:
Controls:
Left/Right---Move
Z------------Shoot
X------------Jump
Enter--------Weapon Select Menu
I've been working on building a simple and efficient platformer engine, and while it basically works, the character sprite can appear jittery depending on the character and camera movement, and I haven't figured out why. I've uploaded a prototype it you'd like to check it out. If anyone has some ideas or suggestions, I'd appreciate it, thanks.
Controls:
L\R-----------Move
Z-------------Run
X-------------Jump
A segmented LCD-style clock. It's pretty simple, but figuring out an efficient way of storing the graphics and not using any spritesheet space was interesting. Entry for the Pico-8 512-Char Jam.
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
Controls:
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!
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.
updated 9/3/22: Improved encoders with automatic escape-sequence insertion and updated tutorial.
Since getting into Pico-8, 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
sset(n%6,n\6,(ord("+%K%C&S2_$?$7(2_C%K.[2S$S$?$:(&2K-K&S2S$3&S$?$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)-35)\4^(n%3)%4)
if(n<7)spr((ˇ+n)\1%8*16,(ˇ+n*32)%176-8,60)end
ˇ+=.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 Pico1K 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 make printing them problematic, but all of them except characters 1,2,3, and 9 will count as two chars on Twitter. Of the remaining characters, 34, and 92 (shown in red) require an extra backslash character placed in front of them in a string, 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 (~).
Alternately, if you're not going to post your code to Twitter, such as in the case of the Pico1K Jam, you can use characters 0-255, and you don't need to worry about any counting as 2 chars, though symbols 0,10,13,34, and 92 will still require an extra backslash character, which the encoders below will add automatically.
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 optimal range of characters we can use for tweets 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. If you're not posting to Twitter, you can pick your minimum starting value, for example, setting it to 16 to avoid the escape sequence characters needed for symbols 0,10, and 13, or just setting it to 0 for the full range of characters.
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, you can set 'min_val' to 0 and 'max_val' to 255 to use all 256 of them.
Direct pixel encoder
width=8
height=8
min_val=35
max_val=126
-----------
cls()
top_color=0
for i=0,width*height-1 do
col=sget(i%width,i\width)
top_color=max(col,top_color)
end
colors=top_color+1
p=0
while colors^(p+1)<=(min(256,max_val-min_val+1)) do
p+=1
end
pixels=p
tbl={}
i=0
while i<width*height do
val=0
for j=0,pixels-1 do
val+=sget((i+j)%width,(i+j)\width)*colors^j
end
add(tbl,val+min_val)
i+=pixels
end
str=""
ch=0
for i=1,#tbl do
val=tbl[i]
nxtval=tbl[i+1]
if i<#tbl and nxtval>47 and nxtval<58 and val==0 then
str..="\\000"
elseif val==0 then str..="\\0"
elseif val==10 then str..="\\n"
elseif val==13 then str..="\\r"
elseif val==34 then str..="\\\""
elseif val==92 then str..="\\\\"
else str..=chr(val)
end
end
function cprint(s,y,c)
?s,64-#s*2,y,c
end
printh(str,'@clip')
cprint('string pasted to clipboard',52,11)
cprint(1+max_val-min_val..' possible values',60,13)
cprint(colors..' colors/pixel',68,13)
cprint(pixels..' pixels/character',76,13)
cprint(#str..' characters total',84,12)
cprint(width*height..' values total',92,6) |
RLE encoder
width=8
height=8
min_val=35
max_val=126
--------
cls()
top_color=0
for i=0,width*height-1 do
col=sget(i%width,i\width)
top_color=max(col,top_color)
end
colors=top_color+1
max_span=min(256,max_val-min_val+1)\colors
tbl={}
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
len+=1
else
v=val+len*colors
add(tbl,v+min_val)
len=0
end
n+=1
end
str=""
ch=0
for i=1,#tbl do
val=tbl[i]
nxtval=tbl[i+1]
if i<#tbl and nxtval>47 and nxtval<58 and val==0 then
str..="\\000" ch+=3
elseif val==0 then str..="\\0" ch+=1
elseif val==10 then str..="\\n" ch+=1
elseif val==13 then str..="\\r" ch+=1
elseif val==34 then str..="\\\"" ch+=1
elseif val==92 then str..="\\\\" ch+=1
else str..=chr(val)
end
end
function cprint(s,y,c)
?s,64-#s*2,y,c
end
printh(str,'@clip')
cprint('string posted to clipboard',52,11)
cprint(1+max_val-min_val..' possible values',60,13)
cprint(colors..' colors/pixel',68,13)
cprint(max_span..' pixel max span length',76,13)
cprint(#str..' characters total',84,12)
cprint(#str-ch..' values total',92,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 sprite graphics and animation down to a few hundred 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
sset(i%6,i\6,ord("=;?",v\4^(i%3)%4))end |
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.
pal({-4,-5,15},1) |
-
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
sset(i%40,i\40,v\2^(i%6)%2)end |
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
sset(i%40,i\40,v\2^(i%6)%2*11)end |
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
sset(i%40,i\40,ord("4?;;333",v\2^(i%6)%2*(i+120)\80)) |
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.
t()\.1%8*16 |
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.
spr(ˇ\3%5,ˇ%k-8,64,1,2)ˇ+=1 |
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.
k=ˇ\2%5... 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) |
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 sprite graphics down to an absurdly small size. I look forward to seeing what you come up with. =)
This is a clone of the infamous Flappy Bird, complete with detailed graphics and 60fps gameplay, and scrunched down to under 560 characters. Any feedback about the controls or physics is welcome.
Controls: Press any button to fly upward/restart
Version 1.1 - Added high score and a brief pause before gravity kicks in on restart.
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.
Current version: 0.42
Changelog
PicoMap is a graphical map editor that allows console game size worlds to 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. https://www.lexaloffle.com/bbs/?tid=39469
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 system functions take up about 10% of the compressed size and token limits, or about 7% for the version without autotiling. 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 memory. 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, five strings are output to the clipboard-- compressed sprite and map memory data strings, a string defining metatile types and some system settings, and string-based lookup tables for the location of each level's data in cart memory and defined autotile types.
When the destination cart is run, the binary level data is transferred to a large table in Pico-8's Lua RAM and the spritesheet and map memory data are decompressed to the proper areas in cart memory. On loading a level, a table is created to contain its map, and this is filled using instructions from the binary level data. A portion of the level table slightly larger than one screen is then copied to the top right corner of Pico-8's map memory 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.
Controls
Editor
Left Mouse btn.-----Select or place object/bring up object placement preview
Right Mouse btn.---Click and hold to drag view/turn off object placement preview
Directional keys----Move view
Scroll Wheel--------Select object number
Space---------------Toggle object editor screen
Z--------------------Undo
X--------------------Delete object when mousing over its top left corner w/object placement preview off (dotted outline and X symbol 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
I--------------------Import spritesheet, sprite flags, and map memory from external cart
E-------------------Export level maps to external cart
H-------------------Reset current map to Home position (screen 1,1)
O-------------------Toggle display of # of objects in range of screen and total # of objects in map
Viewer Cartridge
Directional keys---Move camera
Z-------------------Previous level map (optional)
X-------------------Next level map (optional)
Using the editor
As this is an early version of PicoMap, it's not yet complete and there are going to be bugs here and there. Please let me know about any issues you encounter, as well as any improvements you might think of. Thanks.
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?
v1.1 -- Added ability to clear output string by pressing Z
v1.2 -- Removed characters 0-15 as Pico-8 0.2.2 made these unusable, tweaked appearance
v1.3 -- Added characters 0-15 as code comments so they can be copied and pasted manually
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 =).
Controls:
Arrow buttons---Select character
X button--------Add character to output string
Z button--------Clear output string
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.
Features:
- 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)
Controls:
L/R----Move laser cannon
Z/X----Fire
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
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.
Controls:
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
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 memory space. The cart explains the syntax of the data strings and includes a simple demo of what the system can do.
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.
View Older Posts
