TSPLC@latvax8.lat.oz (Anjin_San, Hatamoto to Lord Toronaga) (02/07/90)
G'day,
the discussion on "Faith in the Amiga" passes by the NewTek DynaHAM modes.
Does this feature of their DigiView (?) software use standard IFF files ?
I ask this because of the criticisms that the Black Belt video thingie is
supposed to subvert the "true" standards of Amiga graphics software. Thus
my question amounts to "does DynaHAM use Amiga IFF graphics standards?"
PS : I realise this may be a really naive question but I really, truely,
don't know what their s/w produces as output :-) as I don't own DigiView.
:-(
yours truly,
Lou Cavallo {out of it in good ol' Down Under}.sparks@corpane.UUCP (John Sparks) (02/09/90)
TSPLC@latvax8.lat.oz (Anjin_San, Hatamoto to Lord Toronaga) writes: >G'day, >my question amounts to "does DynaHAM use Amiga IFF graphics standards?" It really doesn't matter, because you can't do anything with the Dyna-Ham images! As far as I can tell, you can only make them and show them. Showing them takes over the entire machine so you can't even print them out. If anyone knows of any way to print out the Dyna-Ham images, I would appreciate them telling me. I did see one printout of the dynaham face (the mans face with the big pores) but it was done on a RGB video printer (gets the info from the RGB monitor port) It looked terrific. But I would like to print them on an HP paintjet. -- 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 Build something that even a fool can use, and only a fool will want to use it.
bobl@pro-graphics.cts.com (Bob Lindabury) (02/15/90)
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.
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.
-- Bob
_______________________ Pro-Graphics BBS 201/469-0049 ________________________
InterNet: bobl@pro-graphics.cts.com | ProLine: bobl@pro-graphics
UUCP: ..crash!pro-graphics!bobl | CServe: 70347,2344
ARPA/DDN: ..crash!pro-graphics!bobl@nosc.mil | Amer. Online: Graphics3D
___________ ____________
Raven Enterprises - 25 Raven Ave. Piscataway, NJ 08854sparks@corpane.UUCP (John Sparks) (02/19/90)
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.
bobl@pro-graphics.cts.com (Bob Lindabury) (02/25/90)
In-Reply-To: message from sparks@corpane.UUCP > 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) I was mistaken, Dyna-Ham (DDHR - DigiView Dynamic Hi-Res) is supposed to support 16 base colors and modify them from there but actually doesn't in DigiView 4.0. All my translations from 24 bit RGB files has been through DigiView 4.0 which I've been told only allows for 8 base colors. This causes the translations to lose alot more color than they should. Since this mode is so kludgy, I would have rather that it was not even available. It just postpones the development of a REAL graphics adapter for the Amiga. Even though there are a couple of frame-grabber's available for the Amiga, they are not being supported by most of the major players (mainly EA with Dpaint III) so they are not viable alternatives. -- Bob _______________________ Pro-Graphics BBS 201/469-0049 ________________________ InterNet: bobl@pro-graphics.cts.com | ProLine: bobl@pro-graphics UUCP: ..crash!pro-graphics!bobl | CServe: 70347,2344 ARPA/DDN: ..crash!pro-graphics!bobl@nosc.mil | Amer. Online: Graphics3D ___________ ____________ Raven Enterprises - 25 Raven Ave. Piscataway, NJ 08854
Jim.Priestle@afitamy.fidonet.org (Jim Priestle) (03/02/90)
** Quoting John Sparks to All ** >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 ** End of Quote ** Unless I'm wrong, there is some gross misunderstandings here. First, there is not such thing as "Dyna-Ham". You refer to new-tek and new-tek's new mode is "Dynamic Hi-Res (DHR)". Itt is not "ham" because HAM mean "Hold and Modify" and there is no hold-and modifying going on. It DOES allow 4096 colors on the screen at once, but does this by changing the 16-color palett on each scan-line. HAM takes a pixel and modified one color (R, G, or B) while DHR uses the copper-list. I don't know too much about SHAM, HAM-E, etc, but a posting by someone that list all the particulars of these mode would be appriciated. -jim- -- ------------------------------------------------- Jim Priestle - via FidoNet node 1:110/300 UUCP: uunet!dayvb!afitamy!Jim.Priestle ARPA: Jim.Priestle@afitamy.fidonet.org -------------------------------------------------| >>>> The // Air Force Institute of Technology | > // Amiga Users BBS/UFGateway | > \ // Dayton, Ohio (513)-252-7681 | > X/ 1:110/300 | -------------------------------------------------|
gilmore@vms.macc.wisc.edu (Neil Gilmore) (03/04/90)
(Gee, so much to comment on today) Concerning discussion of 'illegal' video modes. I do not object to these sorts of cheats in order to create better pictures. I feel that these modes are indeed limited insofar that using up processor time prevents much of their use in 'normal' programs. But for those who need enhanced capability, such as those animators who can record single-frame, the new modes are a boon. This does not make the normal modes obsolete, it just creates a new category for a specialized need. +-----------------------------------------------------------------------+ | Kitakaze Tatsu Raito Neil Gilmore internet:gilmore@macc.wisc.edu | | Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 | | Middle Kingdom Madison, Wi | +-----------------------------------------------------------------------+
krag@cup.portal.com (Kevin Ray Grotjohn) (03/05/90)
Has anyone seen the TurboColors hack. I swear it allows 29,000 + colors with 30 shades of RGB rather than 16 without flickering or dithering. How do they do that with only 4 bit video dacs.
olsen@hpfcdq.HP.COM (John Olsen) (03/06/90)
krag@cup.portal.com (Kevin Ray Grotjohn) writes: >Has anyone seen the TurboColors hack. I swear it allows 29,000 + colors >with 30 shades of RGB rather than 16 without flickering or dithering. >How do they do that with only 4 bit video dacs. It's really not that tough. All you need to do is open two non-interlace screens and swap between them every refresh. That way, you can use color 00f (bright blue) on one screen, and at the same position on the other screen you use 00e (nearly bright blue). What you see on the screen is about halfway between the two, magically giving you 30 shades of the primary colors (not counting black) by using shades half-way between the existing shades. You can possibly get more shades if you don't use adjacent color values, but the flicker would soon become noticeable. With nearly-identical values, the flicker should be hard to see even for those who are driven nuts by interlace. (For you techno-weenies, the additional (>30) shades would show up because the brightness values are non-linear, so adding color 003 to 00b doesn't necessarily average out to create 007. The bad news is that results may not be repeatable over larger spreads like that.) Also, you could use interlaced screens, but you would end up swapping every 1/30 second instead of 1/60 which might also add to the flicker problem. (Swapping between two interlaced screens? Eech!) John M. Olsen, Graphics Software Engineer olsen@hpfcdq.HP.COM -or- ...!hplabs!hpfcdq!olsen (W) Hewlett-Packard, MS 73, 3404 E. Harmony Road, Ft Collins, CO 80525 (H) 700 E. Drake Rd. #E12, Ft Collins, CO 80525
dfrancis@tronsbox.UUCP (Dennis Francis Heffernan) (03/15/90)
> Unless I'm wrong, there is some gross misunderstandings here. First, there is > > not such thing as "Dyna-Ham". Um, there is such a thing as Dynamic HAM. It seems to work the same way as SHAM, basically, but IMHO it doesn't give as good results and it does insist on shutting down multitasking when used. I occasionally DynaHAM things to see what they look like, but I haven't bothered saving any such images yet. I'd really like to see a Digi-View RGB to SHAM converter, but my skills in programming are limited to the occasional rexx script. Dennis Francis Heffernan | "Great spirits have always dfrancis@tronsbox | encountered violent opposition ...uunet!tronsbox!dfrancis | from mediocre minds" Killer GM- Reasonable fees | --Albert Einstein