Started by Max-Max, July 12, 2013, 11:22:42 AM
0 Members and 1 Guest are viewing this topic.
r6586 | kierongreen | 2013-07-12 14:56:57 +0100 (Fri, 12 Jul 2013) | 1 linePIXVAL typedef moved to simgraph.h
Quote from: Max-Max on July 12, 2013, 10:03:15 PMI was only looking for an easier way to define a colour for highlight, shadow, text etc... An index number doesn't say much and the limited index table doesn't offer to many colours either.
QuoteI believe GUI colors should work like regular image colors...
QuoteWhen specifying colors in the theme file, rather than painting them directly in images...
QuoteWhen reading in a theme that doesn't define a particular color for a theme element, a default color should be assigned for it during loading of the theme...
QuoteOr is it really necessary for GUI images to be recolored by the theme tab file?
Quote from: prissi on July 28, 2013, 10:56:57 PMAs for now, the RGB is just translated into the best matching color index. Why is this not enough for the moment?
Quote from: Max-Max on July 28, 2013, 11:45:57 PMI think it would be good to create a colour class with member functions for colour manipulation. You could for example add two colours with a simple operator+(), get the index of nearest matching colour in the special colour table, blend a colour with alpha from another colour etc...
QuoteI don't think one should ever go from a color to an index, only the other way. You never know what index you end up with, what that index is for, and that index might stand for a very different color at different times.
Quote from: Max-Max on July 29, 2013, 09:24:44 PMThe benefit of having one colour manager is that you don't need to know anything about colour tables, night colours, player colours etc...
# 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.