Path: utzoo!attcan!uunet!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!watserv1!watmath!att!mcdchg!ddsw1!corpane!sparks From: sparks@corpane.UUCP (John Sparks) Newsgroups: comp.sys.amiga Subject: Re: Graphics standards and super-graphics s/w Message-ID: <1471@corpane.UUCP> Date: 19 Feb 90 14:10:23 GMT References: <1506@crash.cts.com> Organization: Corpane Industries, Inc., Louisville Ky Lines: 36 bobl@pro-graphics.cts.com (Bob Lindabury) writes: >In-Reply-To: message from sparks@corpane.UUCP >Besides not being able to do anything with this Dyna-Ham mode..it's really >not all it's cracked up to be. After all, any mode that only allows 16 colors >per scan line isn't any big deal. I find that certain images look a hell of >alot better in normal HAM than it Dyan-Ham because of this limitation. Wait, wait, wait. :-) I don't remember anything about only 16 colors per scanline. The only documentation I found on dynaham states that it gives you HAM in high res. Which to me means that you get 16 BASE color registers (per scanline because it is dynamic ham) but in order for it to be HAM, you should be able to modify those 16 base colors into other colors, just like in low res normal ham. >IMHO, Dyna-HAM and DDHR are just marketing ploys and do not add anything >useful to our graphics modes. I would MUCH rather see a full 8 bit board that >would support 256 colors per scan line. what is DDHR? But I agree with you above. I am glad that there IS dynaham but I don't see too much use for it, except as an oddity. Maybe if they cut down on all the CPU time it uses and come out with a paint program for it, then it would be useful. BTW: Why does dynaham take over the whole processor, and SHAM (sliced HAM) doesn't? They seem to be pretty simular processes. Does this mean just sloppy programming on the part of NewTek? -- John Sparks | D.I.S.K. 24hrs 1200bps. Accessable via Starlink (Louisville KY) sparks@corpane.UUCP <><><><><><><><><><><> D.I.S.K. ph:502/968-5401 thru -5406 I want to live forever or die in the attempt.