zx332 (Palette Tool)

Discuss ZX Spectrum Next Games, Tools and more.
Post Reply
User avatar
zingot
Posts: 7
Joined: Wed Dec 12, 2018 1:30 am

zx332 (Palette Tool)

Post by zingot » Thu Dec 27, 2018 5:57 pm

Screenshot_3.png
Screenshot_3.png (61.08 KiB) Viewed 875 times
zx322 is a palette organisational tool which allows both programmers and artists alike to build colour palettes derived from the ZX Next fixed 256 colour palette. This tool can be used in a number of ways, but I'll briefly explain the save options to show how it could be used.

- Copy Colour
Select your colour cell, click the copy button and then select the cell the colour is to be copied to. Alternatively use "C" as a keyboard shortcut.

- Swap Colour
Select your colour cell, click the swap button and then select the cell the colour is to be swapped with. Alternatively use "S" as a keyboard shortcut.

- Ramp Colour
<Not yet implemented>

- Load Palette
Palette in Microsoft RIFF (.pal) format to load back into zx332 or your paint package of choice.

- Save Palette
Palette saved in Microsoft RIFF (.pal) format. The colours will be the same as those depicted in the ZX Next palette but will be in the order organised in zx332.

- Save Bitmap
BMP indexed image file with pixel data depicting the colours organised with the correct indices from the ZX Next palette. This is most useful for generating artwork (eyedropper usage).

- Save Hex
Text grid (16x16) of hexadecimal values representing the ZX Next indices of the colours defined when using the save palette option.
Screenshot_4.png
Screenshot_4.png (18.41 KiB) Viewed 875 times

DOWNLOAD zx332_v0.019a.zip
0.019a - Fix in RIFF header when saving palette.
Last edited by zingot on Fri Dec 28, 2018 7:57 pm, edited 2 times in total.
Old Skool Pixeller

Xalior
Posts: 2
Joined: Sun Jun 10, 2018 7:33 pm

Re: zx332 v0.018a (Palette Tool)

Post by Xalior » Thu Dec 27, 2018 10:07 pm

That's a really beautiful interface :)

-Dx

Ped7g
Posts: 109
Joined: Mon Jul 16, 2018 7:11 pm

Re: zx332 v0.018a (Palette Tool)

Post by Ped7g » Fri Dec 28, 2018 12:40 am

Very nice.

But why only 3:3:2 colours, and not full 3:3:3? And as programmer I miss the hexa view of currently selected colour (in the 3:3:2 way, or optionally 3:3:2 + 7:1 for 3:3:3 colour mode, like "$1F01" for bright cyan (0,255,255)), so I can just copy (copy to clipboard upon click?) it into code for some quick experiments, without saving/loading any files.

Also you show saving indices, instead of colours... are you aware the NEXT palettes are editable, and the default palette can be modified? And that full output capability of NEXT is 3:3:3, i.e. 512 colours? (you are limited to 256 colours in single palette, but you can mix up palette from 512 total colours) The "save next indices" in hex mode - as long as we talk about default Layer2 NEXT palette, is basically same as saving 3:3:2 colour values, so I would rather present it like that, saving 3:3:2 colours, particular index in palette may contain different colour if one is using custom palette.

User avatar
zingot
Posts: 7
Joined: Wed Dec 12, 2018 1:30 am

Re: zx332 v0.018a (Palette Tool)

Post by zingot » Fri Dec 28, 2018 1:28 am

Xalior wrote:
Thu Dec 27, 2018 10:07 pm
That's a really beautiful interface :)

-Dx
Thank you very much :-)
Old Skool Pixeller

User avatar
zingot
Posts: 7
Joined: Wed Dec 12, 2018 1:30 am

Re: zx332 v0.018a (Palette Tool)

Post by zingot » Fri Dec 28, 2018 1:39 am

Ped7g wrote:
Fri Dec 28, 2018 12:40 am
Very nice.

But why only 3:3:2 colours, and not full 3:3:3? And as programmer I miss the hexa view of currently selected colour (in the 3:3:2 way, or optionally 3:3:2 + 7:1 for 3:3:3 colour mode, like "$1F01" for bright cyan (0,255,255)), so I can just copy (copy to clipboard upon click?) it into code for some quick experiments, without saving/loading any files.

