ripsaw8080 wrote:

I think the most user-friendly approach, and also the one more likely to be looked at favorably by the devs, is to use default settings that work fine for most games and provide an unobtrusive way to change settings for the few games that need it and for people that are inclined to do so.

So the proposal would be then to add just one single new config file option "monitor", defaulting to "rgb", also adjustable to "composite" (and maybe "amber" and "green" if one wants to incorporate that monochromatic patch). That kills several birds with one stone and is basically self-explanatory to all but the most novice users, especially since it corresponds to what the games themselves ask. Adding "amber" and "green" monitor variants would also further justify adding the "monitor" option to the config file, since those are applicable to VGA and EGA as well (since I've read that there were indeed monochromatic VGA and EGA monitors), as well as incorporating the current Hercules F11 function, so the objection that this option would apply only to some machine types and not to others would be defeated as well.

Hue, saturation and brightness, being real-time adjustable on a real monitor, go into a Z-drive program or become a key binding (Z-drive is better for [autoexec] adjustment). "pcjr" and "tandy" composite variants are automatically selected by the machine type as well; the only thing left to work out then is where goes the old versus new cga decision. Given that the svga variants are also different machine types, I would propose keeping "machine=cga" as the old CGA and "machine=cga_new" as the new CGA. Or, equivalently, make "machine=cga" an alias for "machine=cga_old".

Which is almost the same as HunterZ's proposal, if I understood it correctly. Would that be palatable, then?

The problem with that approach, as I see it, is "in for a penny, in for a pound". You'd logically have to make this new monitor= setting apply to hercules at a minimum (currently uses a keybind to change mono color), and then how would it apply to other machine types? EGA/VGA mono is a possibility, but it just becomes awkward with combinations like hercules+rgb.

Anyway, we'll have to wait for dev comment. My experience is that they are not inclined to accept new machine types, or a separation of machine type and video card/monitor, at least not for the time being. I'd be interested to hear their opinion on the Z: program approach instead of conf settings. The Z: program is basically the same thing (start with default, but allow changes), however it has the advantage of only being present for applicable machine types.

NewRisingSun wrote:

MobyGamer wrote:

It's nice that all systems are being considered, but they were never targeted in the real world.

I don't think that most developers were even aware that there are several CGA revisions with the difference being in the composite video encoder. So those two are essential, because games can be found that target either one of them. PCjr composite emulation is necessary if you want "Below the Root" with proper display and three-channel sound, and supporting the Tandy 1000's composite video is just a matter of changing two numbers. And besides, I think it's kind of fun! 😀

Are you sure Below the roots is not displayed in 16 colours mode on the real PCjr like IBM King's quest? Somehow the game is displayed in 4 colour mode like Boulder Dash with Dosbox.

@NRS: That works for me.

@ripsaw: I think you could easily handle invalid combinations by falling back to using the default monitor= setting for the chosen machine= setting, and spitting a warning message on the DOSBox status console.

As for selecting an emulated monitor type by running a fake DOS command: that feels a bit goofy to me, but it's definitely better than nothing. It does have the advantage of inherently allowing you to change the setting during a session as well, although you can do that with some config options too.

HunterZ wrote:

I think you could easily handle invalid combinations by falling back to using the default monitor= setting for the chosen machine= setting, and spitting a warning message on the DOSBox status console.

It opens up a can of worms, both in programming and in documentation. A log message doesn't make it less awkward or more comprehensible to users. (e.g. "But VGA with a mono monitor makes sense, I used to have that setup back in the day, why doesn't it work in DOSBox?").

HunterZ wrote:

As for selecting an emulated monitor type by running a fake DOS command: that feels a bit goofy to me

You appear to be mixing up concepts. The Z: program would be for changing CGA composite settings, it has nothing to do with the emulated monitor type concept. As for it being "goofy", do you have another suggestion that does not use the conf file?

The question with implausible machine/monitor combination arises with a fake monitor command just as much as it does arise with a monitor= config file setting.

So which combinations of monitors and machines would be problematic?
cga/tandy/pcjr: plausible with everything.
ega/vga: plausible with rgb and mono, composite would be plausible with some SVGA cards having TV out, but kind of pointless to implement (heh).
hercules: plausible with mono. RGB and Composite might have been possible with an adapter (but pointless with actual hardware).

All combinations are okay except two: 1) ega/vga and composite: display error message ("composite monitor not supported for %machinetype%, using RGB instead") , 2) hercules and rgb/composite: just display white?

