Per this thread, I wanted to figure out a method for pixel-perfect collision for a project I'm working on, and snaggled the in-project attempt so badly that I decided to start from scratch in a separate cart. This is the result, a little demo that shows pixel (and basic box) collision feedback in real-time on a couple of sprites.
As far as I can tell, the collision test is accurate under the assumptions this cart makes: each sprite is an 8x8 sprite referenced directly off the sprite sheet by sprite number, and any non-0 pixel is considered solid. But beyond that I am making no assumptions about it: I'm sure there are cleaner/faster/neater implementations of the same idea, and I'd encourage anyone who feels like taking a shot at cleaning it up to go for it.
This should also in principle be generalizable to arbitrary rectangles of sprite sheet info for e.g. larger multi-tile player sprites, and in fact I made some progress last night trying to generalize it, but that hasn't totally come together. Anyone who feels like tackling that, go for it.

Hey there, I just wanted to have a very quick play with PICO-8 and this seemed like a fun quick test. Single "large" sprite blitted across the screen while being flipped at random, no interaction. Pretty simple and painless, based on an old screen-saver.
Now onto something a bit more involved (but I expect not much).
This is again just a test for the web player, both on the music playing and the gfx rendering. I couldn't get the renderer to render a 1x1 thing, but I haven't tried too hard and I have absolutely no idea of what I'm doing when it comes to high perf pixel pushing. My hope is that this will be my first proper music release for the Pico-8, hopefully in August.

Seeing screenshots of 3d[-ish] games here and there, a question arises - how does one draw filled triangles, and does so efficiently? I have tried porting one-before-last-step algorithm from here:
http://forum.devmaster.net/t/advanced-rasterization/6145
which resulted in this little monstrous function:
https://gist.github.com/YellowAfterlife/34de710baa4422b22c3e
but, alas, the math is just too much - it can barely draw half of screen worth of triangles before CPU use reaches 1.0. And that's before there's even any game!
I'd appreciate some pointers towards algorithms more suitable for pico-8. Or any help, really.

I've only ever done really minimal/logical collision stuff in games, so more general collision strategies are still sort of mystery meat to me. I'm working on a little test idea with a ship flying near uneven terrain that the player will need to avoid colliding with, and I'm trying to work out a good approach to doing that per-update collision test between the ship and nearby terrain.
If I've got a ship sprite, and a given nearby sprite of map where only a portion of the sprite is solid ground (say, a diagonal chunk of hill), how might I approach writing a collision detection routine for the two? Something using pget for the ship and terrain sprites and appropriate x/y offsets to check for any case where both pixels are non-transparent?

small grid roguelike.
Press z to use items that you pick up, each inventory slot can only be used in the direction it is picked up in. Complete quests for bonus points!
8 ITEMS! 3 ENEMIES! 3 QUESTS!
changelog
0.5
fixed long standing "out of memory" bug
tweaked quest bonus
added highscore saving
0.4
quest where you have to bring at least 3 potions to the exit
enemy that waits until it sees you, at which point it paths towards where it last saw you
0.3
fogs now effect the enemies that they are throw at
better memory management (maybe)
in game sound effects

I can't for the life of me figure out how sound effects or music editing works! Does anyone have any information anywhere? I suspect that if I already knew how any other tracker worked I would be able to understand this, but I do not.
I read what the manual said but it is too abstract. Can anyone give just a little more information?
Thanks

Vomit Comet
By XenosNS
When you are a simple comet, minding your own business while flying through the cosmos, the last thing you want is to fly into a large vomit nebula. Unfortunately, this is exactly what has happened to you.
Use arrow keys to avoid the vomit.
Each time you hit vomit, your tail reduces. If your tail disappears, the game is over.
Grab a barf bag to restore a piece of your tail.
Created for the Halifax Game Collective pageant with the themes of "continuous motion" and "two words that rhyme"
updated version. Removed the ability of the barf bag to clear vomit due to memory error

EDIT: NEWER VERSION
I just found out about PICO-8 yesterday and spent last afternoon and this morning learning about it and making this simple game! I already knew enough Lua to figure it out pretty quick. I might make an update with sound and/or particle effects and I might also just make a whole new game, not sure yet! Anywho, it's a 2-player TRON game you win by making your opponent crash into a trail or the side of the screen have fun!

An implementation of Conway's Game of Life cellular automata.
Wikipedia: https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life
Game of Life wiki: http://www.conwaylife.com/wiki/Main_Page
v0.1: Initial version. GoL simulation uses the screen itself for storing cell data, using the two-line buffer method, with null edges.
v0.2: Pattern library. Audible feedback. Small bug fixes and performance improvements.
v0.3: Performance improvements. Pattern placer now lets you stamp multiple copies until you cancel. Simulation displays a generation count. Small visual changes.






2 comments





