dMZX Forums: SMZX mode improvements -> Archived Requests -> Tracker

SMZX mode 3 but with 256 separate palettes for up to 1024 colours.

Already implemented partially in one of my forks.

I am aware it wont work on 8-bit color depths. Considering showing a warning message in that case.

Updating status to: Awaiting Feedback

I'm pretty sure things that would introduce compatibility issues are things we're trying to AVOID, but please continue.

Updating version to: None

bonk

This would be cool if it were able to be implemented cleanly, because it would open up more graphical possibilities, but I have my doubts that it would flow with the rest of the source in its current state.

Asie, I kind of hope you can prove me wrong. I'd like to see the graphical capabilities of MZX be extended.

Would this be doable if there was still a 256 color palette but the 256 sub-palettes were configured to pull four user-defined colors from it? I think that'd essentially fix any issues with 8-BPP while still making the palette far more flexible than, say, mode 3. It'd also require a major save format change.

That is also a pretty good suggestion, Lachesis! But the save format change req worries me.

Well, at the moment the SMZX palette takes up 768B of the save file. This would require 1kB more to map colors to palettes; not a really a huge price to ask, and MZXEBML will give us a lot of flexibility adding new things to the save format. I don't know how well what's already in MZX internally would work with this though.

IIRC from forking 2.83, there won't be that much to change in order to make it work.

asie, when you're finished with this, a diff of the source (and/or the url to your github repository) would be appreciated.

I wouldn't be too worried about dropping support for indexed colour. Might be worth abandoning further adornment of SMZX in favour of a rework with compatibility modes.

OTOH I agree with Lach that in lieu of this, retaining compatibility with indexed colour modes is generally a good idea for the moment.

(BTW, I'm not completely sure I understand the impact of the proposed adjustment, maybe it can just share the SMZX mode 3 renderer, but if you make changes to the software SMZX render paths you need to update the shaders for GLSL.)

--ajs.

This post has been edited by ajs: 12 June 2012 - 07:58 PM

ajs: Since modes 2 and 3 already tend to have several repeat colors by nature, is there any way that the SMZX palette can be optimized into using as few indexed colors as possible? This would probably result in modes 2 and 3 looking perfect in indexed color mode the majority of the time, and would allow us to always reserve 16 colors of the palette for the UI, so we'd be fixing two issues here (UI palette and compat).

In the case where the palette can't be optimized down to 240 display colors or less, we'd need to start swapping in nearest colors (preferably in order of least usage on the screen), which would be essentially mandatory for mode 1 anyway. At this point, we'd be able to show N colors onscreen and the indexed color platforms would at least be able to show something.

To me, this sounds very doable "in theory", but I've also never touched any of the renderer files. Am I correct to assume that this sort of optimization would only need to be done in the software renderer (I'm guessing there's not going to be a high demand for shaders on a Nintendo DS)?

The SMZX and OS palettes are totally orthogonal so it is possible to 'compress' the SMZX palette upon updates of the OS palette. Some work would be needed when translating the 'graphics' object palette into something SDL can use, but that isn't enormously difficult or CPU-consuming. Substituting SMZX palette colors for others during this remap would also be easily possible; win95 used to do this. Similar story to the above. This hooks in with your suggestion of the 16 UI colors; I wouldn't reserve these though, I'd just subject them to the same 'nearest' matching logic. I'd say you're better optimizing for in-game performance (where the UI isn't as important) than editor performance. Folk using the editor probably aren't using an indexed color mode.

It does sound like only the SW renderer is affected. YUV has a compromised colorspace but that was a pre-existing limitation. The GX renderer (Wii) seems to also have a compressed colorspace. The GL renderers always work in RGB space and so are unaffected.

--ajs.

Updating status to: Implemented
Updating severity to: 2 - Fair
Updating version to: 2.90
Issue fixed in: GIT

While a new SMZX mode hasn't been added, the palette indexing suggestion from post #6 has been implemented as an extension of SMZX mode 3 by Lancer-X in GIT 4719b51.

Moving to: Archived Requests