When I was starting programming this Flash experiment by André Michelle really struck me.
It had beauty, conciseness, and I could see the (at the time really cryptic to me) code.
This cartridge is a humble and sort of crude hommage to this good memory
Ideas for performance improvement, increasing particle quantity:
- Maybe using QuadTrees to avoid looping through too far away neighbours
Use arrow keys to move Blob
Z to Attract
X to Repulse

Windy is really moody today... maybe the weather will get better if you play a little bit with her.
My first cartridge is this little physics demo.
Had lots of fun learning PICO-8 with this!
Sorry but there is no playability yet.
Who knows, maybe i'll work a little bit more on it.
Code will be updated over here: https://github.com/cauli/PicoBox
Changelog
0.0.4
- Now using a faster trifill algorithm by nusan (borrowed from Pico8 3d Renderer by orange451)
0.0.3
- Added ripple effect
- Jump with camera movement
0.0.2
- Improved stability by using sqrt0
- Reduced number of trifill seam glitches drastically
- Improved performance by reducing the number of tris/quad from 4:1 to 2:1, yet maintaining graphic quality
- Particles fly beyond the screen
- You can make Windy jump to nowhere using Z+X
Older versions:

I've kinds thought about this, but there aren't any true rules established, but instead just common sense.
I feel that should probably change.
So, I've got a short list of rules that I'd like you guys to read.
- No derogatory terms/imagery (racist terms, KKK stuff, et cetera).
- Cursing is allowed, but only in moderation. (Don't go on a raging session, folks.)
- No Spamming, trolling or excessive caps. (Trolling on the lines of asking questions like "Does a penguin fart?")
- Respect your fellow members and moderation team (whenever that happens).
- Post things in the correct category. By that, I mean:
Discussion is for general chatting, discoveries, and questions.
Editor is for the Editor, and the Editor only.
WIP holds incomplete carts and what-not.
Cartridges are where cartridges in a complete/presentable form are shown.
Collaboration holds topics for community/team projects.
Support is for problems with the PICO-8 Editor/Player itself.
It would stop execution and dump you into command mode. This would work like setting up breakpoint when you know that something doesn't go right after a specific instruction is executed but you are not sure what.
Example uses:
Stop() after changing the variable: Allows you to print it out in command mode to see if value change according to expectations (e.g. when dealing with imprecision of decimals or when you suspect integer overflow)
Stop() at the end of _Draw(): Allows you to display cart frame by frame e.g. when you debug graphics effects like particles that doesn't seem right.
And so on.
Of course after stopping cart you can then resume() it ;).
And before you ask, yes I know you can stop execution with ESC, but sometimes you need to stop it at the very precise moment which is hard to do manually and so something like stop() would be useful.

This is a reimplementation of a little graphic demo I first saw in the early 90ies on an Amiga500.
I have been writing that kind of demo on pretty much every platform I ever coded with since then.
Was good to see that something like that is possible on pico8 as well. Funnily enough, I pretty much ran into the same bugs, colour mixing issues and performance bottle necks as any other time I wrote a bouncy ball.
Enjoy!
Hi,
I got Pico8 today, I've just started toying around with it briefly and I'm having fun exploring other people's games and reading the forum. Incredible software!
One thing that I've noticed is that there are already various projects stuck because they hit the token limit (eg Underworld Siege or Kingslayer). Now, as a very young console not yet out of the alpha phase, I believe that no one has spent months on a single game and that a lot of things are still to be discovered and boundaries are to be pushed. Yet people hitting the (arbitrary) token limit is not very promising. For example, one of the two games quoted above is a LudumDare game. If someone can reach this limit in a one-week game competition, how can a project grow to a polished, full-featured game? I'm scared that this would prevent some kind of games (RPGs or adventures, for example) to be developed for Pic8, effectively making it less flexible that it could be.

I don't have something to post as a cart yet, but i'll post this capture of what i'm doing right now.
The animation has some color replacements to test the looks of the four turtles. This is the first iteration of how will look one of the three levels i plan to put in the game.
Updated:
Current status: Tech demo. Rewritten all sprite, frame, anim mechanics because i've hit all the limits at the same time :P
No bebop and rocksteady spawning this time, but it's useful to look at the changes i did to the code.
It has a HUD now.
A quick little puzzle game. The goal is to fill up the entire grid with your snake.
Directions:
First, place the snake egg using the arrow keys. Then press 'z' to hatch it. Once hatched, use the arrow keys to move around. The level will reset if you get stuck, or you can press 'x' to reset instantly.

With current one, playing 2 player games is downright impossible unless you have also a gamepad. Well, if you don't want to play a game of Hand Twister at the same time as well, that is.
So I'm proposing following mappings for the 2nd player:
Left: Numpad4
Up: Numpad8
Down: Numpad5
Right: Numpad6
Btn1: Numpad7
Btn2: Numpad9
Then our friend can sit at the side and while we're using arrows+z/x, he'd use just one hand to control the game.
This is exactly how I've set up second player in Nestopia, aside of mapping stert/select to Num+/NumEnter and it works remarkably well.






8 comments







