VOGONS

Common searches


Reply 140 of 758, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
kiyote wrote:

Still playing with this stuff..

Video of it in action, a longer clip, now on youtube.

http://www.youtube.com/watch?v=uBji-SR_WtA

Your video got blocked, dude. 🤣

Reply 141 of 758, by VileR

User metadata
Rank l33t
Rank
l33t

"video removed by the user" != blocked 🤣

nice to see some interest in this area though. Anything else happening on the composite CGA front? for instance, any plans from anyone to patch-in true / full composite emulation - that is, 320x200x4 modes too?

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 142 of 758, by kiyote

User metadata
Rank Newbie
Rank
Newbie

Since Youtube is being @nal, I'm going to convert the video to a flash video, if this new converter works, and host it myself.

I'm going to try to upgrade my video transcoder so that is uses dithered 16 colors instead of just the 16 colors.

Should have really great results after I add in the alternating color to make the number of available colors better.

::::

I've got FreeBasic going in DOS now, requires the Win32 extender to run, but DOES run in DosBox.

If I can't get a QBasic compiled EXE game to work well enough for some 16 color CGA games, I'm going to use FreeBasic to do the job instead.

Just think. A 32 bit program doing 1-bit graphics which then becomes 8-bit graphics.

~Kiyote!

Yes I did a bunch of screaming like a n00b in the thread before. I'm not doing that any more.

Reply 143 of 758, by fronzel

User metadata
Rank Member
Rank
Member

Thanks for posting the programs Kiyote. Although i don't use them on DOSBOX both actually run fine on my 1992 HP 100LX which has monochrome (Yeah Doh! No composite here) CGA.

The GRASP (GL) files work fine and liquid on this old 8 MHz 8086 clone. But your CGA videos are way too slow on this machine. Any ideas about how to speed it up?

Also i would be interested in how you actually made the GL animations.

Reply 144 of 758, by BdR

User metadata
Rank Newbie
Rank
Newbie

Wow, this thread is still running.. I created the CGA composite .GL files, so here's how I made them:

1) First I started looking for a video clip that could be looped
2) Then I extracted the frames from the AVI file, I forget which program I used to do that (maybe avi2bmp or VLC)
3) Then I converted the frames to the a 160x200x16color BMP file
4) I loaded each 160x200x16color BMP file into my GW-BASIC dither program and saved the dithered image (in DosBox -> CTRL-F5).
5) Then I converted the dithered images to .PIC format using the old PC-Paint program
6) Finally I put all the .PIC images into a .GL file using very old GRASP 1.10c program

Like I said, it was quite a lot of work really. You can find the GRASP program with google, I think I found it at vetusware (you can do a free registration to logon and download the files). If you want to make your own GL movie, you'll have to use some sort of GRASP script, I just copied something from an existing GL file and edited it a bit.

Reply 145 of 758, by kiyote

User metadata
Rank Newbie
Rank
Newbie

@fronzel

"But your CGA videos are way too slow on this machine. Any ideas about how to speed it up? "

I have someone re-writing my viewer program in Turbo Pascal, should be TONS faster on your old machine with the new version, when he finishes converting the QBasic source to TP.

I'll host it, and post it here, when he's done writing the conversion.

~Paul

Reply 147 of 758, by VileR

User metadata
Rank l33t
Rank
l33t

Here's something that could prove useful. The attached converter takes any CGA image and simulates it on a color composite display.

