VileRancour wrote:

robertmo wrote:

You may be interested in checking
Championship Golf: The Great Courses of the World - Volume I: Pebble Beach
It also has unclear letters although they don't look detached.

This is a curious one... odd choice of palette - not exactly easy on the eyes. Maybe the display they used for testing was weirdly calibrated, because even in Servo's shots on MG, "medium blue" and "medium green" are hardly blue or green respectively. Looks like their hues are 70 or so degrees off, but only for certain colors.

Championship Golf looks to be made by the same company that made MS Decathlon. It may be possible both games were designed to use old cga type. As new one looks to be washed out colors. Servos screenshots of both games seem to show that he has new version of cga card. I wonder if any games were designed to use the new cga card. If not his screenshots of other games are of not much use i guess (I mean games/modes that look differently on old/new cards)

Attached are pictures of that strange golf game made with my algorithm, emulating the old type CGA. I turned down the brightness by 67% and turned the virtual hue knob to minus 30 degrees to make the calibration screen look like its descriptions.

Here's a patch that fixes the score line for Bruce Lee. It's still a line higher with this patch than it is on my XT, but I suspect that some real BIOSes may do the same thing as DOSBox here. For one thing, the score line is now in the same place in RGB and composite modes (which it isn't on my XT).

That's kind of a dirty trick the Bruce Lee game is playing to make BIOS draw mode 4 text in mode 6 by changing 0x449 to 4 while its writing the status line. Stuff like that could cause any number of problems for DOSBox's emulated video BIOS...

The text is lower with real BIOSes because they use 0x44A (characters per row) to calculate the output start address, and 0x44A is still 80 from mode 6 instead of the normal 40 for mode 4. Given DOSBox's x/y approach, I don't see a less hackish fix without doing more work on the code:

1     x=8*col;
2     y=cheight*row;
3+    if (real_readb(BIOSMEM_SEG,BIOSMEM_CURRENT_MODE)==0x4 && real_readw(BIOSMEM_SEG,BIOSMEM_NB_COLS)==80) y*=2;

yeah expected something like that was happening.
Ideally we would have a bios to curmode mapping function although that one will be one huge "if maze".

Could there be a detection method introduced in dosbox that would switch to composite if it detects vertical lines pattern?

BTW why bruce lee allows composite in both modes? I even think the other one looks better!

robertmo wrote:

Could there be a detection method introduced in dosbox that would switch to composite if it detects vertical lines pattern?

Probably too much fuzzy logic for DOSBox, but it'd be interesting to see a heuristic attempted for that.

robertmo wrote:

BTW why bruce lee allows composite in both modes? I even think the other one looks better!

It doesn't "allow" it so much as it can't stop it. Does the KQ1 booter disallow using its RGB mode with a composite display? Composite (color burst) is inherently enabled by mode 4.

i mean that it is designed specially for composite mode. For rgb it would have solid colors and checkerboards (different checkerboards). But never everything with vertical lines that doesn't look nice on rgb. They also produce nice colors in composite, actually even better than mode 6 in my opinion.

robertmo wrote:

i mean that it is designed specially for composite mode. For rgb it would have solid colors and checkerboards (different checkerboards). But never everything with vertical lines that doesn't look nice on rgb. They also produce nice colors in composite, actually even better than mode 6 in my opinion.

I don't know for sure, but I have a guess that the vertical lines in the RGB mode of Bruce Lee are nothing to do with composite encoding. I think the same data is used for the backgrounds for both modes, with a different mapping mapping between colours and screen memory nybbles. If you look carefully at the Bruce Lee backgrounds, you can see that they are actually 16-colour images scaled by a factor of 2 in both horizontal and vertical directions.

Now, they could quite easily have used checkerboard dithering instead of vertical lines for RGBI mode. Maybe they decided to leave it that way so that it looked better on composite monitors (despite having a separate composite mode) or maybe they just never got around to writing that little refinement to the background drawing routine.

reenigne wrote:

maybe they just never got around to writing that little refinement to the background drawing routine.

That's what I suspect, too. Keep in mind that in the case of Bruce Lee, you are dealing with what was originally an Atari 8-bit game. Ports were not necessarily done with a lot of thought. For example, the PC versions of Donkey Kong and Boulder Dash II both show vertical banding, yet look all wrong with a composite color monitor at any conceivable setting because no one bothered to do the graphics conversion properly. I suspect some automatic Apple II/C64 to CGA conversion tool existing producing a result to sort-of look alright in RGB mode with the cyan-pink palette, that didn't do checkerboard dithering.

Any heuristic for automatic detection of composite color would improperly misidentify these games as "yes" cases.

oh yeah, i didn't figured out they just changed red into pink 😉
guess cause of some common reason: costs cutting, deadline, etc. 😉

Consider this screenshot of the Bruce Lee game hacked to use mode 4 instead of mode 6 for its composite video option:

The game is writing the same video data as it would write for mode 6, and you can see the background looks quite similar to the game's RGB video option; the big difference is the sprites are solid for RGB. So, the developer simply chose not to provide alternate background graphic data for the RGB video option. Well, I haven't seen the original booter, only the DOS conversion, so can't be 100% sure of that.

oh, i guess character colors was that little thing that made me think of it as a different thing. Anyway that means it is not some little hack by some cracker/enchancer but a "specially designed" for rgb by game programmers.

You can see the same thing in later games that supported Tandy/EGA (like Turbo Champions or Shogun)... all graphics are stored as 16 color data, and the CGA mode just shows them as 16 pixel patterns. This shows as vertical lines on RGB monitors, but on composite displays the colors don't make sense at all... Shogun's CGA mode even uses the cyan-red-white palette (burst off), so a composite picture would lack any color.

Here's my "160 colour" patch so far. I realized that it actually only uses at most 64 distinct colours in 2bpp modes, so with a bit more work it might be possible to use a (1,4,7,8,7,4,1) kernel instead of the (1,1,1,1) one - this would smooth out the edges of some of the colour transitions a bit.

In 1bpp mode, it turns out we actually only need 16 distinct colours. Surprisingly, we can get more accurate results with fewer colours than the existing algorithm!

I added new/old CGA card selection to the config file, but I haven't tried out the new CGA card yet.

I've incorporated all the logic delays that I can sensibly model. The delays for 2bpp aren't quite as sophisticated as those for 1bpp, but they're as accurate as I can manage within the confines of a paletted algorithm.

I initially included NewRisingSun's suggestion to convert from NTSC to 709 primaries, but this produces poor results for me (oversaturated red pixels where there shouldn't be) so I've left it "#if 0"ed out for now. My best guess it that some of the colours are too saturated due to the high chroma amplitude and are therefore outside of the domain where the transformation works properly. The saturation generated by this code does seem to be higher than that from my TV so maybe the TV is reducing the saturation due to the high color burst amplitude. I'll investigate that some more.

The colors generally look good; but the colored edges, such as on the castle bricks or door handles, take some getting used to. I tend to prefer the look of edges in DOSBox's current composite rendering in KQ1, but that's strictly subjective and not referring to emulation accuracy.

that yellow grass is cause of that saturation?

ripsaw8080 wrote:

The colors generally look good; but the colored edges, such as on the castle bricks or door handles, take some getting used to.

Maybe this is cause of too high saturation too?

Dosbox doesn't support mode 6 on pcjr/tandy
But is supports mode 4 on pcjr? Notice red blue artifacts on white letters.

VileRancour wrote:

You can see the same thing in later games that supported Tandy/EGA (like Turbo Champions or Shogun)... all graphics are stored as 16 color data, and the CGA mode just shows them as 16 pixel patterns. This shows as vertical lines on RGB monitors, but on composite displays the colors don't make sense at all... Shogun's CGA mode even uses the cyan-red-white palette (burst off), so a composite picture would lack any color.

Actually shogun uses slightly different modes 😉

Shouldn't ega/vga be pink not red? Alghough it is autodetection so maybe it detects ega/vga and chooses different palette for it.