reenigne wrote:

other than "that's what whoever designed the box happened to have in the office"

Yes, I must admit that Sierra has been known to completely screw up their box screenshots at times. Take a look at the last (gray) Ultima II box: Macintosh version presented with high resolution screen graphics without color. Except the shot is obviously with color, it's from the Apple II version, and the hues are all inverted so that water is green, trees are brown, and mountains are blue. Snazzy!

Split the newest PCEM off topic from this thread Topic 45187

Please keep the personal attacks to yourself and keep this great thread clean.

viewtopic.php?f=9&t=45187

=> Information: You are not authorised to read this forum.

Yes, things got uglier...

Ack! I was afraid of that 🙁

I found the non-ugly parts interesting.

This is why I never post offending content, even when it's ok to do so...

Anyways, comb filtering would be a great idea.

@VileRancour: Your New CGA saturation fix seems way off with the rendering of the New CGA-modified Flower Girl.

kazblox: I don't think I have enough data to guess what's going on there - what does it look like without the saturation hack? (also, which version of the hack did you apply - I tried two different ones, both on the previous page.) Do standard mode 4/6 images play nicer with your decoder? Is it based on reenigne's algorithm and data? (it should be), etc.

In any case, keep in mind that 80-column text mode (which that image is based on) is basically the 'special needs kid' of composite CGA, due to the hardware bug that truncates the color burst - on a real CGA you have to tweak things to compensate, but then you only get farther away from standard NTSC specs, and what the display makes of the signal is a bit of a crap shoot. Hence the 8088 MPH calibration screen that makes you adjust three independent parameters to match up the image with our 'reference' palette... which was itself somewhat arbitrary, anyway. All in all, I'd be shocked if the emulated image *wasn't* way off unless you manually tuned the brightness, contrast and hue specifically for this mode. 😉

Oh right, I forgot you could fine tune composite settings with shortcut keys in the DOSBox decoder... I nulled that ability out in my test image rendering program with the decoder implemented and I completely forgot about that until now.

DOH! Call me stupid on this one.

reenigne wrote:

Though not on the cyan/magenta checkerboard - I suspect that might also have been a solid colour on the original developers' hardware (probably a blue).

No comb filter will turn this into a solid blue. Trixter's capture card also seems to be chroma-only, in other words, luma is recovered by subtracting the notch-filtered chroma rather than the comb-filtered chroma from the composite signal. That's quite common, as non-adaptive chroma-only comb filter artifacts manifest themselves in desaturation of edges, while non-adaptive luma+chroma comb filter artifacts themselves as unsightly hanging dots, as seen in the third picture below. Here's the Boxing's title screen with all four filter types:

notch filter only:

simple chroma-only comb filter:

simple chroma+luma comb filter:

adaptive chroma+luma comb filter:

Screenshots depict the emulation of a new-type CGA with a hue offset of +15 (to make the sky less greenish). Obviously, this adaptive comb filter of mine could still be improved, as the two rows below "by Dave and Barry Murry" should be filtered as well. Right now, it errs a little on the conservative side, because filtering too much would look extremly unsightly.

I tried skimming this thread and got lost, seems there are so many different utilities and patches, tried running a couple on alley cat but they didn't work(set to cga, alt-p, etc,) is there a summation and what's the latest and greatest? Would think this would go into main DOSBox to improve its existing composite modes, is this stuff going in or rejected for whatever reason?

Comitted to Dosbox sources in revision 3804 according to thread title

I just bought Dragon Wars on GOG and noticed it has a 320x200 CGA composite mode.

Using an EmuCR revision 3971 build, there are options listed in the DOSBox startup screen for manually forcing CGA composite mode, changing hue, and setting early/late model, so I took some screenshots of all the game's modes with various DOSBox settings:

Edit: I think the blue dragon was a compromise, as adjusting the hue to green causes the adventurers to become pink/magenta.

Not going to bother trying to contribute screenshots to MobyGames any more, after getting this asinine response:

GOG does not feature DOS games. If you used original DOS game on DOSBox, then that would go under DOS screenshots, if you're playing GOG game, this should go under Windows or Mac or Linux screenshots, depending on which platform you played it.

What the f*** do they think GOG uses to get DOS games to play?

mind = blown

Yep, Moby's treatment of emulated re-releases is confusing at best, if not severely misleading. What's worse is that they already have just the tool for a system that doesn't suck - platform flags, like that "Browser (Facebook)" one. Something like "DOS (Emulated)" would actually make sense, instead of mixing things up with native Windows/Mac/Linux ports and then assuming that this ass-backwards approach should be self-evident to everyone.

HunterZ wrote:

Using an EmuCR revision 3971 build

EmuCR builds are pretty limited, plus the composite CGA emulation in current SVN is still an older revision, which has been much improved since. reenigne's latest update has better color accuracy and higher bit-depth rendering (no more palette-based blockiness), and is more configurable without adding extra mapper keys.

I've added it to my Windows build based on r3980 (for testing my Keen 4 composite mod), so if you want a more current build you can use this one... although it also includes the experimental PC speaker patch, which may cause sound regression in some games.

Cool, thanks! Here's a screenshot in late-model mode:

Adventurers' skin looks a bit more orange (as opposed to red), and the female adventurer's hair looks a bit more blonde.

Blending seems to work a lot differently from stock DOSBox SVN. Highlights appear that weren't there before, and old highlights are gone.

I also noticed that for some reason all kinds of DOSBox output scaling get disabled when enabling forced 320x200 composite mode, and aspect=true causes screen corruption. It seems to run at a fixed 2x scaling. This is very annoying on a 1080p screen!

The older version (in SVN) forced a lower saturation for late/'new' CGA, while the newer patch doesn't -- real late-style CGAs do produce more saturated output. Saturation is no longer hardcoded however (you may adjust it and several other parameters, as detailed in the startup message).

HunterZ wrote:

I also noticed that for some reason all kinds of DOSBox output scaling get disabled when enabling forced 320x200 composite mode, and aspect=true causes screen corruption. It seems to run at a fixed 2x scaling. This is very annoying on a 1080p screen!

That's probably because composite is always rendered at 640x200 internally, regardless of what the underlying video mode is. DOSBox treats that as a double-height mode, which the scalers won't work with (same goes for all other double-height/double-width modes as well).
My above build also includes this patch to remedy that, so at least "normal2x forced" and "normal3x forced" should work.

VileRancour wrote:

That's probably because composite is always rendered at 640x200 internally, regardless of what the underlying video mode is. DOSBox treats that as a double-height mode, which the scalers won't work with (same goes for all other double-height/double-width modes as well).

Is this different from what non-patched SVN does? Because scaling works fine there.

Note that the only scaling that I prefer to use is what you get with aspect=true plus output=opengl. I usually use scaler=none.