I recently stumbled on this old post by reenigne - his code completely simulates NTSC, and covers every possible CGA mode / color combination (DOSBox's current implementation only covers mode 6 + white foreground). With his kind assistance, I was able to modify it into a straight-up image converter.

Note that the author isn't 100% satisfied with his old code - he's been testing it against a real XT/CGA/TV setup, and wants to refine it further. But this tool could help us:

- Get a good idea of what composite output should look like (for mode 4 games, too)
- Test the results against good NTSC captures (where available)
- Make a DOSBox patch (could be problematic for other reasons though)

Program notes:

- Input ("in.raw") should be 640x200, raw indexed CGA (a palette value of 0..15 for each byte).
If your image is 320x200 or 640x400, just scale it, don't filter. I added a bit of code to read raw full RGB instead (3 channels interleaved); it works but it's clunky, so I commented it out.

- Output ("out.raw") is 1280x200, raw full RGB (3 channels interleaved). To fix up the aspect ratio in my samples, I scaled this to 1280x400 without filtering, then to 640x400 using bilinear filtering.

- Play with the #defines to simulate a mono display, turn off the color-burst signal, or set tint / saturation. Command-line parameters would be much nicer of course, but they'd need parsing and sanity-checking... maybe later.

Sample results - click for full size:

nLHJk.jpg MS Flight Simulator (as originally shown on reenigne.org)

4jjAz.jpg MS Decathlon (w/composite monitor chosen)

aW9YX.jpg Ancient Art of War (seems geared to look nice on both kinds of monitors)

AW6Wl.jpg Archon

Ufz7j.jpg Below the Root (clearly meant for composite)

VpGLE.jpg Dig Dug (clearly not meant for composite)

wE67G.jpg Fooblitzky, which started this thread

Epd9n.jpg Jungle Hunt

WHrMg.jpg Shamus (nice but subtle effect; note the status bar and the enemies)

1yKg6.jpg Ultima II

5ExOr.jpg 80c text mode color test

Attachments

  • Filename
    cga2ntsc.zip
    File size
    10.08 KiB
    Downloads
    268 downloads
    File comment
    C++ source + win32 .EXE + sample input file (Flight Simulator)
    File license
    Fair use/fair dealing exception

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 148 of 758, by TeaRex

User metadata
Rank Member
Rank
Member

Thanks for the effort! I noticed some of the composite images you just posted (e.g. the one from Ancient Art of War) have areas with horizontal stripes. Might it be a good idea to also implement something like the PAL color delay line? I think some NTSC monitors had one too, right? And if they didn't, the low dot pitch sort of provided one...

What I mean is, for every pixel, take its own brightness value, but average out hue and saturation between it and the one directly above. This would have to be applied after everything else. For pixels in the top row, you'd use black (saturation = 0).

You'd take the saturation and hue values as a vector in polar coordinates. Unless my math fails me (a situation that's not unheard of) 😀 do it like this: convert to rectangular for both affected pixels, add the vectors, convert back to polar, finally halve the magnitude (saturation) of the result. This should come pretty close to what a real delay line does.

This way e.g. areas with horizontal stripes of equal brightness "dissolve" into several additional colors. I know that effect was used in a couple of Apple II games, such as "The Mask of the Sun", so it wouldn't surprise me if some CGA games used it too.

tearex

Reply 149 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie

It's curious - the images produced seem much "blockier" than I was expecting, as if they were rendered at 320x200. I think the code is correct though - it's just than I'm using a much less sharp FIR filter than NewRisingSun did (mine is based on the one from the xanalogtv program which is part of XScreenSaver). I might tweak that some more too now that I have real hardware to compare it too - my monitor seems to have more sharpness than this algorithm.

Might it be a good idea to also implement something like the PAL color delay line? I think some NTSC monitors had one too, right? And if they didn't, the low dot pitch sort of provided one...

I don't think NTSC monitors of the period would generally have had delay lines - it was a fairly expensive component and not as important for NTSC as it is with PAL, so I think they only tended to be present on high end TVs. I might be wrong, though.

