VileRancour wrote:

OmegaPC777 wrote:

Hey, can I have that Tandy/PCjr composite patch, please?

As the replies above yours indicate- an accurate Tandy/PCjr patch calibrated from real machines is not yet ready. The best one currently available is the PCjr patch by NRS which can be found on page 35. But while we're at it, since you've been submitting composite CGA shots on MobyGames, I'd urge you to use the latest accurate patch instead of what's in DOSBox SVN. 😉

I just started using that patch you suggested me.

Here is reenigne's improved composite CGA patch updated for current DOSBox SVN (as of r4115).
Refreshers: F12 toggles composite on/off/auto; Ctrl+Alt+F11 cycles through settings to change (CGA model, hue, saturation, contrast, brightness, sharpness); F11/Alt+F11 modify the current setting. You might need to generate a new keymapper file while in machine=cga.

Since r4095, DOSBox's opengl output can handle >8 bpp inputs, so the emulated composite screen can be aspect-corrected properly now. (The above build also has the enhanced normal scalers, so you can set e.g. "scaler=normal2x forced" and it'll actually have an effect in this mode.)

The color-depth issue was the only disadvantage of this patch vs. DOSBox's existing one. Since that is now solved, I see no real reason why this shouldn't be committed to trunk. 😉

I don't see Tandy/PCjr composite support though. I would say that should be added before "committing to trunk".

NewRisingSun wrote:

I don't see Tandy/PCjr composite support though. I would say that should be added before "committing to trunk".

That'd be nice. We'd still need the chroma_multiplexer arrays for those machines, so Trixter/reenigne are welcome to indicate here whether they'd appreciate more prodding in the matter. 😁

VileRancour wrote:

NewRisingSun wrote:

I don't see Tandy/PCjr composite support though. I would say that should be added before "committing to trunk".

That'd be nice. We'd still need the chroma_multiplexer arrays for those machines, so Trixter/reenigne are welcome to indicate here whether they'd appreciate more prodding in the matter. 😁

I consider myself appropriately prodded. Life is and has been crazy and hectic this past month, but I'll stick another reminder in the calendar for July.

This is the one-year prodding anniversary. 😲

VileR wrote on 2018-06-13, 00:38:

Here is reenigne's improved composite CGA patch updated for current DOSBox SVN (as of r4115).
Refreshers: F12 toggles composite on/off/auto; Ctrl+Alt+F11 cycles through settings to change (CGA model, hue, saturation, contrast, brightness, sharpness); F11/Alt+F11 modify the current setting. You might need to generate a new keymapper file while in machine=cga.

I'm using your trunk now; since it allows me to set sharpness; is there anyway to set all the CGA variables in the config file; e.g.

"Composite ON"
"Early Model CGA"
"Hue 30"
"Sharpness 80"

to save time in entering them all by hand manually?

EDIT: This is what I've got in Wilderness: A survival Adventure.

The composite photo is with the hue adjusted and sharpness as well.

MKSheppard wrote on 2020-09-09, 00:17:

is there anyway to set all the CGA variables in the config file; e.g. […]
Show full quote

is there anyway to set all the CGA variables in the config file; e.g.

"Composite ON"
"Early Model CGA"
"Hue 30"
"Sharpness 80"

to save time in entering them all by hand manually?

The DOSBox devs expressed that they didn't want extra config options, so we didn't add those in.
The enhanced patch still hasn't been merged anyway; if the dev team would indicate that they don't intend to commit it, then we might as well go wild. 😀

You know, I loaded up regular Wilderness in Standard 4 color CGA mode, and then altered the screenshot in Paint Shop Pro to alter the hue by -60 and I got this:

And it fits too well; it makes me wonder if the CGA palettes in-game were chosen deliberately (remember, this was 1985/1986) so that end-users would adjust the hue on their monitors manually to get this effect.

It's been so long (and I was only 6 or 7 during that era of computing), but I do vaguely remember older monitors having hue adjustment (possibly a side effect of many of them being similar to CRT TVs?)

That may be overestimating the effort that went into the artistic decision-making, if there was any... that game was originally an Apple II job, at least according to MobyGames. It was pretty common for folks to just use automated converters when porting graphics to another machine; or in this case just port the vector drawing routines, plug in some numbers for source->target color translation, and call it a day.

The Apple version only uses 4 colors as well, and also has a purple sky. So funnily enough the vanilla RGB CGA version is more faithful to the original.

Anyone know if the new M.U.L.E. release on GOG is lacking composite CGA emulation because of a stock DOSBox limitation, or just lazy config settings on GOG's part?

It appears to be another case of a 320x200x4color mode game that is clearly designed with composite in mind, which I seem to remember being the subject of some friction in this thread.

HunterZ wrote on 2021-03-01, 17:22:

Anyone know if the new M.U.L.E. release on GOG is lacking composite CGA emulation because of a stock DOSBox limitation, or just lazy config settings on GOG's part?

It appears to be another case of a 320x200x4color mode game that is clearly designed with composite in mind, which I seem to remember being the subject of some friction in this thread.

Update: @xotmatrix on Twitter investigated this and found that the DOSBox 0.74-2 build bundled by GOG is simply incapable of applying composite CGA emulation to MULE. This is what I expected based on my memory that official DOSBox decided not to implement any level of composite CGA support for 320x200 modes for some bizarre reason, despite the fact that I've personally come across probably half a dozen games that would take advantage of it.
https://twitter.com/xotmatrix/status/1370854058161008643

Not that the situation with SVN builds would help GOG any better, as I think you have to hit F12 to force-enable it on DOSBox ECE for example. Probably the correct answer is to implement a machine=cgacomp setting.

HunterZ wrote on 2021-03-01, 17:22:

This is what I expected based on my memory that official DOSBox decided not to implement any level of composite CGA support for 320x200 modes for some bizarre reason, despite the fact that I've personally come across probably half a dozen games that would take advantage of it.

Yes, AFAIK DosBox 0.74-2 inherits 0.74's older composite CGA code, so it doesn't have the extra functionality that's already been committed - let alone the latest, even-more-accurate code (available at the top of this page). No idea what ECE is using.

As far as I remember, the reason was that 0.74 used an auto-detect approach, which can't work for 320x200 modes since they don't require a telltale register write, unlike 640x200. Also, supporting them required a different approach and some extra research, which was yet to be done at that point in the ancient past.

Unfortunately, it's probably futile to expect these companies to configure their DOS-era re-releases properly, or even to use an appropriate build of the emulator. 🤬