Add PCjr CGA composite output (1 of 2)

[kcgen]

Merges NewRisingSun's PCjr composite patch. This addresses the first part of the eXoDOS composite project card.

Suggest reviewing commit-by-commit.

• The first commit is the patch verbatim.
• Follow on commits only make small changes (formatting, comments, types.. no renaming or logic changes)

A follow on PR addresses compiler warnings in this file, in general (to keep this PR scoped to just this feature).

[kcgen]

Originally NRS and the other composite folks had included conf settings to dial in composite mode, but there were concerns that this would impact the patches likelihood of being merged - so they fell back to hotkey controls.
I enjoy tinkering with them, but from a preservation stans-point, I can see the value the conf settings provide. A project like eXo could offer composite in the startup selection list, and the game would come up with all settings adjusted to most faithfully reproduce it.
With hotkeys, eXo will have to say "remember to press F12, followed by Ctrl+F11 seventeen times until the colors are blue, orange, and dark green.(or something like that... There are hundreds of hue step).
I unfortunately don't have a good suggestions for the conf settings though, if we wanted to add them.

[dreamer]

The commit message in first commit should include line:

Imported-from: https://www.vogons.org/viewtopic.php?p=546614#p546614

(not Ref: line).

Left few tiny comments - overall the code looks good and you cleaned it up nicely :) I haven't tested it yet, but we need to make sure there's no accidental regression when turning on emulator in PCjr or Tandy modes.

[dreamer]

Originally NRS and the other composite folks had included conf settings to dial in composite mode, but there were concerns that this would impact the patches likelihood of being merged - so they fell back to hotkey controls.
I enjoy tinkering with them, but from a preservation stans-point, I can see the value the conf settings provide. A project like eXo could offer composite in the startup selection list, and the game would come up with all settings adjusted to most faithfully reproduce it.
With hotkeys, eXo will have to say "remember to press F12, followed by Ctrl+F11 seventeen times until the colors are blue, orange, and dark green.(or something like that... There are hundreds of hue step).
I unfortunately don't have a good suggestions for the conf settings though, if we wanted to add them.

Yes, we should add .conf controls for CGA modes, but we need to do it carefully, and make sure they can be switched via config command. Pedantically speaking they would belong to machine section, but from usability standpoint perhaps render section would work better (as we have monochrome_palette option in there already). Not in scope for this PR though. Before finishing implementation of new .conf we should talk to eXo and treat him as a client for this feature.

[kcgen]

Yes, we should add .conf controls for CGA modes, but we need to do it carefully, and make sure they can be switched via config command. Pedantically speaking they would belong to machine section, but from usability standpoint perhaps render section would work better (as we have monochrome_palette option in there already). Not in scope for this PR though. Before finishing implementation of new .conf we should talk to eXo and treat him as a client for this feature.

Really like this approach - thanks @dreamer.

[kklobe]

It looks like a lot of variables in update_cga16_color can be const or constexpr, any benefit to doing that now?

e.g.:

	constexpr double tau = 6.28318531; // == 2*pi
	constexpr double ns = 567.0/440;  // degrees of hue shift per nanosecond

[kcgen]

It looks like a lot of variables in update_cga16_color can be const or constexpr, any benefit to doing that now?

e.g.:

	constexpr double tau = 6.28318531; // == 2*pi
	constexpr double ns = 567.0/440;  // degrees of hue shift per nanosecond

Thanks! Yes; I think they're perfect for the part-2 PR that passes over the entire file.

[kcgen]

Updates inbound.

[kcgen]

CGA composite continues without issues. Here are some machine = cga screenshot, which match the main branch.

[dreamer]

It looks like a lot of variables in update_cga16_color can be const or constexpr, any benefit to doing that now?

e.g.:

	constexpr double tau = 6.28318531; // == 2*pi
	constexpr double ns = 567.0/440;  // degrees of hue shift per nanosecond

Good catch - I think we can shift it to the next PR :) Whenever we can use costexpr or const - we should.

Whenever dealing with "standard" know math constants like Pi, it's preferable to use constants from cmath, so:

	constexpr double tau = 2 * M_PI;

[dreamer]

@kcgen Looks great - thanks! :)

[Wengier]

Glad to see this feature got added.

[kklobe]

Whenever dealing with "standard" know math constants like Pi, it's preferable to use constants from cmath, so:

	constexpr double tau = 2 * M_PI;

This is historically an issue for Visual Studio, speaking from past experience, so might be why the original author avoided it.

[dreamer]

Whenever dealing with "standard" know math constants like Pi, it's preferable to use constants from cmath, so:

	constexpr double tau = 2 * M_PI;

This is historically an issue for Visual Studio, speaking from past experience, so might be why the original author avoided it.

Not for us, we fixed it for VS already :)

It's not really a problem in VS but rather with projects using incorrect include order in header and cpp files - it just manifests in VS more often than anywhere else.