rendlay.cpp: Add support in the layout color component to specify colors by hex rgb(a) values.

[cbrunschen]

Also uses the Ensoniq VFX family of layouts to show it working, and adds a bit to the documentation.

[Gurudumps]

Maybe instead of using the hex word just use # before the number within the quotes like SVG does.
Example in svg would be: stroke="#00ff00" which makes it green.

[cbrunschen]

Maybe instead of using the hex word just use # before the number within the quotes like SVG does. Example in svg would be: stroke="#00ff00" which makes it green.

The colour has to be specified as some attribute of the <color> component. Neither of the existing red, green, blue or alpha attributes would be a good choice for that. So, a new attribute is required - I chose to call it hex because that describes what it contains: a hexadecimal version of the colour, much like you'd encounter in SVG or HTML.

In SVG or HTML, the colour is applied through a color or fill or stroke or background attribute on another element. And both HTML and SVG have to be able to handle both named colours such as "white", "black", "teal" etc, and hex colours. So they need a way to differentiate between named and directly specified values, which is where the # mark comes in: it differentiates a hypohetical named colour "fadefa" from the hex colour value "#fadefa".

But here, where we're not looking to handle named colours on an overloaded attribute, we don't need the # to differentiate them. Indeed, if we did want to support named colours, that could then be done with a separate attribute; but really that wouldn't be needed, because named colours can already be very nicely handled by using the existing <param> facility:

<param name="color_background" value="101010" />
<param name="color_text" value="9a9a5a" />
<param name="color_highlight" value="ff4a4a" />

<rect ...>
  <color hex="~color_background~" />
</rect>
<text ...>
  <color hex="~color_text~" /?
</text>

[MooglyGuy]

But here, where we're not looking to handle named colours on an overloaded attribute, we don't need the # to differentiate them.

It isn't needed, but inconsistent semantics in that regard violates the fundamental rule of UX, the Principle of Least Surprise.

Will it at least still work in those situations if there is a leading hash mark? If yes, I see no reason why this can't go in. If not, please add functionality to discard a leading hash mark.

[happppp]

Better not name the parameter hex, go for something more descriptive like rgb and rgba.

In MAME lay files, it's a 0x or $ prefix for hex numbers. # is for decimal numbers. https://docs.mamedev.org/techspecs/layout_files.html#numbers
It would also be nice if animation still works: https://docs.mamedev.org/techspecs/layout_files.html#view-item-animation

[MooglyGuy]

All due respect to @cuavas, as I'm not sure it was his choice or if this pre-dates his involvement with the layout system, but using # as a prefix for decimal numbers makes MAME an outlier. The majority of art packages, as well as the whole wide world of the web, uses # as the prefix for hex color constants.

It would be a breaking change, but rather than digging our heels in on making MAME more awkward for new contributors by forging our own UX path that isn't reflective of most common use cases, it would be a good time to re-think the representation of color constants in layout files.

[Gurudumps]

The point of the # was to use standard nomenclature that is already used in many places. In Photoshop the hex values can be obtained directly from the palette tool (this is how I get my color values for the layouts). The other standard is RGB. The way MAME requires a number from 0 to 1 for colors is pushing more non-standard 'invented-for-MAME b.s.' that over-complicates something that was solved 160 years ago LOL. To get those numbers you have to take the common separate RGB values and divide each one by 255 which gets annoying very quickly.
With RGB or hex numbers it brings MAME one step closer to the standards, at least for color naming.
In Photoshop the # is not required and that could also be done in MAME. The check can be as simple as looking for a single 6-digit number and if found it must be a hex number then treat it as one.
The other bonus of using hex rgb is you just put 'color=rgb 123456' (or whatever format is finalised) thus saving lots of typing and about 20 or more bytes on every color command.
The existing non-standard numbers can be left as-is so not to break existing layouts. The check there is simply look for any number between 1.0 and 0 having a decimal point.
The color codes used in layouts are somewhat abused... I stick to 3 decimal places which is plenty for any color to be rendered correctly but I've seen some numbers used with as many as 8 decimal places.

[cbrunschen]

Better not name the parameter hex, go for something more descriptive like rgb and rgba.

I chose hex because it describes the format of the value - which can handle both rgb and rgba values, just by specifying 6 or 8 hex digits. rgb or rgba would be slightly confusing if it also accepted the other format - and if they did not, then we'd need to support both rgb and rgba attributes, which seems unnecessarily complex.

In MAME lay files, it's a 0x or $ prefix for hex numbers. # is for decimal numbers.

By using the attribute hex there is no ambiguity or need for a prefix - the fact that these are hex numbers is right there.

In the particular case of layouts, it also avoids any ambiguity of the # prefix - does it indicate a hexadecimal value as is common elsewhere, or a decimal one as used in MAME layouts?

https://docs.mamedev.org/techspecs/layout_files.html#numbers It would also be nice if animation still works: https://docs.mamedev.org/techspecs/layout_files.html#view-item-animation

Animation continues to work. Look at the (piano) keys on any of the keyboards: their colour is animated depending on the position where you press (or mouse down) on the key, and further animated if you move the touch/mouse up / down.

Each key looks like:

<element ref="keyshape_0" id="full_keyboard_key_0" clickthrough="no">
  <bounds x="0" y="0" width="22.5" height="138" />
  <color state="0" hex="f2f2e6" />
  <color state="1" hex="2c44ad" />
  <color state="127" hex="19a14d" />
  <color state="128" hex="e6ce48" />
  <color state="255" hex="ce3f06" />
</element>

Colour is then animated by the Lua script:

key.item:set_animation_state_callback(function()
  new_state = 0
  if key.pressure > 0 then
    new_state = 128 + key.pressure
  elseif key.velocity > 0 then
    new_state = key.velocity
  else
    new_state = 0
  end
  if new_state ~= key.animation_state then
    key.animation_state = new_state
  end
  return new_state
end)

So what is animated is the animation state, and the layout system uses the <color> elements with their hex attributes and correctly interpolates between them.

[felipesanches]

Why not use <color fill="#ce3f06" /> (even while stroke is not yet supported)?

[cbrunschen]

Why not use <color fill="#ce3f06" /> (even while stroke is not yet supported)?

The <color> element does not apply to just fill or stroke or similar. Instead, a <color> is effectively multiplied with the component to which it applies. So, a, SVG image can contain multiple different grey levels, which then, when multiplied by the <color>, generates different levels of the specified colour:

Each component may have a color child element specifying an RGBA colour (see Colours for details). This can be used to control the colour of geometric, algorithmically drawn, or textual components. For image components, the colour of the image pixels is multiplied by the specified colour. If no such element is present, the colour defaults to opaque white.

I am not trying here to make any fundamental changes to the layout rendering system - just to allow specifying colours as a single hex value, rather than requiring a combination of up to four different values.