VOGONS

Common searches


Reply 660 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
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!

Reply 661 of 745, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Split the newest PCEM off topic from this thread www.vogons.org/viewtopic.php?f=9&t=45187

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 663 of 745, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yes, things got uglier...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 667 of 745, by VileR

User metadata
Rank Oldbie
Rank
Oldbie

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. 😉

web  /   blog   /   tube

Reply 668 of 745, by kazblox

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 669 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
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:
boxing-notch.png

simple chroma-only comb filter:
boxing-simplechroma.png

simple chroma+luma comb filter:
boxing-simple.png

adaptive chroma+luma comb filter:
boxing-adaptive.png

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.

Reply 670 of 745, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 671 of 745, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Comitted to Dosbox sources in revision 3804 according to thread title

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 672 of 745, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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:

ega.png
Filename
ega.png
File size
10.52 KiB
Views
215 views
File comment
EGA/Tandy/MCGA/VGA
File license
Fair use/fair dealing exception
comp_late.png
Filename
comp_late.png
File size
15.35 KiB
Views
215 views
File comment
Late-model CGA composite
File license
Fair use/fair dealing exception
game_comp_db_comp.png
Filename
game_comp_db_comp.png
File size
15.35 KiB
Views
215 views
File comment
Early-model CGA composite
File license
Fair use/fair dealing exception
game_rgb_db_rgb.png
Filename
game_rgb_db_rgb.png
File size
7.54 KiB
Views
215 views
File comment
CGA RGB
File license
Fair use/fair dealing exception
game_rgb_db_comp.png
Filename
game_rgb_db_comp.png
File size
14.32 KiB
Views
215 views
File comment
Game in CGA RGB w/DOSBox in CGA composite
File license
Fair use/fair dealing exception
game_comp_db_rgb.png
Filename
game_comp_db_rgb.png
File size
8.73 KiB
Views
215 views
File comment
Game in CGA composite w/DOSBox in CGA RGB
File license
Fair use/fair dealing exception

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

Reply 673 of 745, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 676 of 745, by VileR

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments

web  /   blog   /   tube

Reply 677 of 745, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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

comp_reengine.png
Filename
comp_reengine.png
File size
95.13 KiB
Views
154 views
File license
Fair use/fair dealing exception

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!

Reply 678 of 745, by VileR

User metadata
Rank Oldbie
Rank
Oldbie

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.

web  /   blog   /   tube

Reply 679 of 745, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
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.