Original here. I wonder how obscure this is. I first saw it floating around like a decade ago now. If you recognise it, then... enjoy.
I'd been working on this video encoder thing for a few days and it turned out this clip compresses really well, likely because of big blocks of colour and not that much movement. And so I decided to make a cover as well.
I need exact change only...
Heeeere's fiiive buuuuucks.
5 comments
Hey there!
This is our first game made in pico-8!
Made in under 24 hours as a way to learn the basics of pico-8. It's pretty cool!
The game works and has a win condition, which is a victory in itself :)
pico-8 was so much fun, challenging and very rewarding.
Let there be more!
See you all soon,
Sankaku Games
0 comments
I've become unhealthily interested in image compression on Pico8.
Hit the "z" key to see the next image.
What we have here is something that might resemble the JPEG compression scheme if you squint.
Compression goes like this:
--Discrete Cosine Transform + Quantatization
--Zigzag encoding of blocks
--Huffman encoding
--Run Length Encoding
--Conversion to a base 64 character set
--Overall compresses to around 1/5 of original 8-bit grayscale size.
What didn't work well:
Image quality is kinda low. There are only about 16 levels of gray that are discernible on pico8 with dithering. Not sure that it makes a lot of sense to encode 256 shades of gray in that case. Not to mention that the image quality at 64x64 is pretty lame to begin with.
This path may be a dead-end because I can only get about 12 64X64 images in here before hitting compressed code limit. If I drop the base 64 coding, I could fit maybe 10 images into the sprite area... Because Pico8 compresses data as well (definitely with better algorithms), my compression may be working at cross purposes to Zep's compression. I still need to do an experiment to see whether the base 64 encoding is any better than the base 16 coding.
I've got some glitching in the bottom right blocks.
Here's the compression script: https://github.com/electricgryphon/pico_8_jpg
Perhaps this will inspire someone to greater image compression heights :-D.
-Electric Gryphon
13 comments
Hello,
(scuse for my poor english ;))
This is my first game. created with pico-8.
A small remake of space invaders
I learned to program games for a few weeks on pico-8.
To play :
Directional key (left / right)
"x" key to shoot
thanks for playing
Brachius
edit : fix ultra speed on level 2 xD
4 comments
Rhythm Game made in about 50 hours for Music Game Jam. Team of codyloyd and myself. First jam for both of us.
Hit the buttons to the beat while avoiding the asteroids.
2 comments
I previously suggested that you pretend the 32k of lua token ram was filled with 16-bit tokens, rather than 32-bit, as that would make more sense in the limited address space and no one would ever have used a 32-bit token architecture on an 8-bit hardware architecture. That way we'd get 16k tokens instead of 8k.
I, uh, got no traction on that one, from what I could tell. ;) Gotta try, though, right?
Here's a less-significant proposal:
To encourage people to learn and use object-oriented programming, how about taking your token-pruning shears to any token that (de)references SELF? As it is, it's super prohibitive to put accessors or any simple functionality inside of class methods because of the token overhead of all the extra SELFreferences. The real-world justification would be that a compiler typically keeps self/this in a register.
Seems like other things already favor using classes, e.g. the relaxed timing on top-level table-member references. Maybe this would be consistent with that?
4 comments
I'm any of the pico-8 pros so I probably won't use Peek and Poke, but can I please get an explanation. The Wikia doesn't really help
9 comments
I'm using stat(1) to see what type of CPU usage my game is using and in certain spots it's a lot, sometimes hitting 100% and causing some serious jitters.
When that started happening, I went back through my code and did some refactoring of things...removing dupe code, nesting conditions, removing methods, limiting loops per tick...and that helped.
I'm not so dumb as to not realize that bloated code will impact CPU usage, but what else increases that usage?
Maybe that's a big question...I dunno, I'm looking for a somewhat high level answer, I guess. Just general "things to pay attention to" kind of stuff.
I'm not using any fancy techniques like poke/peek or memory storage or anything like that. Very straight forward coding. I don't feel like my game(s) are very complex or doing a whole lot, which tells me I'm probably missing something in managing overhead.
14 comments
A prototype puzzle platformer with 13 levels. It explores the use of alternate worlds/views on the same level as the main game play mechanic.
It's a complete game, but with the limited space, difficulty ramps up pretty quickly to try out different puzzle ideas and game mechanics.
Arrow keys to move, up or C to jump.
The X key (or other button) comes into play a bit into the game, I won't give it all away.
2 comments
Doing some teaching so I've added a bit to the sin/cos visualization here: https://twitter.com/MBoffin/status/905191907294199808
3 comments
Okay. So, I am brand spankin' new to coding. I am not quite sure what the proper lingo is.
I am attempting to create a sandbox game, but I have no idea how to make it so that when players reach the edge of the playable screen, they can then continue on into a new screen. "Space Delivery!" and "Carmina's World" accomplishes this.
Please let me know if I am not articulating this properly. Any help is appreciated.
This is all of the code I currently have:
player = {}
player.x = 60
player.y = 60
player.sprite = 0
player.speed = 1
player.moving = false
player.timer = 1
function movex()
player.moving = true
player.sprite += 1
if player.sprite > 2 then
player.sprite = 0
end
end
function movey()
player.moving = true
player.sprite += 1
if player.sprite > 18 then
player.sprite = 16
end
end
function _update()
player.moving = false
if btn(0) then
player.x -= player.speed
movex()
elseif btn(1) then
player.x += player.speed
movex()
elseif btn(2) then
player.y -= player.speed
movey()
elseif btn(3) then
player.y += player.speed
movey()
end
if not player.moving then
player.sprite = 16
end
if not player.moving then
player.timer = player.timer+1
end
if player.timer >=30 then
player.sprite = 3
end
if player.timer >=60 then
player.sprite = 16
player.timer = 0
end
if player.moving then
player.timer = 0
end
end
function _draw()
map(0,0,0,0,16,8)
map(0,0,0,64,16,8)
spr (player.sprite, player.x, player.y)
end
|
1 comment
Okay. So, I am brand spankin' new to coding. I am not quite sure what the proper lingo is.
I am attempting to create a sandbox game, but I have no idea how to make it so that when players reach the edge of the playable screen, they can then continue on into a new screen. "Space Delivery!" and "Carmina's World" accomplishes this.
Please let me know if I am not articulating this properly. Any help is appreciated.
3 comments
After seeing https://www.quaxio.com/tron/ I wanted to see the smallest version we can do in PICO-8
Currently 251 characters
I'm absolutely sure we can do even better!
(Yes it is useless, yes that probably the lamest game on earth, but who care? :D)
5 comments
Here's a cart containing all the music data from my recently released game "地獄・Hell", an entry into the "A Game By Its Cover 2017" jam on itch.io. The game itself was designed to run in (a slightly modified version of) picolove, and takes advantage of some of its nonstandard features, and thus I can't post the full cart here.
Interesting note: picolove's reimplementation of PICO-8's sound engine isn't perfect, so the sound ends up having a somewhat different character. In particular, the difference in the way the fast arpeggios behave (especially in track 26) is quite noticeable.
0 comments
Step into cyberspace with cutting-edge 3D vector graphics. Battle tanks with your triangular pew-pew cannon. Explode into a number of polygons.
This is an homage to Specter VR, which came packaged with my Macintosh Performa back in the day.
https://www.mobygames.com/game/spectre
Features:
-60 fps
-Motion blur effects
-Blue/Red 3D glasses mode (it actually works)
-Multiple camera modes
-An attempt at writing title music
Issues:
Gameplay is a bit, well, simple. Basically drive around shooting and being shot at.
--Electric Gryphon
12 comments
