#pico-8

[wingedrobot]

I updated my Kirby avatar!

[boringkate]

I made a Pico-8 demake of one of my old Wii homebrew games today (which I think also had a PS3 release). It's just a simple square avoiding thing, but it's fully playable for free in a web browser. You can even play it on a phone. You can also download the "cartridge" if you wanna play it offline on a handheld or something. Enjoy!

[mogwaipoet]

Look Who's The Shining Two! was made on a game jam deadline

So it didn't get my usual leisurely playtest cycle. It shipped rough as a result, but I think it's in pretty solid shape right now thanks to everyone who sent in feedback.

I wrote up a list of changes made since launch here, if you're interested.

[lucky-vii]

I made a full pico-8 game for artfight!! VOXphi's character got me so inspired that I made the whole thing from scratch in 2 days >:3c

might post the code somewhere if i remember to :p

[mebrob]

another pico-8 screenshot mockup with item samples! and the rebirth cast :)

[addiekinstudios]

I've been trying to finalize this game btw, its been a lot longer of a road than I had ever anticipated.

This was just supposed to be a single month project... And then 5 months later, still not done..

Not sure exactly how to feel about this, we shall see once it is completed and I get some more people to play it.

I also recently reworked how the buildings are drawn giving them more definition and detail as I work on the building system. I'll add a little clip below showing that and if you thinks its good please leave a note.

There is still more to do, as I need to actually place the walls around the floors and other internal things for the buildings. One big issue is door placement and identification.

I think the biggest hurdle I have been running into has been the token limit in pico-8 and trying to minimize the amount of tokens I am using. It does very much feel like a interesting lost art from back in the cartridge days. Where you had limited space for things, I have gone threw a bunch of creative spurts on ways to minimize the tokens.

Its definitely an interesting challenge, and surprising how much i am fitting in a single pico-8 cartridge. I have been at the token limits for a while now. I have exceeded the compression limit a couple times as well, though I have a good amount of comments still taking up space, so not fully at that limit.

I feel like this needs to be done, its weird because there is more to do and I cannot wait to get to that point, and of course a laundry list of things to do. There has been some slowing down of work though. As the limits are reached, and I run out of ideas for a short time.

Its amazing though that you can just give your brain time to work on the problem and when you are not paying attention you'll suddenly get a new idea to try. And then that will push things forward again.

The unfortunate thing about our society is that we do not accommodate this process. We tend to try and force the creativity or solutions. The human brain is a capable machine that requires good amounts of food, sleep, distractions, and more in order to come up with solutions.

[picorobot]

[e1sif]

if g_witch was a pico-8 game

[systemst91]

https://cz.pinterest.com/pin/1051098000508999673/

[highly-nonexistent]

ilo sitelen pona!!

ilo Pikowe (Pico-8) la, mi pali e toki lawa ilo tawa ni: sina ken kepeken sitelen pona!! toki lawa ni li kepeken nimi Token 111 taso, li ken ante, li kepeken nimi P8SCII. sina li wile ala kepeken e sitelen Spritesheet !!  ni li pona tawa sina la, o pana e ni tawa jan ante !!

I've made code for Pico-8 that allows you to use sitelen pona!! This code only uses 111 tokens total, is customizable, and uses P8SCII, meaning you won't have to use a single slot in your spritesheet for it!!  If you liked it, please feel free to share!!

https://www.lexaloffle.com/bbs/?tid=52489

https://nonexdog.itch.io/ilo-sitelen-pona

[picopup]

Catfacts: A collection of 50+ very true cats about facts.

A collab between me and @sapphiconoclast!!

Presented in stunning Picovision!

Coming soon to a web near you!

[modernmodron]

a birthday capybara for @bugbearstew !

[boringkate]

I made a browser based game about a babe with a sword :3

It's a little less fully featured than intended (btw nothing happens when you beat all of the monsters) (I'm still new to pico8 and I handled storing the map is a way that ate up most of my allotted tokens + I had already been working on it for a bit more than a day, so I just wanted to post it), but I could see myself going back to it to do a big up date or a sequel or something (with multiple areas, an exp system, and maybe even a bit of a story)!

Let me know what you think!

[mogwaipoet]

On the left is the sprite sheet for the Pico-8 game I made for my wife for Christmas 2016

On the right, the sprite sheet for the sequel I'm currently working on.

You'd think "of course you'd get better with 8 years of regular practice" except this difference is like 2% practice and 98% adoption of a process:

Look at a lot of reference art

Just keep on stirring the pixels around until it looks good