The only awkwardness that I acknowledge is that the default monitor type would be different for hercules (mono) on the one hand and everything else (rgb) on the other hand.

NewRisingSun wrote:

The question with implausible machine/monitor combination arises with a fake monitor command just as much as it does arise with a monitor= config file setting.

Of course, but I don't think a monitor= setting will be accepted, whether it be a conf setting or a command.

NewRisingSun wrote:

The only awkwardness that I acknowledge is that the default monitor type would be different for hercules (mono) on the one hand and everything else (rgb) on the other hand.

My point about akwardness assumes that many of the possible combinations are going to remain unimplemented, and therefore disallowed. This refers to the programming part of the can of worms. Are you volunteering to implement a comprehensive monitor= setting in DOSBox?

After thinking about this problem with settings, I believe that some compromises may be necessary in order to get the nice feature of low-res composite output into the next official release of DOSBox.

The hard part of this suggestion: let go of the idea of supporting all games perfectly. I'm not sure if DOSBox currently uses new or old CGA composite colors, but whichever it is, stick with that. For the other possible settings, choose defaults that work with most games. If a game doesn't look as good as it could, then it doesn't -- chances are it will look better than it does currently. There will be development builds for the "power users" who want to tweak, and more capable official releases further down the road.

I've been using the F12 auto/on/off key for awhile, and I think it could be simplified to just on/off. Mode 6 would always be auto, mode 4 would be affected by the toggle.

So, no new settings at all, and an on/off toggle on F12.

As long as it is documented, the confusion concern is not really any more warranted than it is for any of DOSBox's other confusing features that already exist.

I think NRS' proposal is very reasonable. You'd probably want a "monitor=auto" so that just switching from, say, machine=cga to machine=hercules wouldn't require changing the monitor= setting from default to avoid an error message.

On a side note: I do recall my old Wyse 8MHz 286 having a switch on its EGA monitor that would force it to amber or green monochrome (depending on which way you moved it from the color setting in the center), but I never used it because that would be silly. Maybe it had a Hercules emulation mode that that would be useful for?

Edit: It's okay to not implement every combination, as long as it falls back to a reasonable behavior. It can also be made clear in the comments and readme that certain monitor= settings are meant for certain machine= settings.

The other option is to have monitor_egavga, monitor_cgapcjrtandy, monitor_hercules, etc., which is never going to happen (but is probably somewhat analogous to how the different sound card settings work).

ripsaw8080 wrote:

My point about akwardness assumes that many of the possible combinations are going to remain unimplemented, and therefore disallowed

