robertmo wrote:It looks what NewRisingSun wants to achieve by making colours prettier by making red more reddish and brown more brownish or providing knobs for people to regulate like reenigne suggest is simply not possible, cause game programmers were using one color as more then one color even in one game. As a result they could use not only 16 colors of cga card (which are definitely not enough to reproduce reality) but actually twice more (ore even more). For example cyan can be used as green or blue, orange can be used also as brown, brown as green, green as yellow, purple as red, etc. Or yellow as 100 different shades of yellow This can be corrected now in dosbox if we make colors look as middle option between two colors.
I think I understand what you are saying now, but I don't think DOSBox can (or should) do anything to solve the problem you're talking about.
If I'm understanding it correctly, the problem is this: There are some games where the art was originally made for EGA/Tandy/PCJr 160x200 16 colour mode (which has the standard RGBI colours) but which also support composite CGA (which has a completely different set of colours). However, the art was not redrawn to be optimized for composite CGA - instead (to save development effort and disk space) the developers just stored the original RGBI images along with a mapping (or possibly multiple mappings - some images might look better with one mapping than another) to convert between the RGBI colours and the composite CGA colours. These mappings were not even necessarily consistent between versions of the game (I've heard about DOS and Booter versions of the same game with the same art having different mappings).
These mappings have two (conflicting) goals: one is to make the image look as close as possible to the art as the artist originally envisaged it, the other is to use as many as possible of the composite CGA colours so that the game looks as colourful as possible. Remember also that these mappings are a part of the game, not a part of DOSBox (DOSBox has no idea, when a CGA composite pattern is drawn, what, if any, RGBI colour inspired it).
So there are two lossy transformations that happen to the image between the artist's mind and the CGA composite screen: one when it's converted to RGBI colours and a second when those RGBI colours are converted to CGA composite (not necessarily even using the closest colour). So it's little wonder that some of the CGA composite images from these games look very different to the box/concept art.
Now, if we try to "tweak" things with the explicit aim of making specific CGA composite images look better and/or more like the corresponding RGBI images, we're bound to make things look worse overall. That's because there are many games with many different RGBI->composite mappings (and many composite games with composite-specific art that was not derived from an RGBI image at all). If, for any given composite dot pattern, you look at all of the "original art" colours that map to that dot pattern across all games, you'll find that the colour in the middle of all those colours is the same as the average colour that that dot pattern produces over all the composite monitors used by the game designers, which in turn is going to be something pretty close to the ideal colour for that dot pattern that the NTSC standards demand.
That's why I want DOSBox to try to be as true as possible to NTSC rather than looking at any particular game to try to determine what the colours are supposed to look like. Looking at particular games is interesting when it seems like they're interpreting composite dot patterns in an unusual way, i.e. the colours are completely wrong because unusual hardware was used in the development (e.g. using a Tandy 1000 instead of an IBM CGA card, or using a monitor with a comb filter) but otherwise we shouldn't really worry too much about the colours in any particular game looking a bit off.