I'm not sure if this was a style choice, but the PNG format is a container format and supports ancillary tags for proprietary meta data. This is how Spore stored creature data inside the picture.
This will give you more flexibility in the future when it comes to storage size, color depth, and not losing fidelity when it comes to the screenshots in the container.

There is a strange bug in v1.1 that returns a decimal value when I do this:
FOR I=0,3 DO K = PEEK(I) L = BAND(K, 15) H = SHR(K, 4) PRINT(L) PRINT(R) END |
The output is:
0 1 2 3.125 4 5.25 6 7.375 |
My assumption is rather than converting to an integer and shifting, you're returning i / 2^s without casting to an integer in the result.
Before I'll ask the question, I'll tell you something so this makes a little bit more sense.
In original Super Mario Bros game for the NES, levels had something called "blocks". Each "block" represented one level feature - be it first mushroom on 1-1 or end stairs after each level. Every block had unique id and actual level was just 1d array that showed what "blocks" in which order were making that specific level.
It would look something like this (in P8 terms):
level1 = {0,0,1,4,3,7}
|
and blocks would be defined in map space. Each block having couple of tiles
It was done, obviously, to save cart space in order to make bigger game.
I plan to do something similar for my next game (after Heavy Duty Sprinkler will be done, which is my "learning" game), however I don't know how I would detect collisions.
Let's say each "block" is 8x16 (WxH, in tiles). Drawing those, no problem, just something like this:
map (8*blockid,0,0,8,16) |

I've been tweaking around with pico-8 for around a week now, and it's reminded me many times of a game called Hammerwatch. One of the cool features it has is a quite good selection of graphical post processing effects simulating a CRT tv.
What I'm suggesting is to add similar effect, separately from the games, treating the pico-8 program kind of as an emulator. This way you could really get the old-school wibe going.
As for what effects I'm talking about, pictures speak better than words.
And before you go, I'll leave you with this.

Oh noes! The fire had started at the Warehouse! And there are people there!
enter...
HEAVY DUTY SPRINKLER!
The ultimate AI, sentient fire extinguishing tool!
Control it with LEFT and RIGHT arrows and rain water by pressing Z!
Don't overdo it though, as water is precious and for any unit of water used, you'll have to hang on for another second before firesquad arrives!
You need to save PEOPLE, by putting out any fire that is WORTH 5 POINTS. Don't rain on people too much, as water is under HIGH PRESSURE and if too much of it lands on a person, it'll PEEL THE SKIN OFF!
After each LEVEL you'll be presented with screen that will show how many PEOPLE you SAVED (each of these worth 15 POINTS added to your SCORE!) and how much of WATER you used (not necessarily in that order).
For every SAVED LIFE you'll be saved 5 SECONDS of waiting on the next level!
I am not a big fan of my music.
[b]Credits where credits due:

Pretty much like C64 allowed it. Changing the font would have few limitations compared to using spritedata:
- Each character would be 1-bit ONLY (e.g. pixel is either on or off)
- Changing characters will affect how code editor and command mode is rendered (mainly to give you live preview of your changes) so if you like writing in flowers and bushes, that's your problem ;).
This would allow to customize our games even more.

This has been my little baby over the past week or so. It started with jotting down the train game by @PROGRAM_IX from the Pico-8 zine #1, and then making it my own. I ended up using over half my tokens, two sprite banks, and the entire map space. I will leave it to you to discover its mysteries. Playing alongside a warm beverage recommended.
v1.1: Small update to effectively double the rate you gain resources.

Hello, I've got Pico-8 and playing around with it right now. However, when making music for the game, I've encountered a problem: when sounds have different speeds, they don't line up properly and there's a pause until slower one finishes playing. Well duh? But here's a thing: In "slower" sound I didn't use up all the lines and "actual" sound ends well before faster sound (background bass) plays out.
While I agree sometime pause may be important, I'd strongly prefer if "stop right there" effect would be added that stops sound on that specific line instead waiting until its "natural" completion (all lines played out).
Hi guys:
I have a project that fits perfectly in PICO-8 because is an easy platformer for children. But I have a doubt that gives me two questions, because visual design is important in this game. It has HUGE sprites, but pixelated ones, for example, the protagonist is about 15x20 pixels, but I've envisioned him looking at x 1000% of zoom in a full HD monitor.
So for PICO8 I think he will show ok at x2 or x3. So how could I do this:
1) big sprite. build the srpite as 30x40 pixels heigth sprite. PICO could move sprites so big?
2) If not, make an engine with a camera that shows the game at x2 or x3 zoom. Is this possible?
Thanks.
Ah! one last question, is it possible to add a postprocessing filter to a game? for example, to have scanlines. That is semitransparent graphic that filters the screen.
Regards.
Fight against wave after wave of hostile alien space droids to protect galaxy command from an invasion.
New Features:
- three different enemy types with individual behaviour
- added a shield to the ship, that recharges over time
- balanced the difficulty (made it a bit harder, since you have a shield now)

CONTROLS:
- LEFT and RIGHT arrows to MOVE
- Z to shoot
This is my first pico-8 game :) Every time I tackle a new game dev tool I like to do my own game version of "Hello World" to learn the basics: a simple space shooter.
It features sprites, input, sfx, background music, score, etc.
Tomorrow I'll be posting a step-by-step tutorial on how to create it.
It's only one day tinkering with it, but I'm truly enjoying pico-8!
Hi all,
I'm having a great time poking around Pico-8, and coming from the NES development world, a lot of the constrained programming makes sense. But my last sticking point is scrolling—I understand how maps work, and I can create a screen-to-screen transition effect by changing the offset into contiguous map data, but I can't figure out how to scroll smoothly 'across' map data. When I attach the camera to the player's position, I travel off the first map and into a weird glitchy void.
Does anyone have a simple example of how to implement scrolling? I've downloaded several example games, but everyone seems to have a different approach, and they are difficult to parse in a fully-functioning game.
Thanks!

This bug seems to be specifically around up/down arrow key handling.
When typing in the editor, pressing the down arrow key and (while the arrow key is still held) pressing another key causes the editor to act like the down arrow key is pressed twice. The same behavior happens with up.
Steps to reproduce:
1) Open some existing document in the code editor.
2) Press (and hold) the down arrow key.
3) Quickly after, press another key, such as delete.
Expected behavior:
The editor interprets the keystrokes as 'down arrow', 'delete'.
Actual behavior:
The editor interprets the keystrokes as 'down arrow', 'down arrow'.
Environment:
PICO-8 (Alpha) v0.1.1
Mac OS X 10.11 Beta (15A262e)






26 comments







