I have a routine where I'm checking a pixel color at a certain x/y to determine whether or not to place a new sprite there. If it's black, it's open; if it's white, it's unavailable. I'm doing this in the _update() loop but I'm often getting cases where it'll place a sprite twice in the same place rather than just once.
After going through my code again and again, it struck me that having the pixel check in the update() might not be the best place. Wondering if doing pixel checks in the draw() are more reliable because there's cases where update() could be slower/faster than draw()...?
I chose to do pixel checking to avoid having to loop through an array checking x/y coordinates every time but it sounds like that may be more reliable?
Any thoughts/insight is appreciated.

In my opinion, pico-8's musical notes don't go nearly low enough.
In addition, its UI assigns numerical values to notes' octaves which are off by 2. (A middle C in reality lies at the bottom of octave 4. In pico-8, its octave is labeled as 2)
Personally, I would love pico-8 to at least cover the range of a traditional 4-string bass guitar, down to e1. (in the 1.8 UI that note would be labeled as octave -1) Even better would be getting all the way to octave 0.
(also, I'm aware I can put a track in "slow" mode.)

a=100 m1="-2"+0 m2=-2 print(m1) --- prints -2 print(a*m1) --- prints -199.998 print(a*m2) --- prints -200 |
While m1 prints as -2, a*m1 seems to be -199.998. Multiplying by m2, the exact same number but not parsed from string, doesn't have this problem and gives the correct answer: -200.
Maybe it's some sort of an off-by-one problem in the parsing that "-2"+0 implicitly does?
Anyway, would be great if this could be fixed for 0.1.9 :).

Long time ago I had a project of the demake of a specific game on retro hardware (this project is not dead yet, I just lack time to work on it)
And a few days ago, I crossed some data for that project and my brain told me
- Why not see if it's possible with Pico-8?
My answer was quite simple: - Challenge accepted!
It's not a game perse, but I'm currently more advanced than on the original project, there is no cartridge for now, as the code is a mess and it's basically just testing some of my original ideas, I have a lot of things to do before I could say "it's a playable game" right now I've just tested the level generation, so nothing really fancy for now.
So, I present you the first moving picture of PPPPPPPP:
(the starfield come from the same effect in the tweetjam, I used it to test the transparency)
Edit: added the cart here:

This is a shader thingy with a few variables and palettes to play around with.
It's all ready to go, but I might introduce dithering into the palettes in the future.
Left / Right changes the active value, and modify values when a value is chosen.
Button 1 activates and deactivates modifying values.
Button 2 changes the palette.
It has a few quirks:
- The timer makes the image jerk a bit after 32000 seconds when it loops around.
- Due to the way the pattern is drawn onto the spritesheet, a lot of the patterns will look weird and cut off. This drawing method made it run way faster though.
- Floating point inaccuracies mess the printed values up a bit sometimes.
Have fun! :>
This is an IFS viewer for pico-8
Hit Z to stop iteration if the view hasn't converged,
or to start iterating with new parameters if it has.
Jump into the src and edit the function for different visuals!
Feel free to remix, this is a commented extension of this #tweetjam snippet with nicer visuals.
Changes:
- Some cleanups
How to play the game:
You win when there is only one marble left on the board. You remove marbles by jumping over them to a empty slot of the board. If you select a marble and there is only one valid move to make from this selection this move will be executed automatically. if there are multiple valid destinations you have to specify where to move the selected marble.
With the ability to record longer GIF videos now, the file size gets pretty big, but I didn't manage to find a suitable GIF optimizer, which removes redundant frames and extends the display time of the frame - all optimizers I found only remove the n-th frame or dither the image... Anyone knowing such a tool, online or offline?

OK, not sure that this is a proper place to post but I have been really fleshing out the Squashy game into something bigger for my first try into Pico8/Lua. I've got it all the way I want it but I can't get it to flip game modes back to the main splash screen as the "game over" screen.
A couple of things... how do i get that to work? (should I post the game or the code?) If the game, how do I post it?
(crazy noob questions, sorry! :) )

Ive been hard at work making a port of the pretty good puzzle game from from the game "game center cx 2" called "Triotos". i would describe it but this guy did it well enough i dont think its needed for me to just retype what he did.
However the problem is that i do not have the skills nor the knowledge to actually program the damn thing. i can use my limited knowledge to imagine how it could work but after that its pretty much blank.
Ive made most of the sprites done and the gamefiled (although im still working on the background) and ive done some basic code.
I forgot how to post cartridges so uh...here's just a mediafire link (sorry)

