Any possibility of being able to switch out the 16 colors in the future?
Yeah, I'd like to be able to set custom palette, perhaps encoded in the cart itself. Would still be only 16 colors per game, just different ones.
It's possible to do this by using poke() to alter the memory addresses where the palette data is stored.
However, you need to know what you're doing.
do you have any more information on that?
I checked a p8 rom, it doesnt seem to have palette data stored in there.
where in memory would I find that?
Bumpity-bump. I want it to happen.
I think it could work this way:
There's palette editor that let you choose any rgb values for any color, but it is per-cart, static setting, i.e. you can't change it at runtime, only in editor. In case of palette block missing from the cart Pico would assume default one is used (for backward compatibility).
I don't think this is in the spirit of a "Fantasy Console". The palette's limits, both in size and chosen colours, define the system's "flavour" like it did so many other consoles from that era. Pico has a feel, and the palette is partly responsible for that feel.
We are supposed to be excited to subvert the limitations, not just ask for them to go away.
This is what is separating "Fantasy Console" from ordinary game dev API.
Good luck making a horror, or even castlevania on Pico!
That sort of thing won't work.
They made a Castlevania on the NES, and that palette is similarly limited.
Don't even compare NES palette to Pico's. NES had 55 distinct colors, many of which are dark to allow for proper atmosphere, while pico's palette is just 16, mostly bright colors that fits to horror genre as good as fist fits in the nose.
NES palette:
Notice amount of dark colors
Pico-8 palette:
Any questions?
Also, please notice that while you could configure palette, it would be on per-cart basis and you'd still have 16 colors to use that you can't change (except for stuff like pal, etc.) at runtime, the difference is that you get to choose which 16 colors to use.
I think the existing cartridge examples show the versatility of the pico8 palette.
there's also some amazing examples on the pico8 twitter tag.
https://twitter.com/hashtag/pico8
i don't think pico-8 needs alternative palettes, however if you really wish to do so you can globally change the palettes in picolove.
Versatility? I just see lots of cute, bright cartoony stuff, not something in the same range as Sweet Home or Castlevania.
@darkhog, why are you always picking fights with other people on the forums? The palette limitations are fine, and part of the appeal. Here's just one example of a cart using darker colors and creating a "horror atmosphere" that you think isn't possible. Also, here's my really rough palette layout by brightness that I've been using for shading.
As far as 16 color palettes go, this one is pretty nice. A lot of saturated rainbow colors, a good range on fades, a skin tone ramp, and darks that fill a wide range of hues. Only the red really stands out as difficult to blend, and I'm okay with it because it's an important color. Immediately dismissing the style as "cartoony" may be closed minded, but demanding alternatives because you can't use it properly is just stubborn.
Also, FYI, the NES resolution was 256x240, so of course the sprites would need more colors and detail than in the 128x128 PICO res.
@darkhog innomin asks a great question! Limits are what the fantasy console experiment is all about. Working within them is suppose to produce the excitement.
If you don't like restrictions, you can make cool 2D games in Unity, or SDL, where you will find tons of freedom to customize whatever. If you have trouble with an editor like you often seem to, you can switch to whichever one you want. I think that seems like more the experience you're looking for.
So? GBC resolution was closer to Pico's and had similar palette. FYI, more colors=more details even if resolution stays the same:
Plus in case of what I'm suggesting, explicit amount of colors would stay the same - you'd have always 16 colors at your disposal, those colors won't be able to be changed at runtime, only in editor, per cart.
Need more greens but don't care about yellows and reds? Gotcha.
Need more darker colors? You get it.
Want to make your game grayscale? Sure you can, with 16 shades of grey.
@darkhog, thanks for ignoring the rest of my detailed analysis of this palette. Also what I meant by mentioning PICO's res was that you can't have as much detail as the NES, so more colors are unnecessary.
I don't want to tell you to go away, but it seems like you're not enjoying the PICO experience and instead trying to jam your own idea of what it should be down our throats. We're not interested.
@darkhog: the GBC has 30% more display space than the pico-8. Also the actual perceivable color space on the gameboy color is only about 4k colors total after you take into account that the display had a terrible gamma curve.
Also, it's worth pointing out that the system came out in 1998, and was a hand held. the PICO-8 is suppose to be a fake console with low specs from a much earlier time period, although it could be argued that the game gear had a similar color space (4k colors) and was released much earlier (early 90s). If anything I would compare it to the genesis or the commodore plus/4. They both had relatively low color spaces (512 or 121 colors respectively) and the games that were produced for them were beautiful.
One thing the developer might consider doing is adding a intensity array for the 16 colors, which would effectively increase the palette space from 16 colors to 256, while maintaining the retro feel. This also fits the TV display theme. Colors back in the day were generated using the HSV space, locking H and S while making V variable was fairly standard for the time.
[quote=Pico site]The harsh limitations of PICO-8 are carefully chosen to be fun to work with[/quote]
Well, resolution - fun to work with, memory, too, sprite/map space limits, yeah. But palette? It needs to change.
[quote]One thing the developer might consider doing is adding a intensity array for the 16 colors, which would effectively increase the palette space from 16 colors to 256, while maintaining the retro feel. This also fits the TV display theme. Colors back in the day were generated using the HSV space, locking H and S while making V variable was fairly standard for the time.[/quote]
Actually, that's a great compromise. I can get fully behind it.
//edit: WTF? Quoting doesn't work?
Quoted from Innomin:
I don't want to tell you to go away, but it seems like you're not enjoying the PICO experience and instead trying to jam your own idea of what it should be down our throats. We're not interested.
Sorry to be a little rude, but he's kinda right. We (well, I at least) value your opinions, but the frequency is a bit of an issue(I did this too on another forum).
I'm not trying to be mean, I'm just giving a bit of advice.
Still though, I support the idea of (easy) switching palettes.
Not too many though, I'd say 64 would be the max.
Little thought: The Sega Master System was known for its vibrant colors. Can we do the same?
But palette? It needs to change.
No, it doesn't, and you really do need to make an effort to get over this bulldozing sense of entitlement you've brought to your interactions on the forum. Enthusiasm is great, being a demanding jerk is not, and there's a balance there that you've really got to work on if your goal is not to actively annoy everyone else in this little community.
While plugging variables into "Bitpools" I noticed that it's possible to use Pokes to produce colors that don't conform to the official palette. I've made a test cart which demonstrates this.
I'm not great at hex values so I'm not sure if it's possible to enter specific color values, or just shuffle through a few slightly altered versions of the main palette.
Neat stuff! It looks like you found the palette, which lives in the bytes 0x51F0-0x51FF (!!) PEEK and POKE only write bytes, so only the values between 0 and 255 will matter.
The high nibble almost seems like it selects alternate palettes, except there's a lot of missing values (black).
For example, dark green is 0x03, and 0x23, 0x33, 0x43, 0x53 are all shades of green.
Visually, here are the dark blues...
(dark purples, dark greens, and browns)
Mason, "Left --> divide by zero"?? heh, what? Welldone and very cool! Will do some tests soon.
@darkhog: maybe you are (just like me) not an artist. still I find it challenging to 'trial-and-error' the best matching color for any pixel of a sprite.
Mason, Cheepicus:
Nice one. I made a little table showing the new colors generated by poking that range of addresses.
Well, looks like we can enter the next Gameboy Jam at least :) Love the funky pink at 0xFF hehe
They all look pretty close to the base colours, apart from the full collection of blues over there. Might be useful for a more somber kind of game.
Cool, if only I knew it before I've finished HDS. Still, will be useful for a next game, especially the blues and greens.
@zep: Don't you dare "fix" this!
Anyway, I am reminded of (also unintented) "hicolor" mode of gbc (read up on that, pretty cool stuff).
I am pretty satisfied with that great discovery by Mason and this is closed for me.
Mmm. I think there are more interesting addresses :) 0x5F00 let's you remap color 0
as an independent color (not backoground like in 0x5F10). But it's not possible to use the color
from the Altern8 table. And from 0x5F01 to 0x5F0F looks like a regular palette remapping to me.
The higher nibble is ignored.
Esteban
Oh man, I hate to be a killjoy, but the colour values >= 16 are only accessible due to a bug fixed in 0.1.2 (the displayed values are supposed to be masked by 0xf, not 0xff). The other colours are historical versions I tried out during development which is why they are vaguely similar.
I haven't completely ruled out the possibility of modifiable palette entries in future, but I'm pretty happy with the way having a fixed palette has worked out so far.
Hi Zep,
Thanks for your reply. No worries. It's a pity because I realised that it was even possible to keep the colours modified during editing as well (like in the GIF). And it was cool to see the background in a different color :) Anyway looking forward to 0.1.2 and congratulations for such a great tool.
B-but... what about #nocartleftbehind?? (jk)
It's OK, I kind of expected this outcome.
Undocumented opcodes! Adds to the retro charm. :) Personally I wouldn't expect anything undocumented to be preserved until v1.0, but it's a cute idea to keep a few along the way, maybe even plan some as easter eggs. I'm not sure expanded palette should be one of them, but it's in the spirit, I think.
Several have mentioned that limited choices 1) are retro, and 2) inspire creativity, and elsewhere there is advocation for 3) they make Pico-8 games look like Pico-8 games and not just pixel-y web games, which fosters community and inclusiveness. I'd add that limited choices make the platform more accessible to beginners. The point where home computers went from 16 colors to 4096+ colors is precisely the point where I stopped doing pixel art because I was intimidated by choice, and greater skill was required to choose wisely. My C64 games weren't pretty, but at least I made some. I couldn't get any Amiga projects off the ground because I was too frustrated with the results.
My 9-year-old loves the Pico-8 art tools, in a way that he doesn't love full-res art tools. Still trying to get him into the Lua part. In true retro form, it's a bit of a learning curve to get modern-style results out of the code without a framework. I wouldn't change it but I'm interested in the contrast.
And here I was happy with that solution, the issue was closed for me and zep just took a knife and reopened the wound (n)
Wow, a whole other 2 shades of green, a purple and some dark blues. You have truly lost everything.
You forgot about different greys. How am I supposed to have grayscale game with only dark grey, light grey, white (that is contrasting too much with even "light" grey) and black (that is way darker than "dark" grey).
Again, I was perfectly happy with Mason's solution and wouldn't bring it up ever again, would just shut up about that, had zep left it in.
You don't design a greyscale game for a platform that doesn't have many greys. Please stop with this nonsense.
Your flippant attitude that zep doesn't know what's best for his creation, and that he's ruining it, is getting tiresome.
Just wanted to link this here. Pico-8 has a nice purplish 4-color greyscale available. https://twitter.com/castpixel/status/600608894587707392
Given that the Game Boy's greyscale was greenish, the fact that it's not based around neutral grey doesn't seem terrible.
The sprites shown are also a bit larger than you'd normally use for a Pico-8 game, but you could definitely do something interesting the scheme if you wanted.
Yeah, the purple tinted greyscale palette option is fantastic. You even have black for a 5th color! ;)
@sta64
> It's a pity because I realised that it was even possible to keep the colours modified during editing
This was intentional in case the sprite editor ever needed to be used with nonstandard colours or mappings one day cough cough. Note that you can still remap the palette while editing, just only in the 4-bit range.
while the whining was a bit much, I appreciate this thread for all the inventive ways shared to work with the 16-color pico-8 palette! ;) thanks @innomin @jamesgecko
[Please log in to post a comment]
