@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 SELF
references. 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?



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.






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.



Doing some teaching so I've added a bit to the sin/cos visualization here: https://twitter.com/MBoffin/status/905191907294199808