Notably step two doesn't really scale so working on subjects bigger than 8x8 is terrifying to me 😂

Reference art is hugely important, as it turns out. You know how the 90s Rare games everyone loves only had like four biomes? It's because they only had one shelf of reference books and Twycross is too remote to drive to the library.

[blubadventures]

Fonts

Today we're going to get very technical and talk about custom fonts in PICO-8. I know I just made this blog, but we're taking a deep dive right away because it's one of the first things I did in my game, and it's still fresh in my mind.

PICO-8 ships with a default character set called P8SCII (a pun on ASCII) that includes 256 different characters. This set includes uppercase letters, lowercase letters, numbers, punctuation, hiragana, katakana, various control codes, and other special glyphs. You can see it below.

The default font has some pros and cons. If we focus on the uppercase Latin letters, punctuation, and numbers specifically, all of the characters conform to a 3x5 pixel size. This is very space efficient and consistent, which makes it an excellent font for writing code on PICO-8's tiny 128x128 screen.

Code is written in "all caps" so to speak, although the concept of uppercase and lowercase letters doesn't really exist in PICO-8 programming. Instead we have normal letters (seen above) as well as an alternate set of 26 characters called "puny characters," which looks similar to the regular font but even smaller!

So it works great for coding, but what if we're reading a lot of English words? Here's an excerpt from Homer's Iliad written using the default font, with regular characters for uppercase and puny characters for lowercase.

It doesn't look bad necessarily. I'd even say it conveys a certain amount of retro charm. But I'd be lying if I said it was easy to read.

Enter custom fonts! This is a relatively new feature of PICO-8, and it is one that is a little bit complicated to implement and not very well-documented at the moment, but I'm going to do my best to explain it.

Unfortunately, you can't simply have your custom font loaded and ready to go by setting it up in the cart itself. Custom fonts are defined by messing around with specific memory values at runtime. I'll explain an easy way to actually create and load your own font in another post, but for now lets talk about the memory addresses that need to be modified and how it works under the hood.

First of all, custom fonts must be enabled with the following poke:

poke(0x5f58,0x81)

Address 0x5f58 contains the bitfield for the current character rendering mode. There are a few options, but the ones we care about are 0x01, which enables special rendering modes entirely, and 0x80, which enables the custom font.

Once enabled, all future printing operations will use a custom font that is defined in RAM from addresses 0x5600 to 0x5dff. That's 2,048 bytes total. Remember that there are 256 different characters in P8SCII, so that's 2,048 / 256 = 8 bytes per character.

Each character in the custom font can be as large as 8x8 pixels in size. Each of the 8 reserved bytes for a character represents a row of pixels, and within each byte, each bit represents whether the cell is filled or not, with the least significant bit being the leftmost column.

Here's an example. Capital T has index 116 in P8SCII. 116 x 8 = 928, which is 0x03a0 in hexadecimal, so the custom font for T is defined at 0x5600 + 0x03a0 = 0x59a0. Here is how I have defined T in my custom font.

peek(0x59a0) = 0b00011111 = '#####---' peek(0x59a1) = 0b00000100 = '--#-----' peek(0x59a2) = 0b00000100 = '--#-----' peek(0x59a3) = 0b00000100 = '--#-----' peek(0x59a4) = 0b00000100 = '--#-----' peek(0x59a5) = 0b00000100 = '--#-----' peek(0x59a6) = 0b00000000 = '--------' peek(0x59a7) = 0b00000000 = '--------'

(Remember, the least significant bit is the leftmost pixel drawn, thus the binary representation and the actual drawing appear to be mirrored.)

It doesn't look great on Tumblr, but hopefully you get the gist. As you can see, this character is 5x6 pixels in size. But how will PICO-8 draw this? The two highest addresses (0x59a6 and 0x59a7) are still empty, and there are also still 3 columns of space on the right. Obviously we don't want the T to be floating in the air or have a big gap before the next character is printed, but how would PICO-8 know that?

Here is where things get more complicated. There are two components that define the actual size of a character.

The default size of the entire custom font. This defines a height and width which applies to ALL characters in the custom font.

An individualized width and height offset for all characters. This is a newer feature than the above, and it is what allows us to make variable-width fonts! Because it's newer, you'll see a lot of resources on how to do #1, but resources for how to do #2 are relatively sparse, at least at the time of writing!

