Version 1.1 -- added ability to clear output string by pressing Z
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
Version 1.1 - Reworked code and squeezed in invader animation
This is a port of the original arcade Space Invaders in just over half a kilobyte. I was planning to submit this for TweetTweetJam 5, but shrinking it down to fit into the size limit proved pretty tricky. The invaders all look the same, there's no UFO that intermittently heads across the screen, and I had to rethink the lives system a little bit, but all the other major elements are there, and I think it plays decently well.
- Score system
- Level Progression
- Enemy Animation
- Enemy Fire
- 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
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.
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 limited memory resources. 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.
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.
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-tier 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 =).
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:
- Core version --the one demonstrated in the cart (74 tokens)
- Version with pre-conversion of strings to tables (104 tokens, lowers CPU usage about 40% further on average --could be useful for 60fps games)
- 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.
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.
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.
Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.
A little while ago I uploaded my first game Cloud Bounce, an animated platformer designed to fit in 280 characters. I was happy with the basic gameplay, but in order to fit it in such a crazy small space, it was pretty bare-bones. The EX version is fundamentally the same game, and still tiny at just over 700 characters, but with a lot of important game features added, including:
- Title screen
- Lives system
- Game over screen with restart
- Gameplay timer
- An improved ending (the original was by necessity super abrupt)
It's still missing sound because I haven't figured out how to make music yet, and when I tried adding a basic jump sound without music, it got monotonous quick. The game's a simple and straightforward platformer with no enemies or in-depth mechanics besides reaching the end in good time, and I don't plan to really change that outside of making a sequel. I'd appreciate any feedback on ways I could make it better and more engaging within those limitations, though. Thanks.
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
- Soft drop button (with slight delay when next piece appears)
- Reset button
Fitting everything in this small a space was really tough, but I made it. I had to cut a few corners, for instance there's no next piece preview, only one rotation direction, and there wasn't space for 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.
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?
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
After discussing base64 encoding in a recent thread, I decided to try my own version of it for storing level strings, but after some experimentation I started wondering how much of a storage benefit it really offers vs. hexidecimal. I also came across an old post from user Overkill from 2016, in which he concludes that unfavorable interaction with Pico-8's built-in compression basically negates base64's byte-per-character advantage.
I decided to perform a test of my own to measure the difference precisely. To do this, I used some web-based tools to generate random strings, using both hexidecimal and my own base64 character set, which uses as many 1-byte characters as possible (59, to be specific -- certain characters like small caps and glyphs use 2 bytes). I generated very large strings and pared them down just enough to fill the compressed data limit to 100.00% using each character set. I performed 3 trials each, recording how many characters would fit for each encoding type, then averaged these amounts for a general comparison. Results are as follows:
Base64: 15846 characters max.
Hex: 23230 characters max.
Base64: 15776 characters max.
Hex: 23261 characters max.
Base64: 15757 characters max.
Hex: 23275 characters max.
Base64: 15793 characters max. -- 11,845 bytes
Hex: 23255 characters max.-- 11,628 bytes
From these trials, the difference in byte capacity vs. compressed size appears to be about 2%, which suprised me. While there could be cases in which custom encoding offers various benefits, in general I think I'll stick with hexidecimal. For me, a negligible increase in storage efficiency is more than offset by much easier conversion to and from byte values and some degree of readability.
Join Squirt as he jumps and bounces in the sky through varying times of day, on his way to Cloud Land.
Features character and level animation, 60fps gameplay, and 150 unique screens of platforming-- all in 280 characters!
This is my first game for Pico-8 (or for any platform, for that matter...). I wasn't originally planning to try and fit a game in this small a size, I was just working on a platformer game test, but then I came across the concept of tweetcarts and things went in an unexpected direction.The game won't change a lot because I can't find any way of packing more in, but I figured it would be good to have some feedback before releasing. Thanks.
Hello, first post here.
I just got started with Pico-8 recently, and have learned about the usefulness of storing data in strings to get around token limits. I was wondering, can I build a data string using a p8 program, then output that string as text that can be fed into another p8 program without it being reformatted? I'm working on a graphical level-editor program that will output level data strings usable by another cart.
I tried using printh(), but when I opened the text file it mangled up the extended character glyphs and didn't preserve the 4x3 font lower-case letters I had in the string. My goal is to have all 121 characters available so I can store about 7 bits per character, instead of the 4 possible with hexadecimal, if this is possible.