bleys@tronsbox.xei.com (Bill Cavanaugh) (05/27/91)
I've been thinking of purchasing the Art Department, having spent a few hours playing with the demo. I'm VERY impressed with the look of the program, and it's amazingly simple interface. I've got a few questions for people who've used it... When I run the demo, I often get a message that I don't have enough memory to handle the picture. I'm trying to load a 120K gif, and I've got 3 megs of ram on a four-year-old A500. Is this part of the crippled nature of the demo? If not, has the problem been addressed in the current release of the software? I noticed that the demo grabs a LOT of memory when it's first run, rather than grabbing it as-needed. Since I have three megs, this shouldn't be a problem, but I was wondering if the live version works this way, or does dynamic allocation? Does the REXX support allow access to all of the commands that are in the Intuition interface? Are there any commands that are available ONLY through REXX? (I think I might have found a reason to get more profficient at AREXX...<grin>). Thanks in advance for any help you folks can give me in making a purchasing decision! I haven't spent that much of my own money on one software package since WordPerfect! -- * Bill Cavanaugh bleys@tronsbox.xei.com * * * * Who woulda thought that by staying in one place * * I'd become a refugee? * * * * Doug and the Slugs *
don@chopin.udel.edu (Donald R Lloyd) (05/27/91)
Art Department demo? Where might this be found?
--
Gibberish May the Publications Editor, AmigaNetwork
is spoken fork() be Amiga Student On-Campus Consultant, U of D
here. with you. DISCLAIMER: It's all YOUR fault.hrlaser@crash.cts.com (Harv Laser) (05/28/91)
ADPro grabs the largest contiguous chunk of FAST memory it can find when it runs. If that chunk is 1 meg or 453K or 8 meg or whatever it is, ADPro will grab the whole thing. It does not allocate memory dymanically. If you want to tell it, at runtime, to grab less than your largest contiguous chunk of FAST memory available, then you can give it a command to do so. If, say, you had a bunch of files sitting in RAM at the time you ran ADPro and then after running it, decided that you needed to throw some more memory at it, deleting the files from RAM wouldn't do it. You'd have to delete those files, quit ADPro and run it again. No big deal. Yes the ARexx support allows access to all of the commands that are in the program's interface. I don't know if there are any ARexx only commands that can't be duplicated in the interface, but I'd guess there are not. By the way, if it's The Art Dept. you've been looking at, consider that Art Dept. Professional offers a LOT more features, not to mention Savers as well as loaders and operators. There's just a whole lot more to it.
cazabon@hercules (Charles Cazabon (186-003-526)) (05/28/91)
In article <1644@tronsbox.xei.com> bleys@tronsbox.xei.com (Bill Cavanaugh) writes: >I've been thinking of purchasing the Art Department, having spent a few >hours playing with the demo. I'm VERY impressed with the look of the >program, and it's amazingly simple interface. I've got a few questions >for people who've used it... > >When I run the demo, I often get a message that I don't have enough >memory to handle the picture. I'm trying to load a 120K gif, and I've >got 3 megs of ram on a four-year-old A500. Is this part of the >crippled nature of the demo? If not, has the problem been addressed in >the current release of the software? > The reason that TAD or ADPro require so much memory is that when they load in a picture, they convert it to either 24 bit colour information or 8 bit greyscale information. Couple on top of this the fact that GIF pictures are stored in a file with a compression scheme similar to LZH, and you get mega-memory requirements. For example: a 256 colour GIF picture that occupies 120K of disk space will, when loaded, take up (on average) 180K of ram. This is for 8 bit colour data, so to get 24 bit colour, triple it. That is a hunk of contiguous memory 560K long. Then on top of that, you have the memory that is needed for the display (say, roughly 100K for a 320x400 HAM image), and then on top of that, the memory needed for the program itself. I think that five megs is the minumum to use the program well. Hope this was of help. -Chuck cazabon@hercules.uregina.ca
James_Hastings-Trew@tptbbs.UUCP (James Hastings-Trew) (05/28/91)
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.
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/29/91)
In article <1644@tronsbox.xei.com> bleys@tronsbox.xei.com (Bill Cavanaugh) writes:
Does the REXX support allow access to all of the commands that are in
the Intuition interface?
Yes.
Are there any commands that are available ONLY through REXX?
Yes, but they are only maintenance type thing (i.e. - to found out how
much free memory you've got, you wade through the about requester in
intuition. In Rexx, you ask.). There's nothing important hiding there.
<mike
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@pa.dec.com
How many times do you have to fall decwrl!mwm
Before you end up walking?perry@madnix.UUCP (Perry Kivolowitz) (06/06/91)
In article <17203@chopin.udel.edu> don@chopin.udel.edu (Donald R Lloyd) writes: > > Art Department demo? Where might this be found? A demo version TAD (not ADPro) is available from your local dealer. If they don't have it - have them contact ASDG - we'll be glad to send it to them. The demo version will not save images, and it will clip 25 percent of the height of the image. A demo version ADPro is *not* forthcoming - at over 50 programs a demo version would be unworkable for us. Perry -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg
perry@madnix.UUCP (Perry Kivolowitz) (06/06/91)
In article <473@regina.uregina.ca> cazabon@hercules.uregina.ca (Charles Cazabon (186-003-526)) writes: >In article <1644@tronsbox.xei.com> bleys@tronsbox.xei.com (Bill Cavanaugh) writes: >>I've been thinking of purchasing the Art Department, having spent a few >>hours playing with the demo. I'm VERY impressed with the look of the >>program, and it's amazingly simple interface. I've got a few questions >>for people who've used it... Thank you. It's been said that TAD's user interface ``hides the complexity of the program.'' What higher complement can you pay a user interface? ADPro's UI is very similar to TAD's. About memory usage, Chuck replies: >The reason that TAD or ADPro require so much memory is that when they load >in a picture, they convert it to either 24 bit colour information or 8 >bit greyscale information. Couple on top of this the fact that GIF pictures ><and so on> Chuck's response was dead on. Here's how to guess at TAD and ADPro's memory requirements: TAD: WIDTH * HEIGHT * 3.75 (Color) WIDTH * HEIGHT * 1.75 (Gray) ADPRO: WIDTH * HEIGHT * 4 (Color) WIDTH * HEIGHT * 2 (Gray) All images are converted to either 8 bit-plane gray or 24 bit-plane color as they are read in. Additionally, we reserve space for the rendered data as well (for example, this is why you multiply by 4 in ADPro (color) instead of by 3). ADPro uses a hair more space than TAD because ADPro can render in up to 8 bit-planes where TAD renders only up to 6 bit-planes. Also, ADPro has an enhanced palette mode which currently uses gobs of memory also (about 400K). BUT! The enhanced palette mode can be disabled so that the memory it would have used can be used for picture data instead. All features of the user interface in ADPro can be accessed from ARexx. TAD does not have an ARexx interface. Yes, there are features which can only be accessed from ARexx in ADPro - namely those features that make sense from ARexx like putting up a file requester under program control, and the like. Hope this answers Bill's original post and gives Chuck an ``attaboy'' for his correct and concise explanation. Perry -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg
neil@celia.UUCP (Neil Richmond) (06/11/91)
Perry,
It is cool seeing one of you guys on the net. I have a question. Can TAD or
ADPro read Wavefront format images (.rla). This would be useful to me because
then I wouldn't have to write my own. Also, I didn't notice if ADPro or TAD
could write DCTV images, although this is not as important since DCTV reads
24 bit iff files. Thanks.
neil
--
Only 3126 shopping days left till the next millenium!
Neil F. Richmond INTERNET: celia!neil@usc.edu
Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)cazabon@hercules (Charles Cazabon (186-003-526)) (06/12/91)
In article <1054@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes:
:Perry,
:
:It is cool seeing one of you guys on the net. I have a question. Can TAD or
:ADPro read Wavefront format images (.rla). This would be useful to me because
:then I wouldn't have to write my own. Also, I didn't notice if ADPro or TAD
:could write DCTV images, although this is not as important since DCTV reads
:24 bit iff files. Thanks.
:
If AdPro doesn't currently support it, then send a file specification to
ASDG, makers of the Art Department and Professional. They say they will
write one for you. Perhaps, if it is common enough, you won't even need
to send them a specification.
They want to support EVERYTHING.
:--
:Only 3126 shopping days left till the next millenium!
:Neil F. Richmond INTERNET: celia!neil@usc.edu
:Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
That's my input...
--Chuck Cazabon, cazabon@hercules.cc.uregina.ca
* My Opinions Are Not My Own...Feel Free To Plagiarize perry@madnix.UUCP (Perry Kivolowitz) (06/17/91)
In article <1054@celia.UUCP> celia!neil@usc.edu (Neil Richmond) writes: >I have a question. Can TAD or >ADPro read Wavefront format images (.rla). This would be useful to me because >then I wouldn't have to write my own. Also, I didn't notice if ADPro or TAD >could write DCTV images, although this is not as important since DCTV reads >24 bit iff files. Thanks. We do not posses the specifications for .rla files. We would have a keen interest in supporting this particular format if you could send us a written spec and an amiga disk with sample images. Neither TAD nor ADPro can currently write DCTV images. This will be included, however, in the next relase of ADPro which is in planning stages now. pk -- Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.'' UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 PLINK: pk-asdg