Heavily inspired by Aaron Bell's blog post.
No, the Pico 8 doesn't really have any secret colors, but by changing a pixel between two colors very fast, we can trick the eye into thinking that it is seeing another color.
Here is an approximation of how the effect should look on your screen:
Of course a lot of the colors wouldn't work, because of flicker.
Technical Info:
This requires 60 fps mode and works best when not run in a browser. Additionally, since (i suspect) the frame timing varies a little, the effect may appear to stutter from time to time on 60hz monitors. Additionally additionally, only some color combinations work (the luminance of the two colors have to be close to each other) and even then the color can vary a little between monitors. Not to mention that you would need to label your games with a seizure warning.
thanks for making my eyes bleed ;)
seriouly, the whole palette is terrible to look at, but there might be a few usable color mixes (the two ends of the diagonal?)
relevant threads:
60fps interlace color test
60Hz self portrait
(edit) made a mod of your cart to single out color mixes:
I literally just wanted to make that application, after reading on 'Commodore 64 secret colours' :)
Starting January did some experiments with that but sadly is not practical to be used on a game or anything. It shouldn't be used in nothing more than a tech demo.
Dither and TV PAL doesn't combine at all, it only looks good on a PC Monitor.
It gets worse when Pico-8 windows goes out of focus and drops the framerate severely, making the effect painful noticeable.
Here's the demo, it has colors sorting and you can use the mouse to colorpick the "HiColor" value:
Using the "HiColor" is quite easy, basically is just 2 4bpp values together for odd and even frame.
Nerd me: This is really fucking cool.
Practical me: Are we literally retreading the 1980s now? I mean... if the extra colors (and other things we're hacking together) are THAT RELEVANT, we could just make it a feature request and be done with it. For that matter, we're doing the same with code compression, map tiles... maybe all we need is a slight, acceptable upscale to PICO-8's project scope without going all balls-out. Even my idea to create an extra layer of recursion for maps isn't to maximize the map space; but really just because so many of my project ideas favor a "10 screens wide, 8 screens tall" format.
Nerd me: But what if "hacking it" is the entire POINT of PICO-8?
Practical me: ... grumbles
Practical me: ...there's also the whole "seizure warning" thing. ~.~
Regardless it still a cool experiment and apparently some people already did a few cool things with it (only noticed ultrabrite links now), why the Forum don't use underscore for links!?
The seizure can only be a problem if the framerate can't keep up the 60Hz and the viewer is focusing on a large area while it's flickering badly. That's easy to do if you just let your PICO-8 emulator go out of focus and watching 128x128 at fullscreen in a huge widescreen.
At most you'll probably get is a headache or eyes hurting depending of the quality of your monitor/television.
Finally, some colors are more stable than others... picking the right colors can actually reduce the flickering of the final picture (sadly the most stable colors are very similar to the original 16 colors).
That is ingenious! I read about this trick done with real consoles, but I did not get the idea of mixing the colors this way!
I remember being blown away by this effect on 'Creatures II' on the Commodore 64 :)
Hi Xderial, it's Aaron Bell here. I absolutely love what you've done here, thanks for the shout out. I'm a big pico8 nerd (without enough time to actually write code for it). You're da real MVP!
I combined the flicker colors with an ordered Bayer dither to get (essentially) 4,096 (more or less) distinct color options.
Setup functions:
generate_extended_palette()
generate_clut()
Draw functions:
extended_color_bayer_plot(x,y,r,g,b) Where r,g,b can range from decimal 0x0.0 to 0x0.f (0 to .9375).
flip_high_color() Works best when using 60 FPS.
In order to determine whether colors are "mixable" with flipping, I find the distance between them in Cartesian space. Less than 0.6 distance seems to eliminate the most extreme flashing while still providing a lot of extra colors.
-ElectricGryphon
I seriously tried using the most stable colors for better color gradients (especially in the darker tones), and was happy for a while. but at some point pico8 got out of sync and I couldn't get it back to normal. can't remember right now if it was the exe or html export but for me that was the death of the tech (for now?).
I have this idea tickling my brain:
why not have a special fantasy hardware persistent display mode that blends the current frame with the previous one? (only for display, actual buffer unchanged of course)
benefits:
- static graphics benefit from all these color mixes (and only those) in a reliable manner.
- dynamic graphics benefit from some blur
limitations:
- setup through an undocumented poke ;)
- only available at 60hz
- full screen effect! dynamic graphics may suffer from blur
- you still have to swap your colours manually every frame, either with pal() -forfeiting 2colours- or by duplicating sprites -forfeiting memory-.
- tricky to use: a moving white pixel ends up as a grey streak, unless you keep it set two frames in a row...
the limitations seem to balance the benefits in a nice pico8 way!
what do you think?
ultrabrite--
I've been pondering suggesting the same thing.
There's a gotcha, though.
I think zep has limited access to final blending with the framework he's using. SDL, is it? The problem is, if you want the blend to look the same as it does when flickering, you have to do a proper gamma-correct blend, not a linear 50/50 blend. So if he were to do it, it would need some genuine thought put into it.
On the bright side, there are plenty of minds here capable of offering help on the notion. My own is on offer, as I've had to do that kind of thing myself when downsampling from spatial dithering.
He could probably just have a 2D table, 256 entries, 16x16 with each axis being the pico-8 palette, pre-computed for a rough-average gamma power (let's say 2.3 or 2.4 since some hardware likes 2.2 and some likes 2.5) that he uses to software-blend between the current and previous vram contents to produce actual RGB colors for the real hardware frame buffer.
The nice thing about it is that it would allow hardware that isn't capable of 60hz to show the effect of a 60hz flicker trick. It'd still miss half of the frames, but their information would be present in the blended frames.
On the down side, a blended buffer gives one a false sense of cleanliness with some of the more severe color differences. If we want to say the blended mode is just an official mode, that's one thing, but if it's just to make up for situations where 60hz isn't easy to maintain cleanly, and true 60hz is still going to be used when truly available, then that might be an issue. Like, blending colors 1 and 15 would work in a blend, but yuuuckkk in flicker mode.
@Felice:
sdl2 does have alpha blending for surface blitting. not sure it's available on each and every platform though. in any case, there's got to be some color table lookup going on already. it wouldn't far fetched to use a tailored 256 color palette I think (needs double buffering though).
what I'm suggesting is an alternate video mode with steady color mixes (think hold-and-modify or half-brite modes on the amiga). somewhat related to the 60hz color trick, but not a fallback for it. also it does not work as a replacement: you can use the flick trick on some static graphics while a moving sprite stays sharp. with the mode I'm suggesting everything gets blurred.
of course that would also work at 30hz. I listed 60hz as an arbitrary fantasy hardware limitation, pico8 style ;)
seems easy enough to implement, and could open the door to a brave new world!
Yeah, I'd agree with simply making it an alternate mode, as you mention with halfbrite.
Seems like it could be done one of three ways:
1) Always average current and previous, giving a presentation interval of 60hz or 30hz, depending on whether you have _update60() or not. This is conceptually reasonable, as monitors back in the day were capable of high persistence, which gave a similar flicker-fixing/blending effect. They would have had trails, but I think we could look the other way on that, uh, misfeature of high persistence. ;)
2) Always average even and odd frames, giving a presentation interval of 30hz or 15hz, depending on whether you have _update60() or not. This would allow a dev to use the blended palette without fringing/blurring on moving objects. This is more difficult to support, as neither PICO-8 nor its monitor, back in the day, would have had the ram to buffer only even frames. Persistence would not have been able to be selective about which to hold and which to ignore.
3) Allow blending between some section of sprite/map mem and screen mem. This means you don't get full sprite/map support, but maybe that's okay. Given the required conceptual DAC bandwidth, I think this might need to be limited to 30Hz as a tradeoff. This feels the least reasonable to me, as it would go beyond the kind of behavior I'd expect from an 8-bit machine.
Really, I feel like #1 is the most in keeping with the era's hardware's abilities.
not easy to rationalize on fantasy hardware from an alternate past :)
since pico8 is already using double-buffering I was thinking of a co-processor that would work during a flip(). not sure how much sense that makes in terms of timing, bandwith etc. but I think pico8 is already far away with its lua cpu :)
I always chalk up the Lua choice to being a decent modern analogue of BASIC, which happens also to be commonly used as a scripting language in games. I think it's a good choice, considering that the platform is game-oriented and thus it'll encourage budding new game programmers to pick up a useful skill.
Anyway, yes, it's true there's only so much you can do to justify fantasy hardware. I just try to keep suggestions within the same realm as the existing "hardware" as much as I can, because I've seen that it's a sort of paradigm zep is actively trying to maintain.
I've selected the most stable colors. And by "stable" I mean not seizure-inducing (as a person diagnosed with epilepsy I can tell, trust me).
It isn't too much, but hey - you still get 23 colors (including default palette)
//edit: It doesn't look too good in html player, but looks great when ran natively.
Does that mean that combos like 0/1, 0/5 or 6/7 are still too flickery for you?
Yeah, these colors that I've selected have virtually no flicker at all, unless Pico-8 drops a frame, which happens occasionally (zep should look into this though as it doesn't seem to be my code but something inside Pico's code itself).
/edit: The way I've selected these is that I've ran a simple cart that let me chose colors to blend with with arrows and basically filled the screen with that colors on each frame. If it didn't flicker, it was a go.
But yeah, 23 colors aren't bad, especially since it added few additional yellows and what's basically a better skin color. Other mixes were either really flickery or made me feel sick, these are ones that didn't do either.
At 60Hz, this effect doesn't work too well on modern lcds. It worked much better in the 80s because of the CRT phosphors. People in the 80s were also playing their video games on older TV's from the late 70s or early 80s, because parents were afraid the game systems might damage the precious "main" TV. All of this adds up to a better effect for that era. Yes, I was there.
Also, the latest web player appears to have more performance/frame rate issues than the previous web player.
Here's an HTML template featuring the video mode I was rambling about in the above posts - dubbed "mode 88h":
https://www.lexaloffle.com/bbs/files/13845/ub88h.zip
unzip in your pico-8 plates directory, export with -p ub88h
I kept a small amount of flickering, because I'm weird like that, but you can get 136 fully stable colors by setting "c_flicker0" to 0.5 in the html file.
try it with the carts above, and also Ilkke's 32col self-portrait!
free to use and modify however you please, have fun!
Necropost, @kabin30240.
We've gone much farther than this now:
https://www.lexaloffle.com/bbs/?pid=109003
https://www.lexaloffle.com/bbs/?pid=102333
[Please log in to post a comment]
