Started by Max-Max, July 12, 2013, 11:22:42 AM
0 Members and 1 Guest are viewing this topic.
# define RGB color #000001 to be a Day/Night colour, alternating between Day #8888FF and Night #111144color = #000001, DN, #8888FF, #111144# define RGB colour #000002 to be a time triggered colour changing at hours 06, 07, 09, 12, 17, 18, 20, 21color = #000002, T, 06:#222266, 07:#333388, 09:#5555CC, 12:#8888FF, 17:#5555CC, 18:#333388, 20:#222266, 21:#111144
Quote from: Max-Max on July 29, 2013, 11:45:38 PMI was thinking that when an image asks for a colour it doesn't need to know if it is a special colour, the manager will know this from the requested colour and return whatever colour it should be replaced with because the manager knows what colours should be mapped to a colour ramp or not (from the PAK colour definition).
Quote from: Max-Max on July 30, 2013, 10:50:12 PMIt is our job to make complex things easy for the novice, meaning we handle the complexity, not the artist
Quote from: Fabio on July 31, 2013, 08:09:11 AMone idea if/when going rgb32 (with alpha) would be to remove special colors altogether and use 1 or 2 bw image masks to tell makeobj which areas should glow at night and which should be player-re-colored.
Quote from: wlindley on July 31, 2013, 08:33:01 AMI was hoping to use the already-reserved "player colors" (in the .png files), but have them handled differently for factories.
Quote from: Max-Max on October 05, 2013, 06:28:22 PMIn the current implementation he can set a RGB888 value, but instead of converting it to a RGB1555 value, just as his images are, it its mapped to an indexed colour. This may end up as something very different than the same RGB888 value he used in the theme.
Quote from: prissi on October 05, 2013, 07:59:04 PMOpenTTD uses 216 color and never had much a trouble with those colors. The actual difference of colors on a monitor will much larger than the differences on the screen. At least no artist complained so far.
Quote from: Ters on October 05, 2013, 08:05:07 PMThis not how it should be in my opinion. The variable that now holds the indexed color should hold the RGB555/565 color value, not an index.
Quote from: Ters on October 05, 2013, 08:05:07 PMIndexed colors are only needed if images need to refer to them. Is that the case?
Quote from: Max-Max on October 05, 2013, 08:46:21 PMI totally agree with you, but since no one is remaking this now the simplest solution was to extend the current system.
Quote from: Ters on October 05, 2013, 09:54:07 PMTouching the special colors, especially as a hack, is the last option. It affects way too many things. There should be half a dozen easier and better solutions.
Quote from: Ters on October 06, 2013, 02:42:43 PMThe special colors table has a layout designed for player colors, where one can go one index up or down within a block to get a brighter or darker player color. Generic colors don't fit into this structure. They would fit into rgbmap_all_day, but that's only used for recoding images, not the primitive drawing functions.
Quote from: Max-Max on October 06, 2013, 03:43:32 PMPS. Wouldn't it be a good idea to move all colour related code to simcolor.h and a Simcolor.cc ?? DS.
QuoteIf one day we moved to full RGBA32 would we have a concurrent simgraph32 or would we simply update existing files?
Quote from: Max-Max on October 06, 2013, 04:11:01 PMSo what approach would you recomed to implement the customized system colours.Obviously we need to store them somewhere and they need to be fetched somehow, probably indexed.
Quote from: Max-Max on October 06, 2013, 04:28:36 PMIf we encapsulate colour handling into objects it would be easier to add new formats, such as RGBA32 and have the correct conversion in the object.