Also you show saving indices, instead of colours... are you aware the NEXT palettes are editable, and the default palette can be modified? And that full output capability of NEXT is 3:3:3, i.e. 512 colours? (you are limited to 256 colours in single palette, but you can mix up palette from 512 total colours) The "save next indices" in hex mode - as long as we talk about default Layer2 NEXT palette, is basically same as saving 3:3:2 colour values, so I would rather present it like that, saving 3:3:2 colours, particular index in palette may contain different colour if one is using custom palette.
I downloaded 64spr.bmp from Jim Bagleys sprite tools page, and used that as my basis for the Next palette presuming it was fixed and only RRRGGGBB. :oops: lots of stuff to amend and rip out :)

OK so in laymans terms can you tell me when it's 332 and when is it 333 ?confused?
Old Skool Pixeller

Ped7g
Posts: 109
Joined: Mon Jul 16, 2018 7:11 pm

Re: zx332 v0.018a (Palette Tool)

Post by Ped7g » Fri Dec 28, 2018 6:40 am

Ah, ok, so you were not aware (I can certainly understand that, if you are not following Next development daily both in forums and facebook and everywhere, it's sort of simple to lose the track of the development)...

So, summary of current state (I'm not member of core team, so if I'm wrong, hopefully somebody from core will step in and explain):

The HW side has DAC (digital-to-analog-converter) capable of 8 levels of electricity current, which limits colour channel to 3 bits at most at final output (value 0..7), that's the reason why final total colours are 3:3:3 (512 of them). This was part of original design (and if this will change with current Next boards, it would be quite an engineering miracle, so you can take that as "set in stone").

There was initially a way to modify single palette item by sending 8 bits only: RRRGGGBB, the 9th bit for blue was calculated as OR between the provided BB bits, i.e. "00" produced "000" and anything else in "BB" produced "BB1", cutting down the 512 colour space into 256 colour space, effectively. This mechanism still exist, and the hexa values you are producing are ready to be used for that. (NextReg $41) - this still does set up full 3:3:3 colour, but from 8 bits input only.

There is now another NextReg $44, where you can send two bytes for single index, the bits are: RRRGGGBB, p000000B - allowing you to set up full 9 bit 3:3:3 colour (the single B in second byte is the least significant bit of blue).

Also you may have noticed certain "p" in that bit description, that's "priority" bit, which works only for colours set for "Layer 2" graphics, and they will make the pixel in "layer 2" with such colour to jump on top over sprite pixels, even if layers are in order where sprites are above layer 2, i.e. one can create subtle details in background image, like grass or signs, which appear in front of sprites, even if the rest of background is behind sprites. (I'm going into such details for you, because I guess some graphicians/coders may be interested in tooling which allows them to work also with priority bit, because then you may need the same colour twice in palette, if some graphics is supposed to stay "behind" and other of the same colour is supposed to appear "in front" of sprites).

