reenigne wrote:

Brightness is just a constant value added to the composite signal, or equivalently luma (or equivalently R, G and B before doing […]
Show full quote

Brightness is just a constant value added to the composite signal, or equivalently luma (or equivalently R, G and B before doing any gamma correction). Probably the easiest way is to add it to luma, changing:

Copy code to clipboard

1Y/=4.0;

to

Copy code to clipboard

1Y = Y/4.0 + brightness;

If that doesn't look like NewRisingSun's images then I don't know what he's doing.

I did try something like that, letting brightness be adjustable between 0% and 200% (which works out to -1 and 1 respectively when applied to Y):

1Y/=4.0; Y+=(tv_brightness/100.0)-1;

but the result is somewhat different - see the screenshot attached.

NRS's images seem to fit in well with what was intended, at least going by the color names on the adjustment screen - e.g. white is still white, even though the brightness has been reduced. But with the above-mentioned method, reducing the brightness turns the white into a darker grey.

VileRancour wrote:

but the result is somewhat different - see the screenshot attached.

Yep, that makes sense since the algorithm as initially calibrated takes black to black and white to white, so turning down the brightness will turn white to grey.

I bet NewRisingSun is also adjusting the contrast when adjusting the brightness. You can add a contrast control like this:

1			Y = contrast*Y/4.0 + brightness;
2			I = contrast*I/4.0;
3			Q = contrast*Q/4.0;

And you can automatically adjust the contrast when adjusting the brightness to keep the white level the same like this:

1			contrast = 1 - brightness;

robertmo wrote:

Championship Baseball
http://www.mobygames.com/game/dos/championship-baseball
This one is strange as it looks it is for the old one as the new one will have blue grass. Although both have green sky 😉

game has also got mode 6 support so mode 4 is not needed.

reenigne wrote:

You can add a contrast control like this: […]
Show full quote

You can add a contrast control like this:

Copy code to clipboard

1			Y = contrast*Y/4.0 + brightness;
2			I = contrast*I/4.0;
3			Q = contrast*Q/4.0;

And you can automatically adjust the contrast when adjusting the brightness to keep the white level the same like this:

Copy code to clipboard

1			contrast = 1 - brightness;

Thank you - that works nicely enough.

Patch is attached; here's what's changed -

• "cga=old|new" is now changeable from the command line
• flipped back the sign on hue_adjust (for consistency with current DOSBox)
• brightness and saturation can be adjusted as follows:
  
  Increase brightness - Alt-F1
  Decrease brightness - Ctrl-Alt-F1
  Increase saturation - Alt-F2
  Decrease saturation - Ctrl-Alt-F2

These are just temporary key assignments. I don't know if I like having all of these functions in the mapper (for a finalized patch), but for now this will make it easier to test a big bunch of games and conclude how much control we'd really need.

VileRancour wrote:

These are just temporary key assignments. I don't know if I like having all of these functions in the mapper (for a finalized patch)

A key for switching between functions could decrease amount of entries in the mapper to even 3 (so the way it is now). And I think it is always better to have these functions even in this form in the mapper compared to not having them at all. They are not that important so don't have to be easily accessible, but if you need them you would have them.

VileRancour wrote:

but for now this will make it easier to test a big bunch of games and conclude how much control we'd really need.

Actually it would be way easier if you added cgaold/new to the mapper too, as right now it is far from easy -try comparing a flight simulator during flight 😉 - i am still using the old build with alt-f10 feature ripsaw did. So could you add a switch for that too?

Edit: I noticed ripsaw didn't enclosed the .diff for his switch, so could you enclose that .diff if that could help?

robertmo wrote:

A key for switching between functions could decrease amount of entries in the mapper to even 3 (so the way it is now). And I think it is always better to have these functions even in this form in the mapper compared to not having them at all. They are not that important so don't have to be easily accessible, but if you need them you would have them.

Yes, but once again I believe that this approach would create a confusing user experience. Now that I think about it, if the default adjustable function is hue, then most users might not even notice the change... still, since the brightness/saturation adjustments are rarely needed, they could also be controlled from the config file and changeable from the command line.

Actually it would be way easier if you added cgaold/new to the mapper too, as right now it is far from easy -try comparing a flight simulator during flight 😉 - i am still using the old build with alt-f10 feature ripsaw did. So could you add a switch for that too?

Sure, attached is a complete .diff - functionally the same as the one above, I just added an Alt+F10 switch like ripsaw's to toggle the CGA type, instead of the command line option.
This brings us to 8(!) key bindings for composite video control... useful for testing, but probably not very appropriate for your everyday DOSBox user.

For a final patch, we seem to have the following options:

• Separate keymapper entry for each control (hue+/-, brightness+/-, saturation+/-, CGA type, composite auto/on/off). Versatile but uses up a ton of keys.
• Your suggestion (one key to switch the adjustable property, two keys to dial it up and down, one for composite auto/on/off). Versatile without using up a ton of keys, but could be confusing.
• Control CGA type/brightness/saturation from the config file / command line instead of the keymapper (just add one key for composite auto/on/off). Elegant but prevents in-game adjustment of the new properties.
• Forget about brightness/saturation, keep hue, and just add one key for composite auto/on/off. Simplest solution, but sacrifices those games that actually need brightness/saturation adjustments.

At this point I honestly don't know what would be best. If Qbix is still reading this, maybe he could weigh in on the issue. 😀

since mame style dialog box already mentioned before:

Key only needed to invokes the dialog box,
pause the emulation while the box is active (recommended),
on the box there various adjustable sliders or other controls,
that sliders will updates the screen appearances as those sliders were changed.

Its prefered to have numerical values for each sliders, thats values were needed for:
- Add another command in Z: to facilitate appearance changes in automated batch files. (like 'mixer.com' but for CGA display).
- or using that numerical values for config file for initial/start-up settings.

Cons:
add more complication to existing codes/frameworks than VileRancour's options.
nowhere as fast as using key-options.

I have remapped to:

ctrl+alt+f1 brightness-
ctrl+alt+f2 brightness+
ctrl+alt+f3 saturation-
ctrl+alt+f4 saturation+
ctrl+alt+f9 hue-
ctrl+alt+f10 hue+
ctrl+alt+f11 old/new

notice how easy adjustment is now: you just keep ctrl+alt pressed and adjust everything you want intuitively.

f12 has to stay without ctrl+alt cause dosbox resets focus on rgb/comp switching and ctrl+alt would have to be released and pressed again which is not convenient.

Joey_sw wrote:

since mame style dialog box already mentioned before:

That was a bit of a joke really. At any rate, it's pretty much guaranteed not to happen 😉

robertmo wrote:

I have remapped to: […]
Show full quote

I have remapped to:

ctrl+alt+f1 brightness-
ctrl+alt+f2 brightness+
ctrl+alt+f3 saturation-
ctrl+alt+f4 saturation+
ctrl+alt+f9 hue-
ctrl+alt+f10 hue+
ctrl+alt+f11 old/new

notice how easy adjustment is now: you just keep ctrl+alt pressed and adjust everything you want intuitively.

Thanks - yes, that's quite a bit easier.
The question remains though, do we really need so many controls for a final patch? Maximum control is good for testing, and for figuring out what settings work best for a given game, but so many controls could be daunting for the general user; and as has been said, there's generally no need to adjust most of these things during the course of a game. If anybody else has an opinion on this, please share.

For one, I think the CGA card type (old/new) could stay in the config file, which is where video cards are normally selected (though it's not a machine type). Obviously you can't hot-swap video cards on a real system, anyway.

Saturation could be hard-coded as well, since current results are over-saturated compared to reenigne's actual TV photos, and the reason has been found (burst signal amplitude). Earlier there was some talk here about doing that - I will test and post some results.

I tested some of the earlier talk about hard-coded saturation values and color correction:

NewRisingSun wrote:

In the old CGA, burst is too large, so saturation (or composite) should be reduced to 56% of the original. In the new CGA, it is too small, so saturation should be increased to 143% of the original, making mode 6 games extremely oversaturated.
...
I'm against a saturation control as well; the algorithm should bring it to reasonable levels by itself. That means for mode 6 games, existing saturation should just be reduced to 56% regardless of CGA setting, then the NTSC-to-709 transformation applied. For mode 4 games, I'm less certain, but I tend to favor taking the unadjusted old CGA amplitudes.

reenigne wrote:

I strongly feel that whatever saturation correction we apply it should be the same for all modes. After all, no real monitor knows which mode the CGA card is running in.

with Old CGA, the hard-coding approach seems to work quite well. These 4 images were all obtained with cga=old and with saturation set to 60%. The NTSC-to-709 transformation is applied (I enabled the previously-disabled "#if 0" code).

Click for full size: as you can see, the saturation appears just about right for all colors, no over-saturated reds. The same value works well for both mode 6 (Tapper, Bruce Lee) and mode 4 (Decathlon, Below the Root). In particular, Bruce Lee now looks much closer to reenigne's TV photo:

So for Old CGA, this would seem to be the right approach. New CGA may be a little more problematic: the NTSC-to-709 transformation looks extremely bad unless you reduce the saturation, but that makes some mode 4 games look too desaturated (and doesn't appear to be justified in theory, either). I'll try to test this some more later, though.

About brightness, I'm not too sure: we've only found one game so far that needs any brightness adjustment (Championship Golf), and I doubt that there's any way to let the code determine an optimal value in each situation.

If you really need to use function keys at all, please at least let me set an initial hue and brightness setting in the configuration file. For most games, it becomes quickly obvious which setting is best, and I shouldn't have to adjust it with function keys every time I run the game.

VileRancour wrote:

New CGA may be a little more problematic: the NTSC-to-709 transformation looks extremely bad unless you reduce the saturation

Be sure to clamp R, G, B values before (and after) NTSC-to-709 adjustment.

But the saturation problem with new CGA matches my experience with the Tandy 1000, whose composite circuit is based on the new CGA. So it's not really an emulation problem, but a problem with the real hardware.

Should DosBox compensate for this, in the spirit of user-friendliness? I think so. That's why I suggest using the color burst amplitude as you described for old CGA and for new CGA in mode 4, but using old CGA saturations whenever new CGA is in mode 6.

VileRancour wrote:

and I doubt that there's any way to let the code determine an optimal value in each situation.

Well, Championship Golf is the only game I'm aware of that uses an intensity color as color #0, so that might be an idea.

By the way, regarding brightness: are you removing the 7.5% black level setup, as you should? Only if you remove it does Burger Time's monitor test screen look right, with the "R" fully disappearing as it should (with old CGA).

NewRisingSun wrote:

If you really need to use function keys at all, please at least let me set an initial hue and brightness setting in the configuration file. For most games, it becomes quickly obvious which setting is best, and I shouldn't have to adjust it with function keys every time I run the game.

That's fine by me - I'm all for minimizing the amount of button-mashing needed to set a value (especially after having tested a bunch of games in a row now)... Config file settings can also be made changeable from the internal command line, so that would give additional flexibility, in the form of batch files for instance.

Be sure to clamp R, G, B values before (and after) NTSC-to-709 adjustment.

But the saturation problem with new CGA matches my experience with the Tandy 1000, whose composite circuit is based on the new CGA. So it's not really an emulation problem, but a problem with the real hardware.

Should DosBox compensate for this, in the spirit of user-friendliness? I think so. That's why I suggest using the color burst amplitude as you described for old CGA and for new CGA in mode 4, but using old CGA saturations whenever new CGA is in mode 6.

It's not as if we're really fixing a problem with the real hardware, as long as the original hardware has a way around the problem (the TV's saturation control); we're just picking an optimal value. Which I have no problem with, but I still think it would be preferrable to find one that works nicely for all modes. The NTSC-to-709 conversion already seems to add a bit of saturation in itself, so for the new CGA perhaps something a bit higher than 56% would do the trick (say 70%?) - I'll do some more testing later.

Well, Championship Golf is the only game I'm aware of that uses an intensity color as color #0, so that might be an idea.

True, but some non-intensity colors might need a bigger adjustment than some hi-intensity colors; take #7 and #8. At this point, though, I'd be happy to relegate the brightness to a configuration setting as well, since it's becoming clear that we can't cover all bases without some sort of [composite] config section (or a whole lot of ctrl-alt-F# bashing).

By the way, regarding brightness: are you removing the 7.5% black level setup, as you should? Only if you remove it does Burger Time's monitor test screen look right, with the "R" fully disappearing as it should (with old CGA).

I am now - thanks for the heads up. 😀 Added it just after the YIQ-to-RGB transformation, before R, G, B are clamped and passed to the NTSC-to-709 matrix. Hope that this is the right place (the attached screenshot seems to say so).

For anyone else who wants to test, here are the changes from my last patch: in vga_other.cpp, find the "#if 0"..."#endif" section and replace it with

1			static const double gamma = 2.2;
2
3			double R = Y + 0.9563*I + 0.6210*Q;	R = (R - 0.075) / (1-0.075); if (R<0) R=0; if (R>1) R=1;
4			double G = Y - 0.2721*I - 0.6474*Q;	G = (G - 0.075) / (1-0.075); if (G<0) G=0; if (G>1) G=1;
5			double B = Y - 1.1069*I + 1.7046*Q;	B = (B - 0.075) / (1-0.075); if (B<0) B=0; if (B>1) B=1;
6			R = pow(R, gamma);
7			G = pow(G, gamma);
8			B = pow(B, gamma);
9
10			int r = static_cast<int>(255*pow( 1.5073*R -0.3725*G -0.0832*B, 1/gamma)); if (r<0) r=0; if (r>255) r=255;
11			int g = static_cast<int>(255*pow(-0.0275*R +0.9350*G +0.0670*B, 1/gamma)); if (g<0) g=0; if (g>255) g=255;
12			int b = static_cast<int>(255*pow(-0.0272*R -0.0401*G +1.1677*B, 1/gamma)); if (b<0) b=0; if (b>255) b=255;

if every game had such a test we would know for sure what card it was meant to be used with 😉

Thanks for sharing a proper build.

After doing some tests with the color-corrected new CGA, 70% seems to be an optimal saturation value: color clipping is mitigated enough to differentiate the two blue colors in Blue Angels; mode 6 and mode 4 games look fine, with minimal over/under-saturation (Tournament Tennis is sort of an extreme case, since it's a rare example of using the darkest palette available). Once again screenshots are attached.

TODO, hope to get to this soon:

- hard-code the different saturation values for old and new CGA
- move cgatype, hue and brightness to a proper config file section
- see about adding composite support for tandy/pcjr machines

About this latter point: we know what changes are needed for Tandy - use New CGA encoding, offset hue by +120° in mode 6 and -45° in mode 4. But what about the PCjr?

Youtube has some PCjr video captures (1, 2) and the colors look virtually identical to New CGA with no other adjustments.... on the other hand, all the games shown use pure chroma colors so there's very little artifacting visible to put that theory to the test.

Another (minor) problem is that the auto detection won't work, since there's no such thing as port 0x3d8 on the PCjr.

VileRancour wrote:

Another (minor) problem is that the auto detection won't work, since there's no such thing as port 0x3d8 on the PCjr.

Auto-detection? How can it support color burst at all? 😉

The games in the videos appear to be using mode 8/9 16-color graphics, and although the PCjr does have a composite out, things will look better in general with a RGB monitor hooked up to the RGB out. If you're suggesting some kind of composite output for all modes, that would seem to be beyond the scope of the current patch.

ripsaw8080 wrote:

VileRancour wrote:

Another (minor) problem is that the auto detection won't work, since there's no such thing as port 0x3d8 on the PCjr.

Auto-detection? How can it support color burst at all? 😉

The games in the videos appear to be using mode 8/9 16-color graphics, and although the PCjr does have a composite out, things will look better in general with a RGB monitor hooked up to the RGB out. If you're suggesting some kind of composite output for all modes, that would seem to be beyond the scope of the current patch.

The PCjr's video can do everything the CGA can do and more, the functionality is just elsewhere. I would deduce that the PCjr., since it combines the pure RGB signals with the composite signal for 16 shades of gray, would show "new" CGA composite colors.

Tandy and PCjr. should be kept to RGB. If you want composite, select CGA. If you want, for whatever reason, to see how a Tandy generates CGA composite color, just set the Hue to 135 degrees. If you want to see what the RGB modes (8, 9, A) would have looked like on a TV, perhaps selecting an NTSC filter would be the better way to go.

Can you be a bit more specific than "elsewhere"? Is color burst always enabled on the CGA modes for composite output, or is there maybe a different mode register?

VileRancour wrote:

About this latter point: we know what changes are needed for Tandy - use New CGA encoding, offset hue by +120° in mode 6 and -45° in mode 4. But what about the PCjr?

In mode 4 the artifact colors on the PCjr are different than both CGA and Tandy (I have no idea how far the hue is offset by; if any one is interested I can do some captures when I get a chance). Offhand the only game I can think of that utilizes this is Below the Root; it's really CGA mode 4 no matter what machine you have, but on a PCjr it uses different color patterns so on a composite monitor the results look similar to the CGA composite version. In mode 6 I think PCjr should be same as new CGA with no offset (though that's from memory, I would need to double check that).

The PCjr does not implement the CGA Mode Control or Color Select Registers at 3D8h & 3D9h, but it does implement the Status Register at 3DAh with some differences. For write operations, the video gate array at 3DAh implements five control registers and sixteen palette registers. Mode Control 1 Register is at index 00 and bit 2 turns on or off the composite color burst.

Another thing to note is the CGA and PCjr. defaults. An IBM PC with CGA defaults to the colorburst being on, the PCjr. defaults to it being off. I am not sure what that is supposed to mean, since the text modes do not display the colorburst on startup.

Run the below program and take pictures of the output, that will show what the colors are supposed to be.