8:00 AM by Sushicats
The objective is to make sure that the cars reach their destination and avoiding traffic jams.
Controls:
You move the cursor with arrows.
While Z is pressed and you move the cursor you place roads.
While X is pressed and you move the cursor you remove roads.
Tapping X on top of an existing road will cycle through some options, you can make straight roads one directional and you can add semaphores on top of intersections.

I started playing around with the shallow water equations and got to something that's maybe a little bit fun. Arrow keys make waves, Z switches boundaries between (approximately) open and reflecting. My implementation mostly follows https://graphics.ethz.ch/Downloads/Publications/Tutorials/2008/Mue08/coursenotes.pdf .
Current limitations/known bugs:
- Dissipates energy rapidly, although you'll probably only notice this if the boundaries are reflective.
- No handling of dry regions. Weird things may happen if depth goes to 0!
- Weird oscillations around both (nearly-)dry regions and shocks/big elevation changes. Not sure yet how much of this is attributable to bugs vs. limitations of the discretization I'm using.
- Liquid volume is not conserved. Not really a meaningful concept with open boundaries, but pretty noticeable with reflective boundaries.
- No wave breaking etc. Shallow water equations are a heightfield model and I don't think I'll get around to full liquids on PICO-8 any time soon. :)
I hope this cart is fun to play with! I'm hoping to fix a few of the items above, clean up the graphics a bit, and maybe find a way to build a little bit of a game around these dynamics.

| I love seeing work-in-progress screenshots.
The great thing about keeping these screenshots is that after the game is finished, you can tell in retrospect which screenshots were significant and interesting. Pico-8 encourages screenshotting, with its built-in screenshot and gif capability. And the file size is minimal. ... So I figure a lot of folk probably have cool early screenshots of games that later become great games. So let's see 'em! |

@zep:
Is this really the expected behavior?
> ?shl(1,32) 1 > ?shr(1,32) 1 |
I'd have expected 0 in both cases.
It works correctly for lesser shifts that push the 1 off of either end:
> ?shl(1,31) 0 > ?shr(1,31) 0 |
Seems like you're doing a modulo of the shift with 32:
> ?shl(1,33) 2 > ?shr(1,33) 0.5 |
Doesn't feel like the right behavior to me. Like, in assembly language, maybe, but not in a higher language.
PS: It would be nice to have bith arithmetic and logical shifts right, btw. :)

[previous: 44810]
Controls
Z to start, or X to skip all instructions.
Arrows move/dig through mine.
Z brings up map.
Commentary
This was going to be a maze game where you had a 'zoom in/out' button, and that idea was going great for a while, until I realised mazes are hard and I didn't know if I could do justice to a maze generator in the time I had. So instead it became a digging game, and grew in scope disgustingly until I had more work than the maze would have been in the first place. But inspiration will be inspiration I suppose.
Use your map to see roughly where the gold is, then make your way towards it, being careful to manage your truffles (food) and glow crystals (flashlight power). You can find both in the mine but you have to balance things carefully. At any time you can press Z to check the map, and see an indication of local tile types. Try to reach the gold before you starve!
itch.io page: here
Hi!
I'm new to Pico-8. I've been learning from the great carts very talented ppl publish here at Pico-8 BBS. I've just seen a demo doing pretty colorful spirals and wanted to test myself doing something similar in a per pixel color fashion.
The code is a pretty slow unoptimized version without look up tables or palette reordering, but, hey, it works!
Use left/right/up/down to tweak parameters.
Have fun!
-- 11/13/17 --
Soon. :)
-- 10/27/2017 ---
REMINDER! You've got one weekend left :)
To be specific, you need to finish your games at some point on 10/30 and upload them by/on 10/31. Don't worry about getting it uploaded exactly before the stroke of midnight or anything; this is a chill jam...
Buuuuutttt.... if you get your games in before mid-day on 10/31 and post the cartridge ID (that '[ # 02156489# ]' thing you use to display it in a forum post) in this thread (or send it to me on twitter, I guess -- @enargy)... you'll be happily surprised.
For reasons. :)
Trust me.
[evil, secret laughter]
As for our project, I still have a ways to go before making use of all of this amazing art by @castpixel but here's an update gif:
Good luck and happy jamming! Have a spoooooky weekend! I can't wait to check out all the things I've been seeing previewed!
--- 10/13/2017 ---
Reminder that the #3CJam -- the 3 Color Jam -- is running all month. Feel free to take a week. Or a day. Or even just an hour -- it's all up to you. Just make sure you only use 3 unique colors on-screen (at a time).
Here's some progress on the entry @castpixel and I are working on --

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.
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
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

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.


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?






0 comments