There are 6 palettes in total, each has 256 colours, and they are strictly tight down to different layers (each layer has 2 palettes, i.e. primary/secondary, only one is active at time): ULA-layer (classic ZX with Next colours/Timex mode and LoRes 128x96x256 mode), Layer 2 (256x192x256 only) and Sprites (palette is 256 too, but it's worth another paragraph of note later) - all of these palettes are from your editor point of view identical, they have 256 colours (items/indexes) and each item can be set to 3:3:3 colour by that NextReg$44 (but Layer2 will also accept "priority" bit). = So one can have all 512 colours displayed at the same time at screen, by using 256 of them for example for Layer 2, and other 256 for LoRes ULA mode (with static image, without some trickery like changing palette while display is being generated), but from your tool point of view there's no big difference, each palette is 256x 3:3:3.

What makes difference to your current setup is, that any index can contain any colour, i.e. indexes are not describing colour (they do after power-on in Layer2 palette, each index is set to the 8bit colour of it's value, but any SW can change that and upload its own palette).

The transparent colour for ULA layer and Layer2 is 8bit colour, setup by default as $E3 (11100011 = RGB(255,0,255)), the SW can modify it, but only 8 bits can be set, and the 9th bit is not compared (i.e. two colours from 512 total space are "transparent") - it's what wiki says, but I'm not sure if there was actually change to make the compare full 9 bit, so only one colour from 512 is transparent, and it's always the one with bottom blue bit set by some rule (0?), for artists this is probably no big deal, just pick one colour which you want as transparent (and is enough distinct from the ones you want to display). The compare is colour-based, so you can have several items in palette set to that same transparent colour (waste of resources, and probably not relevant to your tool, JFYI how it works internally)

The transparent colour for sprites is index-based, i.e. 0..255 for particular index in the palette, so this is different from above.

And that extra note about sprites... sprites can be currently both 8-bit and 4-bit, i.e. 256 or 16 colour palette (both can be used at the same time by different sprites, it's per-sprite feature). For 4-bit sprites the transparent "index" set does test only bottom 4bits of it (again something not to worry if you are an artist, just put that pink/violet/whichever you want colour into "transparent" pixels in images with sprites and let coder to deal with it) (transparency index is checked before "offsetting" described in next paragraph).

But, each sprite has "offset 0..15" in definition, which allow to offset all sprite pixels in colour space by multiples of 16, i.e. pixel with value 74 (pointing at sprite palette index 74) can be offset by 192 (12*16), so instead colour 10 (266 truncated to 8b) will be used. So you can have on screen several sprites, each using the same graphics data, but offsetting the colour differently, and if you prepare your palette for that, having like for example three sub-palettes being +32 apart, you can have the same sprite in three different colour sets. (with 4-bit sprites you can have 16x 16 colour palettes, i.e. still using 256 colour sprites, just limited to 16 colours sub-palette per single sprite). Maybe you can work with that in UI too, your palette view is already 16x16 so in case 16 colours sub-palettes are being designed, one can view each sub-palette under each other, but maybe also 32x8 and 48x5.333 and 64x4 may be handy for verifying each index is at the "same" position within each sub-palette defined.

And one more extra bit of information, there are two new modes in ZXN allowing to mix two pixels together, the two possible mix modes are (for each colour channel) like: C = C1 + C2 clamped to 7 (if result is above 7), and second mode is C = C1 + C2 - 5, clamped to 0..7 (i.e. result under 0 is set to 0 and above 7 to 7). Not sure how much that is relevant to your tool, if in some version v72.0 you will add also mixing-preview... :)

----- so in some shorter summary ---
Every palette item in Next is 3:3:3 (although you can set it up by 3:3:2 value, which will expand to 3:3:3 automatically).
Each palette is 256 items big (256x9 = 2304 bits per palette), index 0..255.
All graphics is (max 8 bit) index-into-palette based (B&W 512x192 timex hi-res mode does use the ULA palette probably too, although only two colours of it), although not always full 8 bit indexes are used.

So what you have now seems to me already very useful. Maybe allowing 3:3:3 total colour space as first change. And then rethinking how to load/save/hex in a way to preserve also index information, and allow for index re-organization, that would probably cover all basic needs of everyone. Then the extras like mixing modes preview or sprite offsets... (depending how much you want to play with this project)

... reading it before submitting, that 6 palette info seemed to me a bit useless, but thinking about using your tool, it may be handy to have multiple palettes opened at the same time, and allow for blocks copy/paste, as many times one would probably want same basic colours in both layer 2 and sprites palette, etc.. (but different extra colours in other parts of palette).

(edit: had some typo in one value, so there was jump from 47 to 74 for no obvious reason, should have been 2x 74)

User avatar
zingot
Posts: 7
Joined: Wed Dec 12, 2018 1:30 am

Re: zx332 v0.018a (Palette Tool)

Post by zingot » Fri Dec 28, 2018 1:02 pm

Thank you for the detailed response. I will need to digest everything you have outlined here to be sure I begin implementing correctly. From what I'm gathering the palette choice is exactly the same as the AtariST (0-7 values 3bit colour range), so I can, as you suggest immediately implement 3:3:3 as for everything else I will need to sit down and take it all in =)

Thought I'd edit this reply, and show off some work-in-progress pixels as I try to figure out a new layout and what's needed.
View Full-Size
Attachments
zx333_bkg.png
zx333_bkg.png (8.53 KiB) Viewed 799 times
Old Skool Pixeller

Post Reply