Are you a PICO-8 tinkerer, but haven't been able to see a game to completion? Are your pixel art skills strong, but your code could use help, or vise versa? Do you just simply prefer to work as a team instead of solo?
Come join Picocity, a Slack team oriented towards working together to create finished works for PICO-8.
While I will proudly say there is no better resource for sharing carts and tips than these official forums, what I was really missing was an environment to motivate me to create finished experiences, not just tech demos or code snippets. Picocity came to be with the hopes that aspiring builders can help hold each other up and see carts through to completion.
Create an account and join us at picocity.slack.com
(Please note, this is not in competition or poaching from Neko250's team, you can, and should, participate in both! Picocity started on Twitter, and I only recently realized I probably should mention it here on the forums also.)

There is something I been trying to figure out how to make and it's been eluding me.
i am trying to make an ammo dispenser that activates on once ammo pack has been collected. So you grab a pack
it delays for some time, then spawn another pack and so on. Should be simple to do, but so far I am not having any luck with it.
Thx all

Hi,
the documentation states:
reload dest_addr source_addr len [filename] Same as memcpy, but copies from cart rom |
But if I read this from another cartridge, only 0 bytes are read into the current memory. Is this part of the documentation outdated or am I doing something wrong? Code would be simply:
reload(1024,0x4300,10,"tor_carttest.p8") peek(1024) |
while there is an empty function inside of the other cartridge...

A demake of MT-32 music tracks from Ultima VII, half-assedly arranged for pico8's 4-channel synth. This started out as a way to practice transcribing music by ear, but in the end I cheated and used the original MIDIs as a reference.
It currently includes only the diegetic music from the game, i.e. music that plays from instruments in the game world. I may try to squeeze in one of the longer themes from the game as well, though the cart is kinda tight for sfx space.

I'm surprised there doesn't seem to be a way to permanently write bytes to the memory and save it with the cart, so you can make your own efficient level storage format. That memory only becomes available to write to at run time - then any changes you make are reset.
My idea would be to have a level data format for a game that only shows one screen at a time (no scrolling) and has a stream of data that is - sprite cluster index (eg. 1 could be a group of trees, 2 could be a house) and an X Y position on screen.
I could kind of store the "level data" in the code by actually specifying screen positions but this is incredibly wasteful - each character is worth one byte, and I'd need several bytes just to set one position. Eg. "X = 54" is 6 bytes and I could store that in 1.
Am I incorrect - is there some way to store a sequence of bytes on the cartridge? (Besides the tiny "Persistent cart data")
In my game, having 5 sprites makes the game slower, in a strange way where every second frame is 1.9 CPU and every first frame is 1.0 CPU. This makes the game laggy - and things that should toggle on and off each frame appear to flash randomly due to every second frame being longer.
Adding 5 more sprites keeps the game at a steady 1.0 CPU! It runs perfectly smooth!
Is this a known issue?
Sometimes, we want to be able to play animations in reverse. This is the advanced animation function with a reverse option. In this case, the foliage grows, stays for 5 seconds before shrinking away (playing the "grow" animation in reverse), disappears for 10 seconds, then repeats.
Added coloring to show correspondence between currently-selected factor and its visual representation.
Controls:
Left/Right : select a different number
Up/Down : increase/decrease selected number
Z/X : make factorization canonical (sort in ascending order, no 1s)
In the original version of this, you could only change the product (and the factors would be calculated from that). In this version, you can change the product, but you can also arrow over to the factors and change them, too, which hopefully helps the user see relationships between numbers.
In the last post, we looked at some basic animation, collision and AI examples. In this one, we're going to take it a few steps further and improve upon these functions.
During the development of my game (tentatively titled "Castle of Thunder", which is a port of INTV's Thunder Castle), I realized that I was going to need some more advanced functionality, because the first enemy is a total of 4 sprites when walking horizontally, and 2 sprites when working vertically. Since we had all of our animation stepping, animation speed, frame numbers, etc stored as properties of our actor in our simple animation demo, it works great for 8x8 actors, but not as well when that actor is comprised of several sprites.
Further, I found that I needed to be able to specify x and y offsets for actors with multiple sprites, so that subsequent sprites can have custom positioning and aren't drawn on top of the first. I [i]also






6 comments