Many, as in exactly one: vga/ega plus composite. (Let's not be silly by counting all the svga types separately...)

The only one that needs to be newly implemented is mono (amber/green) for all machines except Hercules, and that will be trivial; all that is necessary is to convert from RGB to grayscale somewhere in the color register routine, then tint with amber, green or white (i.e. not at all). That's four lines of code, plus maybe a few ifs more..

So it's a small, tiny can of worms. 😀

I'm looking forward to your patch, and seeing it accepted into SVN. 😀

If the monitor= proposal is carried, then I'll do the mono part as described. 😉

ripsaw8080 wrote:

After thinking about this problem with settings, I believe that some compromises may be necessary in order to get the nice feature of low-res composite output into the next official release of DOSBox.

The hard part of this suggestion: let go of the idea of supporting all games perfectly. I'm not sure if DOSBox currently uses new or old CGA composite colors, but whichever it is, stick with that.

DOSBox's current colors sometimes look like old CGA and sometimes new CGA, due to that 15-degree tint hack, which just happens to correspond to the difference between the two cards in mode 6 (more or less). It turned out that this hack isn't based on real hardware behavior after all, and it's triggered by a bit that serves another purpose in mode 4, so we would still need a proper way to control this setting. Completely taking away the choice would, in a sense, be a regression from what DOSBox currently does.

I'd really like to avoid discarding any of the adjustable settings from the last patch; they can still be made unobtrusive. I like your previous idea of an internal Z: program - if conf file settings are out of the question, that sounds like a good substitute, though the hue adjustment and the monitor toggle (auto/composite/rgb) should probably remain in the keymapper on top of that. The program could always be called from [autoexec] or from a batch file, so the flexibility is still there. Would be best if it offered help on the various settings (like the conf file comments do), since nobody ever bothers to RTFM anymore.

I've been using the F12 auto/on/off key for awhile, and I think it could be simplified to just on/off. Mode 6 would always be auto, mode 4 would be affected by the toggle.

That probably wouldn't be intuitive to most users, and I don't see how having three states vs. just two should be a deal-breaker. At first I didn't see the need for having all three, but you convinced me a few hundred posts ago, if you remember. 😀

Also, are we aiming to add pcjr/tandy composite support in the "official" patch? I'd like to have that, but on the other hand, the emulation is incomplete for those machines (we cannot support the 16-color modes, unless we ditch the palette and rewrite the whole thing). Would like to hear what the devs think about this too.

VileRancour wrote:

DOSBox's current colors sometimes look like old CGA and sometimes new CGA, due to that 15-degree tint hack, which just happens to correspond to the difference between the two cards in mode 6 (more or less). It turned out that this hack isn't based on real hardware behavior after all, and it's triggered by a bit that serves another purpose in mode 4, so we would still need a proper way to control this setting. Completely taking away the choice would, in a sense, be a regression from what DOSBox currently does.

Following the idea behind my suggestion for a settings-less approach, the hack would still be used (in mode 6 only); thus no "regression", and no one will be surprised by significantly different colors in KQ1 (or any other game that happens to set that bit). I know you and others won't much like that, but it is part of the compromise to avoid additional settings.

VileRancour wrote:

At first I didn't see the need for having all three, but you convinced me a few hundred posts ago, if you remember.

I remember. At the time I was only looking at "covering all the bases" in terms of possibilities. I mention the on/off toggle as an idea that could be adopted for the sake of simplicity.

I don't think the "keep it simple" approach is necessarily the best approach. As with the Z: program for composite settings, I'm just throwing ideas against the wall to increase the chance of something sticking. 😉

Following the idea behind my suggestion for a settings-less approach, the hack would still be used (in mode 6 only); thus no "regression", and no one will be surprised by significantly different colors in KQ1 (or any other game that happens to set that bit). I know you and others won't much like that, but it is part of the compromise to avoid additional settings.

Yeah, I see what you're saying, but that would mean we'd still be emulating incorrect behavior (besides preventing games from looking right); it just bears pointing out, as something that might just outweigh the simplicity bonus of avoiding any new settings.

I remember. At the time I was only looking at "covering all the bases" in terms of possibilities. I mention the on/off toggle as an idea that could be adopted for the sake of simplicity.

I don't think the "keep it simple" approach is necessarily the best approach. As with the Z: program for composite settings, I'm just throwing ideas against the wall to increase the chance of something sticking. 😉

That's what I'm going for too - admittedly, I just really want the more inclusive idea to stick, so I'm trying my best to see if it does before going for a last resort approach. 😀

About the "monitor=" config file proposal: I actually really like the idea, and it would certainly be the sensible (and complete) way to do things.

That said, I agree with ripsaw that anything like that is very unlikely to be considered for an official release any time soon. So while I'd love to see this happen, it should be the focus of a different patch, which could at least benefit unofficial builds.

Among the things that would need to be changed: if "composite" gets its own separate monitor type, then it should offer complete composite emulation - 16-color modes included (CGA text mode + the extended PCjr/Tandy graphics modes). Anything less wouldn't make much sense in the context of such a setup, and supporting that stuff would require some pretty fundamental changes.

For mono/TTL monitors, that patch I wrote wouldn't be a very good basis - it's pretty much limited to CGA, and based on somewhat arbitrary hard-coded values. Monochrome VGA monitors are entirely different beasts, and I know even less about mono EGA.

And just for the sake of being ridiculously thorough, we could look into those obscure "EGA-64" clones that offered the full EGA palette in low-res on specialized displays. 😉

VileRancour wrote:

About the "monitor=" config file proposal: I actually really like the idea, and it would certainly be the sensible (and complete) way to do things.

Everything else would seem hackish and therefore less intuitive for the user. Remember my argument that it would be congruent to what many games themselves ask.

VileRancour wrote:

Among the things that would need to be changed: if "composite" gets its own separate monitor type, then it should offer complete composite emulation - 16-color modes included (CGA text mode + the extended PCjr/Tandy graphics modes). Anything less wouldn't make much sense in the context of such a setup, and supporting that stuff would require some pretty fundamental changes.

I have most of this already written; it would only have to be slightly optimized and adapted for inclusion in DosBox. But I'm not going to bother if I'm told in advance that it would just end up being the hundredth unofficial build.

NewRisingSun wrote:

being the hundredth unofficial build.

Actually there is just one unofficial build - ykhwong one that incorporates all patches ever released for dosbox so none of the work done by their developers is wasted. I think this is a good way of handling it as there are many nice patches for dosbox that wouldn't appear in dosbox other way. They were not fully tested and may break many games but at least they work for the ones that use those patches. Allowing all those patches into official dosbox (apart from increasing dosbox complication for users) would require a lot of extra testing and add extra complication into dosbox's source slowing down any further development. And we have to be aware dosbox (like many other emulators in the past) is actually no longer being developed as all main developers got involved into their real work and have no time for dosbox (same happened with many other emulators in the past), so it is even possible no new dosbox version will ever be released unless new developers appear.

A monitor= line is discussable. That is actually planned for after 0.75, but if a decent patch is presented, then I will probably add it before the next version.
I am a bit curious on which things you want to support in the monitor= line as in my plans it should be very flexible.

Although it would be limited on what was possible hardware wise though and not everything needs to be handled right in the initial version of it. Totally useless combinations and/or hacks should be skipped as well, but for a start having composite and rgb output for various machines might be nice.

NewRisingSun wrote:

The question with implausible machine/monitor combination arises with a fake monitor command just as much as it does arise with […]
Show full quote

The question with implausible machine/monitor combination arises with a fake monitor command just as much as it does arise with a monitor= config file setting.

So which combinations of monitors and machines would be problematic?
cga/tandy/pcjr: plausible with everything.
ega/vga: plausible with rgb and mono, composite would be plausible with some SVGA cards having TV out, but kind of pointless to implement (heh).
hercules: plausible with mono. RGB and Composite might have been possible with an adapter (but pointless with actual hardware).

All combinations are okay except two: 1) ega/vga and composite: display error message ("composite monitor not supported for %machinetype%, using RGB instead") , 2) hercules and rgb/composite: just display white?

The only awkwardness that I acknowledge is that the default monitor type would be different for hercules (mono) on the one hand and everything else (rgb) on the other hand.

Not necessarily so awkward, as Hercules + RGB could allow for Hercules InColor emulation. Some games support it and its 720x348x16 mode. Richard Wilton's Book "Programmer's Guide to PC Video Systems" should have most if not all the information needed to emulate the InColor Card.

Great Hierophant wrote:

Not necessarily so awkward, as Hercules + RGB could allow for Hercules InColor emulation. Some games support it and its 720x348x16 mode. Richard Wilton's Book "Programmer's Guide to PC Video Systems" should have most if not all the information needed to emulate the InColor Card.

Video Modes Supported : Hercules InColor
http://www.mobygames.com/attribute/sheet/attributeId,579/