Dear Pico-8 Community,
The darker colour palette should be available without fiddling with memory or coming up with detour functions.
@BoneVolt @Krystman
(via YouTube and such... not dissing! You guys are great <3)
Palette switches were cute,
but this whole schebang has flopped into an inefficient knot (as far as I can tell).
...I wish that first-time-carts from total amateurs (like me) could also use "dark-brown", lol.
...And that expert carts don't all use ~double the amount of available colours.
Perhaps I don't understand the memory limitations.
And I do appreciate (and want to preserve) the elegance of "0-15"/Proof of concept/Simplicity didactics etc..
But the cats' been out of the bag for a while.
@zep could you please greenlight "night mode" [EDIT: in the UI or functions].
Maybe its impossible at this rate. Maybe it wasn't intended this way.
Dunno. Shäre ur thoughts...
Trying to be constructive. Or did I miss something?
It's a super interesting subject, feels almost political.
Happy new year.
x Phume
EDIT: link to @shy 's cool devkit menu experiment https://www.lexaloffle.com/bbs/?tid=41032
Not to be rude but it's just
pal(0,128,1) |
to swap black to darkbrown until reset
(first arg is the color to be changed,
second arg is the new color (darkbrown)
third arg is the palette mode (so in this case the primary display pal.)
If you want night mode it's just
for i=0,15 do pal(i,i+128,1) end |
to swap colors.
also thanks, happy new year too!
(I just feel like it's already pretty easy and I'm pretty sure it's been changed to be easier than when it was first hidden in there but I'm not entirely sure.)
(I also personally like the pal swap problems and interesting ideas; the whole idea of hoops is the appeal of pico-8 for me imo. I really want it to stay the same.)
@SmellyFishstiks Dark brown was an example, I kinda think you missed my point. :-)
Although "Night Mode" might be the wrong request ...? Maybe custom Palettes?
EDIT:shot from the hip
@Phume I was still adding on to my thoughts,
I think I understand; getting alt colors is a bit tricky but I personally enjoy that just like a lot of other things in pico (stacking sprites in the same space, using RAM space, etc.)
"custom palettes" doesn't make much since to me since you allready can have custom palettes
@SmellyFishstiks At heart I agree, but something about about it is too sneaky. I feel like it should be easier to do in code, in the loops, without poking around.
@SmellyFishstiks available in the UI? Function inputs (0-31)? Would that be impossible? Age old discussion...
From an image format, that's not really possible.
PICO8 screen format is defined as a pair of 4 bits, e.g. limiting the number of addressable color to 16.
So to open up this discussion, on principle I agree with this sentiment, because the 32 colors are not currently very user-friendly. I'm not talking about how easy it is to set them up, I'm talking about how intuitive it is.
Right now, you have to pal({...}) AND poke(0x5f2e,1) to get the colors in-editor, and even then it blows up the rest of the editor's menus (code, sfx, music) by recoloring them to match the art palette. This all means that 100% of the time I'm in an external sprite editor now when I'm doing things for Pico8. I limit the colors I'm using to 16 shades manually, then work out a way to import the external spritesheet so it's coded with the correct values from 0-15. It's kind of the opposite of a "cozy" development environment...
Even though the internal color data must be limited to 0-15 values when moved to the screen, a lot could be done to improve the way the palette was accessed in editors. Using a screen palette per scanline in the editors, zep could let people define the current 0-15 screen palette used in spr and map, and only alter the non-UI rows to this new color mapping. @BoneVolt created a utility that does something similar to this in-game, so it's possible even with the screen data limitations, but I think it should be built-in to those editors by default. For map, at least, it would be incredibly easy to only re-palette the black rows, so the top/mid/bottom UI rows don't go weird when you're using re-paletted art. And for the code/sfx/music tabs, it's actually really bad if some green-highlighted text suddenly becomes gray or nearly the same color as the background, so the screen palette remapping should be turned off entirely in those tabs.
How this is implemented would be important, though. I'd recommend adding a completely new hardware editor tab to the five basic ones, where you can set things like the art palette / screen scaling mode / btnp delays / a checkbox for devkit mode, and other undocumented values that you only find out about after searching the fan sites. We already have a devkit mode, so why not also have a hidden hardware tab that gets enabled if you click on the sprite tab three times or something?
This stuff should really be attached to the cart rom and editors a bit better than it is right now, and I can understand the frustration from newcomers when they see what the Pico8 pros are doing. Not because they can't learn how to do it themselves, but because it seems like the techniques are intentionally obtuse. Often it even feels like it goes against the intended, all-in-one, minimalist design of the platform, by requiring outside programs and conversion scripts. Those things will always exist, but something like colors shouldn't require their usage.
@shy ur my hero
+= I dont know what an extra hardware tab would feel like, its a bit of a rock and hard place when it comes to UI clutter and code clutter.
Doesn't the music tab feel a bit fiddly? (I haven't really used it yet).
But the ergonomics def. fall short atm. I like the idea of some new/improved functions, simple stuff like what zep did with split()...
stuff that nukes code that shouldn't be there and makes for good backwards compatibility.
EDIT... dare I say pythonesque haha
There's always community made stuff that helps beginners explore stuff, like my own Painto-8 Lite. I agree that it would be cool if you could edit the palette without blindingly doing it through code, or resorting to external tools.
I don't want to express any opinion on how pico-8 "should be" though, because it's not an easy thing to design. If you put everything in the editor, you will end up with an extremely cluttered editor. Like when you open Photoshop or any program like that for the first time. Your reaction will most likely be "what is all this stuff"; "do I need to learn all this just to get started?".
Making the 32 colors accessible through the editor could just change the problem in a beginner's eyes from "Why can't I edit colors from the editor" to "Why can I only use 16 colors if there's 32" and so on.
In any case, that's not up to me, so I don't care that much. There are tons of tutorials and tools to help beginners, and considering as I was a beginner not too long ago, the hardest part will always be actually coding the game. We're not in some drag-and-drop app after all.
Not really, just to have a look at the entire sheet when I need to.
So here is a way to think about it.
Pico-8 is a platform with harsh restrictions. 16 colors. Low resolution. Low graphics memory. Limited tokens. Limited cart data. All these restrictions are punishing but only if you end up bumping against them. This is a good thing. Pico-8 teaches you to think small. To keep your scope in check. To keep things manageable and simple. It is a tough lesson but one that is worth taking. In fact, I seem have to repeat it every now and then.
Now there is a way to negotiate all those restrictions. You can always nudge things a bit. You can get a bit more code in within the token limit. You can get a bit more colors. But if you do that you need to sign a pact with the devil. There is a price to pay. That price can be very steep. It's an illicit hack. You voided the warranty. You're off the deep end. You pulled off the safety. No seatbelts, no helmet. No more cozy time.
I understand the desire to want to keep up with all the cool carts people are posting. I see BoneVolt's stuff and it makes me feel like the default 16 colors are not enough. I see Fred72's stuff and I feel the need to get more into 3D. But we should see it as it is - it's just FOMO speaking. The grass is always greener when you're using the alt colors.
I've been around the PICO-8 community for a while. I made a bunch of fairly successful games. Despite of all of the tutorials, I have used the alt colors just ONCE. And the game I'm currently working on won't be using them.
So the way to see Pico-8 is that it has the 16 default colors available in the editor. And the 16 alt-colors is just an obscure hack. And if that hack seems sketchy you probably shouldn't do it. There is a price to pay if you do.
The default 16 colors are plenty to do amazing work with. Don't give it to the FOMO.
Doubling down on the "illicit hack" bit: The alternate display modes, undocumented and only accessible via pokes discovered by the community, are there to simulate the unintended behaviors of retro platforms. Master coders learned to warp hardware with techniques never imagined by the designers of that hardware by weaving through the complexities of those systems. In a fantasy console, there isn't really a good way to implement exploitable complexities abstractly, so Pico-8 includes a few "undefined" behaviors as easter eggs. The old master techniques grew from research, sharing, and cross-compilation tools, and we're expected to do the same with the undocumented features. Pico-8 is an ARG as much as it is a gamedev platform. The fact that these features are available as simple pokes is the accessible easy version of this idea.
If the easter eggs should be supported directly in the tools, why stop at colors? Should the sprite and map editors have wide-pixel modes? Should the music editor support low-pass filtering? Should all of the amazing things people are doing, like platform physics or 3D, be built in to make them more accessible?
I was envious of the off-platform dev tooling used by professionals back in the day. My C64 had no built-in monitor or assembler, on-platform coding was tedious even with third-party tools, and I had neither the hardware nor the expertise to achieve what the fancier commercial games were doing with cross-compilation. On-platform coding was cozy and fun, and the fancy stuff off in the distance was inspiring even if it was impractical to reach without cross-platform tooling. That envy is part of the experience, inevitably.
Remember that Pico-8 makes it easy to build custom asset editors as Pico-8 carts (see cstore() and reload()). It would not be difficult to implement a color-mode capable sprite editor from scratch. Many of us wrote our own on-platform helper tools back in the day, because we had no other options. It's great that you can have the complete retro dev experience without ever leaving Pico-8, including building your own tools and libraries--and downloading tools and libraries made by others! (Uploading to the BBS directly from Pico-8 is still a gap, but dang that'd be sweet.) Go full screen, don't look back! :)
@Krystman, @dddaaannn: I really don't want to be a contrarian, but I kind of disagree with this sentiment. From a user-experience perspective, it's not good to say that something as fundamental as color is hidden away unless you are experienced and willing to pay the price. I can understand the question of "why stop there, why not overbloat the software and editors with everything?", but the point is about where you draw the line. If you make it too obtuse to discover / do / experiment with basic things in your editors, then you're right, people will start to use other tools that are more general or code their own. Instead of spending that time quickly prototyping and making games, which is kind of why harsh restrictions are good in the first place.
This is not a question of envy or FOMO for me, as I've solved the problem for myself by avoiding the builtin art editors entirely. It's a question of intent. Simple is good, and Pico8 is a good demonstration of that, but it has to be simple and complete. If it doesn't solve the basic problems of what it's supposed to be an editor for, then what purpose does it serve?
I've been here for a long time as well, and on a different account years back I argued against adding additional colors to Pico8 at all. But those colors exist now, and the editors haven't kept up with the bloat of the system because of this. Whether you personally use the alt colors in games or not is more than likely due to the obstacles required to set them up, when in my opinion the whole point of fantasy consoles is to streamline that process and make those decisions for you. Now Pico8 is saying, "There are only sixteen colors, unless...", and that trap is pulling a lot of productive hours away from many newcomers here.
Thanks @shy, that's a good clarification of your point. I think you're saying that Pico-8 should have an explicit well-supported feature set and none of the easter egg nonsense, and that's a fair position. One could argue that hidden features are categorically different from advanced techniques, even if the one is trying to simulate the experience of the other.
One attractive aspect of Pico-8's artificial limitations is that not only does it produce a cozy dev experience, it produces a cozy community experience. As long as most of its capabilities are within reach of a beginner, then beginners are less likely to feel alienated or intimidated by the work of others. I think this needs to be balanced against making it satisfying for people of different levels of interest, investment, and experience. Clearly some people are having a good time writing simple arcade games, others are making Poom, and hopefully it's all fun and inspiring for everyone.
One role the hidden features could play is to give people stepping stones towards advanced techniques: yes it's a little bit harder to use the second color palette, but it's not as difficult as, say, color switching (Pico-8 reproduction!). This too is C64-inspired. The C64 lacked obvious BASIC commands for many of its features. As a kid, I could barely get hires mode to work, but I knew how to change the background color: POKE 53281,0. That seems obtuse but it was a doorway to understanding graphics modes that would have been less accessible if there were a BACKGROUND "BLACK" command.
Whether the hidden features make Pico-8 more accessible is debatable, and you make a good argument that they may do as much harm as good to this end (though probably not much of either, IMO). I think they do a good job of making Pico-8 grippy, and that benefits gamedevs of all levels and the community as a whole. Ultimately the hidden features are meant to contribute to the contours and idiosyncrasies of the platform for people who enjoy exploring. It's fair to say that this distracts from what could be a simpler core idea, but I think there's lots of reason to believe that that's not what Pico-8 wants to be.
OK. puh... I can't make it through all of these positions without being at least a bit of an emotional twat. Plus I can't spar with the pro-language at this rate. Though I'm quite chuffed that this has turned into a legit thread , a first for me hehe.
So I'm hearing some “Slippery Slope”...
("when more colours are available eventually everything will be..." take your pick)
No.
And a bunch of “Back in our Day/Hard Sweat” arguments too.
(we snuck around these corners and didn't have those tools)
No.
I could elaborate,
and I know there are silver linings to those arguments.
but... here's my Fallacy! No one's used it yet.
APPEALS TO THE FEELS!!
I spent a >year with a raspi 3 as my main desktop computer because I was so * broke after my macbook died.
And after having to deal with all the horrible (need an art director) open-source linux games,
and (1k+ games but none of them work) emulation dream land,
I stumbled across Pico-8.
It seemed insane to me that anyone would bother to nail down something so elegantly human.
Regardless of the "reactionary-retroness" which makes me never want to play a platformer again...
I like the PICO restrictions, bare-bone pythonic code and adventurous chewyness of the whole thing (pokes and all).
And I like the light heartedness, encouragement and underlying "spring-board" to further game-design notions embedded here (morals and all).
But there's something eerily conservative going on here too,
I can't really put my finger on it, so I took a jab at the colour thing (which is what irks me the most in practice).
Whatever. Pico could be all about triangles, but if the FEELS were the same, I'd still be here.
Been trying to get into Godot, and before pico I was into PyGame...
but somehow it seems that if an idea can't work in Pico (2d,3d,32-colours whatever) then its not crunchy enough to survive plugins.
Lol most of the de-makes are better than the originals.
I'm saying this system is very NEW,
inspired by good ideas from the past,
but shouldn't be a memory lane machine either.
How many luddites like me have ever been able to code gameboy games
without faffing around with the home-brew scene or taking apart some horrible WYSIWYG UI?
It's optimised for a computer that costs <50,- that's radical!
And you can post and share stuff faster than you can fart.
It should be treated as such: something radically new.
I used to have the craziest emulators on my handheld.
Now its just BBS. It's that good.
So that's were I stand. I get the various arguments.
But there's clunkiness growing here that as a Dutchman I don't gel with.
And I'm not calling for swiss-industrial-design, rounded corners and that kinda shit.
Just maintaining the reasons why im here. Like the rest of you.
But those reasons are fresher than platitudes about bygone hardware and self-induced hacks.
As far as the 32-colour issue goes: I don't care for now, fine.
I tried to implement palette changes again today,
but it was so * boring I just made them toggle.
At some point I'll bother to make a stubborn little function for myself,
but until then it'll make me feel dirty. Meh.
I've heard some VERY good arguments from all positions.
But some pretty grumpy/stuffy ones too...
Sorry if my writing style is a bit mad and my arguments all over the place, that's just me. :-)
Anywoo. You're all fab. Keep it up.
While I'm at it I'll shamelessly plug my new little sprite animator (handheld)
https://www.lexaloffle.com/bbs/?tid=40997
don't look at the code it's gross.
<3
Phume
Appreciate the perspectives, @dddaaannn and @Phume. I definitely get that different people are getting different things out of using Pico8, and that's a good thing!
To be honest, I do like the code-based access points to some of these features, and I think the alt color setup is fine for me and my own workflow at this point. I have programs and scripts that I prefer using over the 128x128 display (especially for maps). My biggest concern, though, is that starting out with the built in editors and trying to do anything interesting / advanced right now builds fatigue, and likely pushes a ton of people away from Pico8 development entirely. Because if it's not simple to work inside the limitations here, then why not just make a game in something else?
Since a lot of the UX issues could be fixed with a few small additions to access the "intermediate" features, like screen palette and devkit mode (which have both been around for a really long time, and are documented), I personally think it's worth it. Also, I think we need to have a conversation about what hardware secrets should be saved with cartridge data, because the code-only access points for many of the hidden features kind of scream "unplanned patches" to me, rather than intentionally hidden design.
For example, mouse-controlled games really shouldn't need to poke in code. If you want that kind of control, you can have it, but I don't think I've ever seen a project toggle devkit mode on and off. So it always feels clunky, and the fact that the state of devkit mode is not saved with the cartridge also feels wrong. I get that some systems don't have mouse+kb, but then doesn't it make even more sense to flag devkit carts as requiring it?
I think the alt colors fall into this middle ground "design limbo" for me too. Basically, Pico8 is a 4-bit palette-based display that doesn't have any editor support for its own palette right now. Even if you only use the starting 16 colors, you're stuck viewing them in that specific order, and are unable to test fadeouts / lighting effects / etc on your tiles without coding it manually. With the addition of the 16 new colors this problem has only become more obvious, but it's been a problem with the art editors and saved cart data for a while now. I think all games should load a default screen palette on run, which is synced with the art editors, and only after that let code mess with it.
Also, while you could just write your own art editor and workarounds for these things, or find one on the bbs, both of these take time away from your project because the built in editors aren't good enough. At any experience level, if you run into too many obstacles you may just throw the whole project away. Similar to how hitting the token limit in a cart feels bad, on some innate level, and that can be a project killer all on its own.
We also have a nice big community of first time developers here. Training them to avoid the weird and overly complicated ideas is definitely a good thing, but it's important how you train them. Hiding appealing features by making it necessary to fight against UI has probably resulted in a lot of half finished, fully abandoned projects, from people that tried and failed to make them work. I think downplaying that real issue is not a good thing, and I also think it should be a major design goal of Pico8 to reduce this barrier to entry as much as possible.
Anyway, apologies for the rambling post, this is the end of my TED Talk. I just think there are some serious design issues that need a refactor in Pico8's editors, and the alt colors are only the most obvious example of this. We've gotten used to how Pico8 works, but that doesn't mean it's as intuitive as it could be. Since it's still in beta and new features are being added even now, it makes sense to me to update the editors and cart data to reflect the current needs of the platform.
[Please log in to post a comment]
