bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/09/87)
[ A500 ]
Ok, I'm upset. I just went through three, count them, THREE IFF viewers.
ALL of them hogged processor time while displaying the picture. This is
hard to do with the Amiga. They must have really worked at it!!
Having all three viewers do this is odd. Perhaphs a bug in the IFF routines
from Electronic Art/Amiga??
-Strange-
PS. I just found one that does not (phew!). It's called USHOW and will do
all the formats (HAM, LO, HIGH, INTERLACE, OVERSCAN). At 996 bytes it is the
smallest yet. (68000 source available from author)
( If you want it, i'll upload it to the usenet mail location of your choice,
even comp.binaries, if there is demand )
-------------
Ack! (NAK,EOT,SOH)
|\ /| .
{o O} . bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
( " )
U Single tasking? Just say *NO!*hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) (06/09/87)
In article <8706090134.AA03008@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >[ A500 ] > >Ok, I'm upset. I just went through three, count them, THREE IFF viewers. >ALL of them hogged processor time while displaying the picture. This is >hard to do with the Amiga. They must have really worked at it!! I doubt the fault lies in the EA routines; the IFF routines merely allocate a bitmap and load the picture into it, they don't display the image. It is up to the IFF client to display the image and wait for some input before exiting. It's probably just a case of somebody busy-waiting for input.-
dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/09/87)
:> :>Ok, I'm upset. I just went through three, count them, THREE IFF viewers. :>ALL of them hogged processor time while displaying the picture. This is :>hard to do with the Amiga. They must have really worked at it!! : : I doubt the fault lies in the EA routines; the IFF routines :merely allocate a bitmap and load the picture into it, they don't :display the image. It is up to the IFF client to display the image :and wait for some input before exiting. It's probably just a case of somebody :busy-waiting for input. You misunderstood bryce.... Bryce *was* talking about the fact the programs are busy waiting for input, which is pretty darn hard to do even for an idiot programmer. I also noticed that COSMO2 busy waits for input (A PD asteroids-like game).. Of course, COSMO2 has other problems.... (at least v2 runs on 1.2). -Matt
kim@amdahl.amdahl.com (Kim DeVaughn) (06/10/87)
In article <8706090134.AA03008@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > > I just found one that does not (phew!). It's called USHOW and will do > all the formats (HAM, LO, HIGH, INTERLACE, OVERSCAN). At 996 bytes it is the > smallest yet. (68000 source available from author) Another nice thing about "ushow" is that it seems to be quite a bit "looser" than other viewers. I've had several image files that other viewers, DPaint, etc. refused to load. Ushow has been able to load most of them (probably because it does a very minimal amount of error checking due to it's small size). After loading them with ushow, I was able to capture the displayed image with GRABBiT, and could then load that image into DPaint, etc. Now I know that the original image files had been corrupted (probably extra characters on the tail end that XMODEM tacked on), but the images sure looked OK. I think it might be a good idea for people who are writing programs that load any IFF-type file (graphics, music, whatever) to include options that permit one to continue to attempt loading of a corrupt file. After all, the damage may not be very severe ... And just think, listening to your complier, or viewing your spreadsheet might not be as awful as it sounds ... could this be the start of a whole new art form? Wonder if Manx or Lattice sounds better ... :-) /kim P.S. I don't recall this being documented in ushow, but I have found that by default, hitting *any* key (including shift, alt, etc.) will terminate ushow's display of the image. However if you first click on the image with the left mouse button, you can then hit any keys you want to without terminating the display (to invoke a screen dumpper, or what- ever). In this mode, you terminate ushow by clicking in the (invisible) close gadget in the upper left corner. -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner CATS) (06/11/87)
In article <8706090134.AA03008@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > >Ok, I'm upset. I just went through three, count them, THREE IFF viewers. >ALL of them hogged processor time while displaying the picture. This is >hard to do with the Amiga. They must have really worked at it!! > >Having all three viewers do this is odd. Perhaphs a bug in the IFF routines >from Electronic Art/Amiga?? That's probably my fault. My first IFF viewer (SeeILBM) had to be thrown together very quickly so that we would have a pull-down-able screen viewer on the second release of the IFF stuff (because the EA supplied viewer ShowILBM had some problems when started from Workbench because it used a ViewPort rather than a screen). Anyway, I grabbed some old screen/window code from my first Amiga program and patched it into ShowILBM to create SeeILBM. That old code contained some rather stupid mistakes, one of which caused it to busywait. There are probably other viewers floating around based on this early example. Any one who is writing code to handle ILBM's should get the latest IFF release (Fish #64) and look at the non-busywaiting HAM-capable (and color-cycling) viewer "Display". -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
glee@cognos.uucp (Godfrey Lee) (06/17/87)
Is ushow on a Fish disk? If not, please post it on usenet. -- ----------------------------------------------------------------------------- Godfrey Lee, Cognos Incorporated, 3755 Riverside Drive, Ottawa, Ontario, CANADA K1G 3N3 (613) 738-1440 decvax!utzoo!dciem!nrcaer!cognos!glee
robertw@hpcvc0.HP (Robert Williams) (06/25/87)
Yes, Please post ushow to comp.bin.amiga (or whatever). If you have source, that might be interesting too.