Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!lll-winken!aunro!alberta!herald.usask.ca!telepro!tptbbs!James_Hastings-Trew From: James_Hastings-Trew@tptbbs.UUCP (James Hastings-Trew) Newsgroups: comp.sys.amiga.graphics Subject: TAD/ADpro information. Message-ID: Date: 28 May 91 05:06:06 GMT Article-I.D.: tptbbs.James_Hastings-Trew.3160 Organization: TelePro Technologies Lines: 32 In a message dated Mon 27 May 91 08:48, Bleys@tronsbox.xei.com (bill Cavana wrote: BC> When I run the demo, I often get a message that I don't have enough BC> memory to handle the picture. I'm trying to load a 120K gif, and BC> I've BC> got 3 megs of ram on a four-year-old A500. Is this part of the BC> crippled nature of the demo? If not, has the problem been addressed BC> in BC> the current release of the software? What you have to understand is that Art Department (Pro or not) converts ALL pictures loaded into a full 24 bit format. Your 120K GIF file might have been very large - 640 * 400 or more in size) which would make for a very large 24 bit image in it's buffer. BC> I noticed that the demo grabs a LOT of memory when it's first run, BC> rather than grabbing it as-needed. Since I have three megs, this BC> shouldn't be a problem, but I was wondering if the live version works BC> this way, or does dynamic allocation? No, the release versions do the same thing. I have a 9 meg machine, and ADPro grabs all of it when it is run. It just grabs everything it can gets it's hands on right away, mainly (I think) because it does not know what you want to do with a picture - you might want to bring in a 800 * 800 bitmap and scale it up 200%. It has to have the largest buffer it can muster, because it can't (very easily) dump out the existing buffer to grab a new one. It pretty much has to do what it does. Also, three megs is a small machine these days, especially when it comes to messing with graphics in any kind of large colour-space. Get more RAM. Trust me, you'll use it.