Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!ncis.tis.llnl.gov!lll-winken!snll-arpagw!paolucci From: paolucci@snll-arpagw.UUCP (Sam Paolucci) Newsgroups: comp.sys.amiga.tech Subject: Re: CAMG Message-ID: <124@snll-arpagw.UUCP> Date: 13 Jun 89 19:38:06 GMT References: <1373@psueea.UUCP> <122@snll-arpagw.UUCP> <123@snll-arpagw.UUCP> <253@tardis.Tymnet.COM> Reply-To: paolucci@snll-arpagw.UUCP (Sam Paolucci) Organization: Sandia National Labs, Livermore, CA Lines: 30 In article <253@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: ->Let me add my 2 cents: -> ->If an IFF picture is EXTRA_HALFBRITE or HAM, then the CAMG chunk is mandatory. -> ->If the only bits set in the CAMG chunk are just LACE and/or HIRES, then ->the chunk need not be included. -> ->With respect to the ECS: The LACE bit does not necessarily mean to use ->intelace mode. It can mean "switch to interlace (flicker) mode" or it can ->mean "do what ever is required to switch the display mode so that 400 or ->more lines are visable". If the picture has 4 colors or less, I'd say the ->latter. But a 640x400 16 color picture requires interlace. (Unless the ECS ->can do more than what I've been told.) But interlace may not be required with future Viewmodes associated with future hardware. Hopefully IFF files will still be around then. My only point is that all the parameters in use when the IFF file was created should be written out. If a reader wants to ignore half of them, then so be it. But all the info should be there to recreate it as intended if one wants to. The way the file is interpreted should not have to depend on future changes to the Amiga resolution and bitplanes. This can only happen if all the info is there. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov