[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IIgs RGB to YPbPr Component experiment
mdj wrote:
Michael J. Mahon wrote:
It's only "nominally" 140 pixels horizontally--it's actually 560
pixels with full artifacted glory. ;-) For example, the 140
Apple "pixels" don't have to be placed on mod 4 boundaries!
That's right, but mod 2 boundaries would be close enough to make hires
colour look pretty nice. I'm concerned that having multiples of 560 is
not even enough for full artifacts as it will look too sharp. Bring on
300dpi displays! :-)
It certainly is true that more resolution makes many problems
simpler.
Earlier, I've suggested that gross oversampling, combined with
low-pass filtering, could remedy many of the ills caused by lack
of sampler sync with the Apple dot clock.
Actually an 840x768 raster would work pretty well for everything,
except monochrome dhr.
Not for programs that create colors across "pixel" boundaries...
Well, it gives you 3 digital pixels per hires pixel, so it's enough to
half-dot shift. I don't think it's possible to generate a dot more less
that two raster pixels wide in hires mode.
Yes, I agree. I think with proper low-passing of the signal used
to assign colors, the result could be quite smooth.
Just looking at the fact that rather impossible to generate a decent
result on a 'regular' 15" digital panel. I think in my case I'll not
try, and let the VGA output + the scan convertors built into such
displays handle it, and concentrate on an output compatible with
slightly larger panels
Trying such algorithms out in software would make good sense.
Software can easily duplicate anything that hardware could
produce, and it's probably easier to try a lot of alternatives.
(Of course, hardware is getting pretty "soft" these days, too. ;-)
-michael
Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."