kiyote wrote:Still playing with this stuff..
Video of it in action, a longer clip, now on youtube.
Your video got blocked, dude.
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...
Dig Dug (clearly not meant for composite)
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?
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.
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.
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.
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.
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.
double hue_adjust = (-(45+33)+TINT)*M_PI/180.0;
Users browsing this forum: TheGreatCodeholio and 0 guests