Note: web player doesn't currently support 60 FPS rendering, so this is just going to look like a static palette unless you download it.
Hat tip to ilkke for the inspiration.
This is a simple palette vs. palette demo to show off the idea of color interlacing in a very simple way: it uses the new 60 FPS function to render very quickly alternating images of 1. a single large tile version of the pico 8 palette and then 2. a 4*4 matrix of palettes, one lined up perfectly with each of the large color squares.
The result, when viewed, is a flickery implication of 256 separate colors*, one for each combination of two colors from the pico 8 palette. As laid out in this example, that shows up as a series of variously tinted versions of the palette itself.
It'd be interesting to lay out the color combos in a more gradient-centric way, but this was far simpler to throw together as a first experiment.
Here's a rendered approximation of the interlaced effect as a smooth static image, though of course the visual effect in practice has a kind of restless volatility that this doesn't capture:

CONCEPT:
Use some basic SFX scripting to make a DDR "demake." Slam Jam is further along than I am. Go enjoy that, too.
SPRITING SUNDAY:
Okay. So I did most of this last week. I'll probably revisit this after Concert of the Damned; I certainly would like to get way better with SFX/Music tracker stuff, and code to manipulate it from within. So far it has arrows (that can be recolored for 1/8 and 1/16 notes, holds, etc.), a "hold blur" that can be flipped each direction, some system icons and CD banners (which can also be palette swapped, but for now they're pretty straightforward).
Not a whole lot, but it's there.
The music part is gonna be a bit trickier; but I believe still doable. The thing is, I'm going to need a way to create a few functions that make and load SFX structures - or at least can reassign the IDs on the fly - so that the song select screen has 64 samples; and then once a stage is chosen, it can write the song data into the music tracker for gameplay purposes - and then play a sequence of the structures (1-8, 9-16, 17-23, 9-16, 24-32; for example); and at the end of the stage - during the EVAL loop - it reloads the samples.
Fact is, a lot of songs share many of the same core beats and structures, only the main melodies and tempos are really different. The tempo will have to be totally reimagined (to work with PICO's "speed" setting instead), but a common factor should control both that and the arrow speed. And since the game doesn't require external sound effects, it can actually use all 4 sound channels for composition purposes.
That said though? I'll fully admit I hardly know diddly about how the data structure for that stuff works right now. So "Music Monday" may be a good few months of constant tweaking to make right; and really, none of the other gameplay works without that. But I'm posting the current source material here because someone here may be able to run with it better than I can.
Visualizer code after that? I mean... it exists now elsewhere, so we'll see what happens with that.
BONUS ROUND: Name all of the songs that the CD cover sprites reference!!
AFTERTHOUGHT:
Another similar concept popped into mind after this, and it might be equally amusing, as well as different enough to be compelling.
You control a character, and a corresponding stepzone (just Z/X, it's two arrows wide) located above them (they both snap to the tile grid). Easy charts are 4 columns acrpss, mediums are 6, hards are 8. As targets approach the stepzone, you have to move the character to the position and then tap Z/X with the rhythmwork. Charts also contain "spikes" which you have to move the character/stepzone to AVOID. You can also "slide" targets by holding Z/X and then moving left/right with the correct timing (or holding both of them; which can also sustain holds).
It's similar enough in structure to reuse the music code; but also different enough to be its own beast. Oh well, there's always later.

CONCEPT:
Castlevania SotN/Zelda II demake. The main focus of the game is the Zelda II-style combat; but also with palace-building scripts that... well... at this point, basically generates pathways to two keys (or enemies that drop them), an item room (that requires one of the keys), a boss room (that requires the other), and an in-palace shop. There's seven "palace chunks" in total, and later I'll be scripting closeoffs for passageways that aren't used.
DESIRED OUTCOME:
A seven-palace romp with progressive/changing enemies, decent assortment of weapons and passive items, enemy drop RNG that on occasion includes some of these weapons and items, to give it more of that SotN replay/uncertainty, a couple of secret areas of some sort?
[b]SPRITING SUNDAY

I stumbled across PICO-8 a few days ago and decided that I had to try it out. This is my first PICO-8 cartridge, just to get to grips with it. I started out following the TRON lightcycle tutorial on YouTube, but then inspiration struck me halfway through so I made this instead.
Pretty simple program, really. Use the arrow keys to draw, and Z/X to cycle through the colour palette. Black works like an eraser, and you can also use it to create gaps between drawings, like the letters in the thumbnail. I know it's kinda fiddly, but so is an actual Etch-a-Sketch :P
Probably could've put this in the "Completed Cartridges" section tbh, as there's not much room for expansion or improvement on a program this simple, but I didn't think it was big enough to warrant it. Maybe later.
Updated it a bit, you still can't win (it won't detect it at this point...)
but looks a bit better now.
Hi there, i was playing around with pico8, and just wanted to post this code,
i'll update it in the next few days.
all data is stored in the map itself, with pre-calculated surrounding bomb counts.
the current version has everything shown on the field, i'll remove those in the next "version"
posting this just to give an idea how one (newbie ofc) could use the map to store additional data/game state.
i'll do some code cleanup and new sprites later.





2 comments