Where do we define this stuff? Remember when I said that we have 8 bytes for each of the 256 characters in RAM for defining the custom font? There's a slight asterisk there, which is that the first 16 characters in P8SCII are never actually printed. These are called control codes and they represent various printing functions, not text. They do have a graphic in the first image I posted, but they are never actually printed. Therefore, the bytes in RAM reserved for these first 16 characters may be freely appropriated for other uses.

Font-wide settings are stored in the data reserved for character 0. We can think of this as the "font header". Each of its 8 bytes have different purposes. I'll outline them explicitly.

0x5600: Pixel width of characters 16-127. (Mainly Latin letters, numbers, and punctuation.) 0x5601: Pixel width of characters 128-255. (Mainly special glyphs and Japanese letters.) 0x5602: Pixel height of all characters. 0x5603: Draw offset x. 0x5604: Draw offset y. 0x5605: Set 0x1 to apply size adjustments (see below); set 0x2 to apply tabs relative to the cursor. 0x5606: Pixel width of tabs. 0x5607: Unused.

I'm just going to focus on 0x5600 and 0x5602 here, but you can experiment with other values as you wish. When designing my font, I found that 4 pixels wide generally looked pretty good. However, we also have to account for a gap between characters, which I would like to just be 1 pixel, so our actual character width should be 5, which is the value I poked to 0x5600.

For height, Latin characters vary quite a bit. For most tall characters, like lowercase d, I made them 6 pixels tall. However, some characters like lowercase g are meant to be drawn partially "below the line" when written on paper, so I had these characters dip 2 pixels deeper. Here are some examples.

Since we have characters that extend to both extremes in terms of height, we can say that overall the font is meant to be 8 pixels tall. Furthermore, I once again want a 1 pixel vertical gap when printing to the next line, so we'll say the height is technically 9, which is the value I poked to 0x5602.

But wait! What about the characters which are extra wide, like our uppercase T? That was 5 pixels wide, not 4, so won't it get chopped off? The answer is yes. (Technically, the entire T would still get printed, but we would lose the 1 pixel gap before the next character.)

This is where the per-character width and height adjustments come into play. Remember the data for character 0 formed our header, but we still have characters 1-15 whose data is still unused. That's 15x8=120 bytes. We have 240 printable characters (17..255). Therefore we can allocate one nibble (that is, 4 bits, or half a byte) for each printable character. The lower nibble in each byte will correspond to the lower of the two characters represented by that byte.

The 3 lowest bits in the nibble represent the width offset for that character as a signed 3-bit integer, for a range of -4 to +3. This is what will be added to the default width when determining the actual width for that specific character. The highest bit is used for a vertical offset; if it is set, the character will be drawn one pixel higher than normal.

Finally, to enable these per-character adjustments at all, the lowest bit of 0x5605 must be set to 1, as mentioned previously.

Let's see some examples. Remember that the T we drew earlier was 5x6. Or rather, it's 6x6 if we include the 1 pixel horizontal padding on the right side. But our default width is only 5. Therefore we need to set T's offset to +1.

We have to do some fairly complicated address math to figure out where T's offset lives. Remember its P8SCII index is 116. Among the actually printable characters, its index is 116-16=100. Offset data begins at 0x5608. Remember each byte corresponds to two characters. 100 (or 0x64) is an even number, so it is going to live in the lower nibble of its corresponding byte, which is located at 0x5608 + 0x64 / 2 = 0x563a.

T's roommate is character 117, which naturally, is U. The U I drew conforms to the standard width of 5, so its offset should just be 0. Across the board, I'm not using any height offsets, so those bits will always be 0. Therefore, our offset for T is achieved with the following poke:

poke(0x563a, 0x01)

Lets pick a more complicated example: lowercase L and M. Let me show you what I drew for those first.

Both of these characters have nonstandard widths. Worse yet, they're roommates! L will need an offset of -2, and m will need +1.

L's index is 76, and M's is 77. Their offset data will live in the same byte, with L taking the lower nibble. The address of this data is given by:

0x5608 + (76 - 16) / 2 = 0x562e.

M needs a width offset of 1, which is simply represented as 001 in binary. L needs -2, which is represented as 110 using two's complement on a 3 bit integer. Again, both should have a 0 height offset. Putting this all together, our poke will be:

poke(0x5626, 0b00010110)

Or in hex:

poke(0x5626, 0x16)

Or even in decimal:

poke(0x5626, 22)

Anyway, that's my overlong explanation for how custom fonts work. Now let's see the custom font I made in action, side-by-side with the default font.

Not bad! Personally, I find this dramatically more readable, but it does come at a cost: it takes up way more vertical screen space than before.

[mebrob]

hypothetical binding of isaac demake for pico-8