I'm using a 90s era TV as a composite monitor and I haven't noticed any comb filtering (horizontal hue/saturation boundaries are sharp, not smeared out over 2 scanlines as I'd expect them to be if comb filtering was in use), but maybe that's just because I haven't been looking for it. Or maybe the TV is new enough that it's doing some clever digital stuff to turn on the comb filter only under certain conditions. The non-interlaced signal might also cause it to decide not to use the comb filter, but that's pure speculation on my part. I may have to do some experiments.

As for implementing a comb filter in software - I think you're right in principle, except that you wouldn't want to use polar coordinates (all the processing is done in cartesian colour spaces and converting to/from polar would be prohibitively expensive) - you'd just do the averaging on the I and Q components directly.

That's interesting that there are Apple II games that take advantage of this, though - can you point me to screenshots of what "The Mask of the Sun" (or any other game designed with this in mind) looks like with and without comb filtering? I'm wondering if it's not so much comb filtering that they're relying on as just a general smearing due to low vertical resolution.

Reply 150 of 758, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

Dig Dug (clearly not meant for composite)

Originally I thought you said (clearly meant for composite), but the formatting of the post put the "not" in an odd place.

I made a spreadsheet of all PC/DOS games supporting composite color, taken from MobyGames, and tried to determine whether they were using 320x200 or 640x200 graphics. Some I could not figure out because I did not have access to the game or screenshots. It shows that there are probably just as many games that support 320x200 color composite graphics as there are games that use the 640x200 mode for color composite graphics.

Attachments

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 151 of 758, by TeaRex

User metadata
Rank Member
Rank
Member

Here's two emulator screenshots from Apple II "Mask of the Sun" showing the effect or rather the lack of it (in the tree trunks, and in the greenish background of the other one - notice how other "mixed" colors use dithering while these do not). The emulator used here (a modified YAE 0.6) doesn't implement the kind of vertical mixing I suggested, and it uses a simple "sliding window" implementation of the Apple's artifact colors.

Does a comb filter enter into the consideration here at all? I thought its job was to "comb out" the relatively narrow bands introduced by the color signal from the upper range of the luminance signal. This would increase horizontal sharpness but wouldn't affect the vertical at all, or would it?

Attachments

  • Mask1.png
    Filename
    Mask1.png
    File size
    9.98 KiB
    Views
    4566 views
    File license
    Fair use/fair dealing exception
  • Mask2.png
    Filename
    Mask2.png
    File size
    13.8 KiB
    Views
    4566 views
    File license
    Fair use/fair dealing exception

tearex

Reply 152 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie

Does a comb filter enter into the consideration here at all? I thought its job was to "comb out" the relatively narrow bands introduced by the color signal from the upper range of the luminance signal. This would increase horizontal sharpness but wouldn't affect the vertical at all, or would it?

Yes, the delay line that you mentioned is a comb filter, and (for NTSC) the whole point of using a comb filter instead of a notch filter to separate luma and chroma is that it improves horizontal luma resolution (at the expense of vertical chroma resolution).

For PAL the situation is a bit different because of the phase alteration - without the delay line you get Hanover bars (and not the kind with nice beer).

Thinking about it, a comb filter doesn't work properly for computer-generated signals like those from Apple II and CGA anyway. That's because NTSC TV signals have 227.5 color burst cycles per scanline but Apple II and CGA actually generate 228. So when you delay by 227.5 cycles you're shifting your scanline across by the equivalent of 2 CGA high-res pixels as well as down by a scanline, which means that the horizontal resolution won't actually be improved at all by this filter for these images. And indeed I found http://www.digipedia.pl/usenet/thread/1647/8106/ which says that Apple II composite monitors don't have comb filters.

So maybe the authors of "Mask of the Sun" were labouring under a misconception, or tuned their images for some particular TV which did have a comb filter, or dithered those areas that way for some other reason entirely.

Actually, now that I remember some more details about the Apple II video hardware - that latter explanation makes much more sense. As I recall, in the "high res" graphics mode each byte controls the colours for a horizontally contiguous group of 7 pixels, each the width of a low-res CGA pixel. The 8th bit in each byte controls the phase of these pixels, so in any group of 7 pixels you can either have black/blue/orange/white or black/green/purple/white. That means you can't do horizontal dithering of green and orange or green and blue, which are the two sets of colours in your screenshots which are dithered only in the vertical direction. I'd bet that's the reason, and it's nothing to do with delay lines at all.

Reply 153 of 758, by VileR

User metadata
Rank l33t
Rank
l33t

@TeaRex: with CGA, those horizontal stripes are mostly the result of dithering meant for digital monitors, so you'll mostly get them in games that don't really target composite displays anyway. Ancient Art of War looks like it's trying to exploit both digital and composite quirks, and it kinda-sorta works, but you can't eat the cake and have it too. :)
I can't think of too many CGA games that deliberately use horizontal stripe effects for composite color blending. On the Apple II you only had 6 fixed artifact colors; the CGA could do 16 at once (and use the palette/color registers to change those 16), so I guess people didn't feel the need for such a technique.

Thinking about the kind of filtering you propose... anything directly below a black (or white) pixel would be halfway desaturated. Probably wouldn't look very good in games like Fooblitzky or Burger Time.

Great Hierophant wrote:

I made a spreadsheet of all PC/DOS games supporting composite color, taken from MobyGames, and tried to determine whether they were using 320x200 or 640x200 graphics. Some I could not figure out because I did not have access to the game or screenshots. It shows that there are probably just as many games that support 320x200 color composite graphics as there are games that use the 640x200 mode for color composite graphics.

If I may add/correct: Oil's Well, Seven Cities of Gold, Jumpman and BurgerTime should be filed under '640'. They all trigger composite emulation in DOSBox (which confirms that they use mode 6), and the colors look similar enough to Servo's captures on Mobygames.

Still, I agree with your last comment. To use artifact colors in a 320x200 game, you don't have to do anything special - just use the appropriate pixel patterns; specific support for composite video wasn't always advertised. So it's likely that even more of these games exist, just not listed as such on Mobygames.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 154 of 758, by VileR

User metadata
Rank l33t
Rank
l33t
reenigne wrote:

