Sullivan@cup.portal.com (sullivan - segall) (12/20/89)
>In article <19331@watdragon.waterloo.edu>, rsingh1@dahlia.waterloo.edu writes: >> These last 2 modes are GREAT for display (slide show's). Recently, I did >> a job where I converted 640x480 HAM's to GIF (reduced to 256 colours) for >> display on an IBM VGA. The results were nice, but I realized that now I >> could display BETTER images with these dynamic modes. > >Remember, you started with HAM images. That means that most of the >color information was already thrown away when you had to reduce to >4 bits per primary. No wonder the VGA images looked bad. If you ... >produce much smoother shading gradations. A degenerate though >frequently occurring case is grey scale images. The Amiga, no >matter how you slice it, will only produce 16 levels of grey. A VGA >board will do 64. The difference is amazing. If you add dithering >the VGA image will approach black&white photo quality while the >Amiga image will still be trying to catch up with the straight VGA. > All of this discussion of sliced, diced, etc. HAM, EHB, or what have you, versus VGA displays reminds me of some color tests I was playing with last year: A technique which could be described as Vertical-dithering is also possible using Amiga hardware. The method is this: To get 31 shades of grey -- On every even frame display the closest lower shade of grey. On every odd frame display the closest higher shade of grey. Your eye will tend to mix shades which are rapidly alternated without noticeable flicker, if the colors are close to one another. A similar effect could be produced by mixing different colors on alternating frames for a potential palette of about 8191 shades. This effect can be produced with minimal coprocessor overhead (but substantial memory overhead), or by changing the color registers on the fly. A similar technique would be to separate the three colors (R,G,B) and display them separately in sequence, in high res. My tests tend to indicate that doing so will cause the phosphor to flicker noticeably, but perhaps a maintenance pulse ( like 1, 1, R, ... 1, G, 1, ..., B, 1, 1) would help to reduce flicker. As far as I can tell, all of this has to be done in non-interlace. The update rate for interlaced screens is too slow, and the phosphor dies completely before it is refreshed. If anyone is interested, I can send some more info after New Years.... and maybe even dig up some old code. Merry Chrismas all. -ss