I was just wondering how to change the pico 8 palette for my cartrige?
I need the following colors..
0-000000 (transparent) 1-303030 (dark gray 1) 2-404040 (dark grey 2) 3-9D9D9D (light gray 1) 4-C0C0C0 (light gray 2) 5-FFFFFF (white) 6-FF2B2B (red) 7-FF7F7F (light red) 8-FFD800 (yellow) 9-FFE97F (light yellow) A-4CFF00 (green) B-A5FF7F (light green) C-7FBFBF (blue) D-BFDFDF (light blue) E-FF60E9 (purple) F-FFAAF3 (light purple)
thats kinda dumb since in the older hardware like the NES and GB you could define your own.
this should be an option in the future.
maybe there could be a set palette but you could mix colors to defined our own.
for example mixing white and red would give a lighter red
The NES and GBC etc, sure. But going slightly further back, the C64, Spectrum etc had fixed palettes of 16 colours - this gave the games on those machines their characteristic appearance, ie you could identify a C64 game just by looking at the colours. Having the set palette for Pico8 makes all the games look like Pico8 games, and is also "older" for old farts like me :)
The NES had a fixed palette of 64 colors, and you had 4 sets of 4 of those colors to choose from for what could be displayed on screen at any given time. Sprites using transparency only had 3 colors from that palette to work with.
However NES's palette was still pretty characteristic of the NES. It notoriously had poor yellow options and kinda sorta no red at all? Your choices were brownish or orangeish. However it had some very good blues to work with, which was why Capcom decided to make Mega Man blue.
Also, the way the NES's backgrounds were rendered, you could only use one palette for each 16x16 region of the screen, which made complicated images like a fullscreen drawing difficult.
Having only 16 colors on the PICO-8, but being able to use all of them anywhere at any time, that's a different sort of challenge. Compared to NES, some graphics can look straight out of the SNES, with the complexity of color mixing you can do in small spaces. But the lack of options/monochromatic ramps can still hurt.
Good point, there was that further restriction in what could be used at any given time. The C64 had this too, for sprites and maps. So a good middle ground would be say 32 colours and some kind of limitations on how they could be used at once?
I love the simplicity of the colour system on the Pico-8. Personally I don’t understand why people try to push the Pico-8 to be more “capable” engine. I think they miss the whole point. There are a ton of engines that can make retro looking games, some specially made just for that (Pixel Vision 8), some not so (like Godot and Unity). I think the idea behind Pico-8 isn’t just that, to make oldish games. The thing in which the Pico-8 shines for me is making it’s own “world”. Every one is on the same line with the same restrictions and abilities, like well defined boundaries. That makes incredible boost to creativity and feeling of the community. Keeping everything so simple makes it easier to learn and especially easier to learn from others. I am on my way to becoming one of Pico-8 devs and learning game development as a hobby. I am strongly against adding any new layer of complexity to the mix! I love to see how people learn to live with the limitations and how cleverly they are using those limitations to make such pieces of art! Why try to copy someone else, if you already are unique?
I appreciate constraints, I would however not mind it if there was just one primary space limiting factor, rather than...what, three? Compressed code is the "real" limit due to png, and tokens is sort of an imaginary one, yet they both end up being pretty close to the same limit anyway. It'd be nice if tokens weren't a thing, or were relaxed a bit to not include commas, etc. But all requests for changes like that seem to fall on deaf ears. :P
Some of us try to push the envelope in terms of what you can make PICO-8 do because that's what's fun to us.
It's for the same reason that someone might build a Star Destroyer out of matchsticks. It's not because it's a really good idea to have a Star Destroyer built out of matchsticks. If anything, it'll probably just end up being an eyesore that collects dust in a room you can't really use for anything else anymore. It's the challenge of building it that would be fun, not the having of the end result. Heck, use the last remaining match to set fire to it when you're done. :)
Actually, speaking of a Star Destroyer, maybe a better example would be Lego. When you give me a Lego set, which you'd be well-advised to do if you want me to like you, you're not giving me whatever I end up building. You're giving me the experience of building it. Sure, it's nice to end up with something cool, but the fun is the part where you're putting it together. When you're done, you turn off the lights and you go eat dinner. Because you're done.
Note though that I'm just talking about why we do that. Other people have totally different reasons to use PICO-8, different goals, different end products, etc. I'm not a good game designer. I design code, not games. That's what's fun to me. Someone who designs games is going to be more interested in using PICO-8's tools at face value, because they care about a player experiencing the message their game carries, not the medium that it's carried over.
(That last bit, or rather the inability to understand that last bit, is why a lot of "AAA" games look amazing but aren't fun.)
The NES had kind of a cool system for getting access to other colors: you could apply so-called "emphasis bits" to the screen which would change all the colors. They would make the screen slightly more red, green or blue, similar in concept to putting a piece of colored cellophane over the screen, and if all the bits were set it would darken all the colors.
Normally it would apply to the whole screen, but you could interrupt rendering partway down the screen and set them there, which some games used to make it look like the lower part of the screen was underwater.
I really liked your lego illustration! That nailed in perfectly what I love in with Pico-8: we all have a standard set of legos and it’s up to us how we use it. And I love to see the amazing things people can do with this standard set and how they push the boundaries of it. What I’m against at is adding new pieces to this set just because there are other kits that include those pieces. I think that being so strongly a strict standard set of legos is the feature that really separates Pico-8 from the rest.
Yeah, that's true. I do push zep at times to tweak the API a bit in terms of quality of life (e.g. adding the ceil(v) function instead of forcing us needlessly to do -flr(-v)), but I would be pretty opposed to significant changes. I wouldn't want people to add extra syllables or lines to a haiku, and I wouldn't zep to slowly turn PICO-8 into UE4. Luckily he doesn't want him to do that either.
I was kind of surprised when dither patterns arrived, as I consider them almost a generational step past where PICO-8 tries to be. Pragmatically, though, people were already doing dithering themselves, just with painful, ugly code, so really it was just a quality-of-life thing. It's not like you can do something with it that you couldn't before--it's just easier to do it. So ultimately I'm okay with that.
Adding more colors, though, would introduce something that's currently impossible. The only thing you can do right now is run 60Hz and flip back and forth between a very small handful of very compatible colors. You can get another 7 or 8 colors without noticeable flickering, as long as you can maintain 60Hz updates. But adding new, actual colors would not be a good idea. Not unless it's a new platform, e.g. NANO-16 or something.
@UncleSporky ya I just think that if you can change colors with peek and poke why not be able to change them directly in the editor
TIC-80 already supports 16 custom colors in rrggbb format
I don't really see why we shouldn't be able to have 16 colors out of 256 colors by combining 2 from the default palette.
this would basically just be layering 2 50% opaque color creating a 100% opaque color.
Unity supports millions of colors and true accelerated 3d rendering, why doesn't pico-8?
Seriously, the limitations are part of the fun. If they're not working for you, you can always go use something else - TIC-80 as you mentioned is an option, or you could use Love.
some time ago I suggested an additional video mode (secret pico-8 colors). basically it would display a blend of the current frame buffer and the previous one. that would have the effect Shadowblitz16 is talking about (50% mix, 120 additional colors) but with side effects (heavy blur on moving objects). also you'd have to handle the color swapping yourself (just like the 60Hz color trick). so, benefits with a caveat, like most pico8 features. just a poke to enable/disable, no api change, it's all inside the fantasy gpu.
also, on a semi-related note, retro monitor for pico-8
@keiya limitations are fun but that is no reason that the existing 16 colors shouldn't be somewhat modifiable.
@ultrabrite if it was supported correctly it wouldn't create motion blur
there are multiple ways it could be done
12 bits for colors could be done instead where rgb range from 0..F instead of 0..FF it could even be compacted more to 0..7
that would only require 12 or 9 bits per color
EDIT: the pico8 palette wouldn't be any different visually with a 12 bit rbg range.
also it probably would take up less space if it was stored that way since colors would no longer be a 24 bit rrggbb range
Colors are stored as a single nibble, four bits, not a 24-bit value. I mean, sure, there's probably one copy of the palette somewhere in the interpreter, but that's negligible compared to storing graphics that way. That's like, the entire point of palette-based graphics.
[Please log in to post a comment]