It's curious - the images produced seem much "blockier" than I was expecting, as if they were rendered at 320x200. I think the code is correct though - it's just than I'm using a much less sharp FIR filter than NewRisingSun did (mine is based on the one from the xanalogtv program which is part of XScreenSaver). I might tweak that some more too now that I have real hardware to compare it too - my monitor seems to have more sharpness than this algorithm.

I don't think the results look any more "blocky" than DOSBox's current implementation, though only mode 6 games can be directly compared at this point. The attached images are from Tapper - #1 is a DOSBox capture, #2 created with your code (then horizontally downsampled to 640 pixels using bilinear filtering).

Looking at Servo's hardware captures on Mobygames (see this one from the same game), they seem to have more advanced filtering going on, with less "fringing"; but I can only assume that something like this would be too computationally costly to apply in real-time, e.g. for DOSBox.

Attachments

  • tapper2.png
    Filename
    tapper2.png
    File size
    17.86 KiB
    Views
    4494 views
    File comment
    (cga2ntsc)
    File license
    Fair use/fair dealing exception
  • tapper1.png
    Filename
    tapper1.png
    File size
    10.4 KiB
    Views
    4494 views
    File comment
    (DOSBox)
    File license
    Fair use/fair dealing exception

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 155 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie

Looking at Servo's hardware captures on Mobygames (see this one from the same game), they seem to have more advanced filtering going on, with less "fringing"; but I can only assume that something like this would be too computationally costly to apply in real-time, e.g. for DOSBox.
,

Actually I think this sort of filtering is doable - it's just a different FIR filter, which requires a bit more code to set up but actual inner rendering loop is the same. Take a look at Blargg's NES libraries at http://blargg.parodius.com/ntsc-presets/ to see what sort of things have been done in the past.

The most obvious difference in Servo's tapper screenshot is the 7.16MHz vertical stripes. This is quite easy to achieve too, but I'm not sure it's really desirable. Capture cards (such as was used to make this screenshot) and some more modern TVs (like mine) will do it but it doesn't really add any clarity - the sharpness is rather artificial (7.16MHz luma signals aren't terribly useful without 3.58MHz luma signals). I also think that this wouldn't have been visible on 80s composite monitors for reasons of beam focus, dot pitch and analog bandwidth.

Reply 156 of 758, by TeaRex

User metadata
Rank Member
Rank
Member
reenigne wrote:

Actually, now that I remember some more details about the Apple II video hardware - that latter explanation makes much more sense. As I recall, in the "high res" graphics mode each byte controls the colours for a horizontally contiguous group of 7 pixels, each the width of a low-res CGA pixel. The 8th bit in each byte controls the phase of these pixels, so in any group of 7 pixels you can either have black/blue/orange/white or black/green/purple/white. That means you can't do horizontal dithering of green and orange or green and blue, which are the two sets of colours in your screenshots which are dithered only in the vertical direction. I'd bet that's the reason, and it's nothing to do with delay lines at all.

Well, maybe that's the case and I just fell into the trap of "what we're used to looks better". My multi-norm TV does the vertical filtering even when fed NTSC, and I personally think Mask of the Sun and other games that use this horizonzal striping look better that way. But maybe they don't.

tearex

Reply 157 of 758, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie

My multi-norm TV does the vertical filtering even when fed NTSC, and I personally think Mask of the Sun and other games that use this horizonzal striping look better that way.

Can you take a picture of what those same Mask of the Sun screens look like on your TV? I'm interested to see what it makes of them.

It makes some sense that any sort of blurring applied to those screens would improve the image - after all, the whole reason they're doing the dithering them is to make more colours. Arguably there's a need for emulators to have some kind of "blur" control to emulate lower-quality monitors, which may be closer to what developers targetted (and closer to what users actually experienced) than the ideal models of the best quality monitors that emulators usually implement.[/quote]

Reply 158 of 758, by VileR

User metadata
Rank l33t
Rank
l33t

Hmmm... there seems to be a bug with tint control... at least with the way I implemented it for the converter.
When using a 135 degree offset to test Tandy 1000 colors, I noticed that the chroma colors get tinted as well, though they're not supposed to. This in turn affects the artifact colors and overall the results look wrong.

Please see the attached image. I assume I'm doing the adjustment at the wrong place:

double hue_adjust = (-(45+33)+TINT)*M_PI/180.0;

Should this be moved elsewhere?

Attachments

  • tint_135.png
    Filename
    tint_135.png
    File size
    4.63 KiB
    Views
    4388 views
    File license
    Fair use/fair dealing exception

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]