Per this discussion, I wanted to mockup a potential new idea for the Pico8 editor, to better incorporate some of the undocumented features that are being used more and more often by people. The 32 color extended palette is the major one, which I still think does not play nice with the existing editors, for three reasons:

• Repeatedly tweaking the colors in your art requires you to look up arbitrary numbers and re-type them into a line of code, which introduces a huge delay that makes doing this in Pico8 very unpleasant. Some tools have been coded by other people to help you with this in-game, but I'm talking about the editor itself. The current art tabs don't work with the alt colors at all, and color is important enough that this is kind of making them unusable in their current state. I feel like every game I've played in the past year here has tweaked at least one color from the starting 16 into an alternate, so it's a huge use case.
• When you poke(0x5f2e,1) to preserve the palette in editor screens, it really messes up the code/sfx/music editor tabs, where colors are very important for communicating information. If I'm tweaking art and code at the same time, in that wonderful Pico8 way, I have to keep uncommenting and running a for loop that resets the palette and stops() at the top of my code tab, or just accept the weird colors in the code tab now. Duplicate colors can even make the text in the console completely disappear!
• Running special code to get the editors to look right is really hacky, and may not even be possible if you've maxed out your tokens on the game code. Shouldn't this palette feature be something that is saved with the cart ROM permanently, and only affect specific areas of specific tabs? Shouldn't a fresh startup change the palette on load, and be easy to tweak even if your code is completely broken, and doesn't run at all?

This is my suggestion for a quick fix: a hardware settings tab (see the thunderbolt icon in the top bar). To avoid scaring newcomers, this tab might be hidden until you triple-click the sprite tab, or gets enabled with some other quick, documented shortcut. It enables access to a lot of the values in the hardware state that are commonly used in a "set it and forget it" kind of way. I think these settings should be saved in cart ROM, and booted up when a cart is loaded or directly run.

The idea is to use the scanline mode for two distinct palettes: ART and GUI. The top and bottom red bars would always use the GUI palette, as would the code/sfx/music/console tabs. ART would be used on scanlines in the sprite and map tabs only, like so:

(notice the red UI bars and gray tools, but correct palettes in the art scanlines)

This plan is not perfect (the art cursors still go weird, and the colors not being selectable on the sprite or map tab directly makes them less easily tweaked), but it goes a long way to making a 16-color palette from the 32 total colors a lot more usable in a limited display, as well as exposing some useful features that 99% of people don't know about right now. Without something like this, I have personally resorted to just not making art in Pico8 anymore, because importing a spritesheet is easier than coding with mostly arbitrary numbers every time I want to tweak the art palette.

Also, a good half of the time when I'm giving tech advice, it involves linking people to the memory page from the fan site. These undocumented features are very useful in a variety of ways, and I think mid-tier experienced people would appreciate more direct access to them than a code command. Especially since the hardware settings that get poked at the very beginning of carts (like mouse+keyboard access or screen mode) rarely ever get un-set afterwards, so it makes sense to save those settings in the cartridge.

Anyway, happy to hear comments and alternate ideas. I just think the second palette has grown much bigger than expected, and Pico8's editors aren't totally set up for it right now.

...and I just realized that my "secret settings" mockup wouldn't work, because it could potentially have four distinct palettes drawn on screen at once. But overlooking some tabs used to reduce this down to a maximum of two (GUI/ART and PAL1/PAL2), I think the general idea is still functional. Might even be worth avoiding custom GUI palettes entirely, and just having buttons for the default palettes from the gui_theme command line argument. Some of these settings really need an interactive home, and others really should be saved with the cartridge data.

hi @shy,
I love that you did this :-D
super cool.
Off the top of my head / My gut feeling is that any extra menu tab would have to be much more foolproof that a collection of "things we use alot".
Priority: basic colour options > btn delays > hardware flipping (in that order for example). The latter two are still not too obtuse imho, though who am I to talk I learn the joy of saved games today... damn.

Your second section about scanline shows that it can work! Great in my opinion. Though would still need to be colour-safe in terms of readable text and so on. Complimentary/Counter-Colours pairs could be an option. but that would get out of hand real fast.

Check out the palette switcher I made for my project when you have a moment. (its not the same aesthetic as the vanilla pico UI, but perhaps shows hot succinct it could be.
x

EDIT: that being said I just reread your last comment on the "32-colours please" thread and do agree with you more on some of the hardware clunkyness points.