I made this experiment back in 2020 and I finally decided to polish it up a bit and release it. Contains:
-Speed!
-Momentum!
-Horizontally looping level
-Loops!
-Damage!
-Collectables!
-Music!
-Rain!
Source code should be somewhat readable. It's mostly done using the Sonic Physics Guide as a reference. http://info.sonicretro.org/Sonic_Physics_Guide
Also out over on itch.io: https://geeitsomelaldy.itch.io/tosh-the-haggis-pico-8-experiment
So I'm reading the docs about pico-8's memory space.
https://pico-8.fandom.com/wiki/Memory
Am I reading this right and the game code is not in addressable space? I wanted to "read" the program code at runtime using peek(...) is there any way to do this?
There's a section on that page talking about Lua memory, and separate from the pico-8 memory space. The way it's described it sound like runtime memory space for variables etc. Not what I want.
Any ideas?
Mitt's Marble Adventure!
Explore the town of Townton and the surrounding area and battle EVERYBODY* in intellectual duels of marble supremacy.
*You cannot battle mom or the dog, sorry. But you can pet the dog.
This cartridge is part of the Twelve Days of Pico Christmas, our Advent Calendar project for 2021. https://www.lexaloffle.com/bbs/?tid=45525
Stuck? Open the spoilers for some hints:
Holiday season, stuck at home waiting to open presents?
Despair snow more, a play of totally accurate bowling will enjoy the day!
Devlog
Codebase expands from Ghost Rally, no longer limited to a single dynamic/static response.
Collision hulls are limited to solid rectangles to benefit from simplified overlapping tests and clipping maths.
The whole engine could be plugged into any 3d engine if you don't mind the staggering token cost :/
Sources are available at: https://github.com/freds72/chamboultout
The game went through multiple iterations (initial idea was a "chamboultout"), including odd things like:
TO LOAD THIS PICO-8 CART, in immediate mode, type:
load #tweetpaint
VVhat's new ?
✅ (12-21-21) Always have white cursor, suggested by @fsdsdsffs
[8x8] | |
What with the Christmas holidays coming up there's a good chance a bunch of you may be stuck in line in some grocery store or shopping mall so - having seen all the little paint programs rolling around, thought I would write up my own for you to test your art skills in as you're waiting to make your purchases.
512px under
Year 4096. A burried building with lasers and traps. How many lives will it take to leave this place ?
- Jump, wall jump and dodge lasers
- 18 memory cards to collect
- 32 rooms to explore (with lasers in them)
- Auto-save
- 1 red cube
- Lots of lasers !
Controls
- Arrows : move
- V (or X) : jump
- C (or Z) : grab/drop
Move and jump
Grab and drop
Wall jump
About
This game is my first Pico-8 game. It is also the first game I manage to finish after a few attempts with game engines such as Unity and Godot. It took me 1 month to complete the first published version. The Pico-8 restrictions allowed me to define a manageable scope for this game. In the end, I used the entire space available in the map editor and the spritesheet editor. The code uses every token allowed.
I've hit a really bizarre error; my code has no coroutines, but it fails with "attempt to yield from outside a coroutine"
I've simplified it down as much as I could; while removing unrelated cruft (e.g. the sort
function from my new project template that I wasn't actually using anywhere) the bug would arbitrarily appear or disappear.
The bug will either get triggered 100% of the time or 0% of the time when you run the cart, but its presence or disappearance arbitrarily changes depending on what other unrelated code there is in the cart.
For example, tab 0 is 15K of function foo() end
repeated over and over again. They're commented out right now, and the bug is present. If you comment them back in, the bug disappears.
Commenting out the body of pqb
(which prints many many u64 objects) seems to remove the bug for good (no matter how many foo
s I comment in or out). I'm not too experienced with metatables; I think I may be at fault for something I'm doing inside u64.__tostring
? sometime variation of this code give a slightly differently-formatted error message that jumps me into the middle of my __tostring
method. or maybe printh
is having issues dumping so much text to the console? I dunno