axjjb@acad2.anc.alaska.edu (BRYANT JOHN J) (10/26/90)
After my post of memory woes while running The Art Department, it was suggested that I get more memory (Kinda makes sense eh? :-) Anyways, With 3 megs of RAM (1 meg chip, 2 megs fast) The Art Department is fantastic. I have been rendering pictures left and right and I am extrememly pleased withthe results. The Art Department is a must for anyone using graphics. Note: I am in no way afficliated with ASDG (makers of the The Art Department). I am just a very satisfied customer. John J Bryant Student Computer User Consultant University of Alaska Anchorage Disclaimer: I said what???
jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) (10/26/90)
axjjb@acad2.anc.alaska.edu (BRYANT JOHN J) writes: >Anyways, With 3 megs of RAM (1 meg chip, 2 megs fast) The Art Department is >fantastic. I have been rendering pictures left and right and I am extrememly >pleased withthe results. The Art Department is a must for anyone using >graphics. I totally agree. However I've got 8MB, and it leaves me with about 1.5MB free. I don't mind this at all, I just run TAD last (after whatever else I run allocates whatever memory it/they needs/need), and all is well. >John J Bryant >Student Computer User Consultant >University of Alaska Anchorage >Disclaimer: I said what??? -- +----------------------------------------------------------------------------+ | "Earth destroyed by solar flare. Film at eleven" - The last nightly news.| +----------------------------------------------------------------------------+ | jeffo@mrcnext.cso.uiuc.edu These opinions are mine, that's all.| +----------------------------------------------------------------------------+
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (10/26/90)
In article <1990Oct25.224025.7029@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: >I totally agree. However I've got 8MB, and it leaves me with about 1.5MB free. >I don't mind this at all, I just run TAD last (after whatever else I run >allocates whatever memory it/they needs/need), and all is well. 6.5 megs used by TAD? What the heck are you doing? Converting TWO images at once? I've got 5 megs of RAM and can run TAD while also running a local and line one window in Paragon. -- John M. Adams --**-- Professional Student on the six-year plan! /// Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// "We'll always be together, together in electric dreams" Moroder & Oakey \\V// Sysop of The Beachside. FIDOnet 1:3612/557. 904-492-2305 (Florida) \X/
jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) (10/27/90)
jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >6.5 megs used by TAD? What the heck are you doing? Converting >TWO images at once? I've got 5 megs of RAM and can run TAD >while also running a local and line one window in Paragon. >-- >John M. Adams --**-- Professional Student on the six-year plan! /// >Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// >"We'll always be together, together in electric dreams" Moroder & Oakey \\V// >Sysop of The Beachside. FIDOnet 1:3612/557. 904-492-2305 (Florida) \X/ No, TAD just allocates that much, I don't know why or how much of that it actually needs, but it does grab quite a bit. I could just run other stuff first and let it grab what it needs (for instance, I use a 1MB review buffer for VLT, so I run VLT first then TAD if I want both to be running at the same time). It's really strangehow TAD allocates all that memory, but all I'm doing is either looking at files, or converting them to IFF. I really like TAD though (I had to throw that in!) Jeff -- +----------------------------------------------------------------------------+ | "Earth destroyed by solar flare. Film at eleven" - The last nightly news.| +----------------------------------------------------------------------------+ | jeffo@mrcnext.cso.uiuc.edu These opinions are mine, that's all.| +----------------------------------------------------------------------------+
arc@desire.wright.edu (10/27/90)
In article <25124@uflorida.cis.ufl.EDU>, jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: > In article <1990Oct25.224025.7029@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: >>I totally agree. However I've got 8MB, and it leaves me with about 1.5MB free. >>I don't mind this at all, I just run TAD last (after whatever else I run >>allocates whatever memory it/they needs/need), and all is well. > > 6.5 megs used by TAD? What the heck are you doing? Converting > TWO images at once? I've got 5 megs of RAM and can run TAD > while also running a local and line one window in Paragon. > -- > John M. Adams --**-- Professional Student on the six-year plan! /// > Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// > "We'll always be together, together in electric dreams" Moroder & Oakey \\V// > Sysop of The Beachside. FIDOnet 1:3612/557. 904-492-2305 (Florida) \X/ I think what TAD does it take the memory from your system at startup, depending on how much mem. you have.
perry@madnix.UUCP (Perry Kivolowitz) (11/04/90)
In article <1990Oct25.224025.7029@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: >axjjb@acad2.anc.alaska.edu (BRYANT JOHN J) writes: > >>Anyways, With 3 megs of RAM (1 meg chip, 2 megs fast) The Art Department is >>fantastic. I have been rendering pictures left and right and I am extrememly >>pleased withthe results. The Art Department is a must for anyone using >>graphics. > >I totally agree. However I've got 8MB, and it leaves me with about 1.5MB free. >I don't mind this at all, I just run TAD last (after whatever else I run >allocates whatever memory it/they needs/need), and all is well. Thank you both for your sentiments, we do try. TAD is written to look for the largest contiguous block of memory you have and to allocate it for its primary image buffer. TAD's memory requirements are like so: For a color image: WIDTH x HEIGHT x 3.75 bytes For a gray image: WIDTH x HEIGHT x 1.75 bytes TAD will always leave 1/16 of your ram available or 64K whichever is larg- er. ADPro (Art Department Professional coming very soon) requires: For a color image: WIDTH x HEIGHT x 4 bytes For a gray image: WIDTH x HEIGHT x 2 bytes However, ADPro allows you to specify the max size of its primary imaging buffer. So, on a machine like an 18 megabyte A3000, you can ask ADPro to use only enough memory as you need. If you liked TAD...I think you'll find ADPro better still. -- 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
drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) (11/05/90)
That 3.75 bytes per pixel is a pain! I have 5 megs (1 meg chip, 4 fast) and I cannot load in a 1024x1024x256color picture. My calculations tell me that that is 1Meg pixels. At 24 bits per pixel that is 3 megs. However, 3.75 megs (even if I run ONLY TAD) is not available so I can't do anything with these GIFs. Isn't there some work around for this? Rick Tillery (drtiller@uokmax.ecn.uoknor.edu)
perry@madnix.UUCP (Perry Kivolowitz) (11/10/90)
In article <1990Nov5.053442.4010@uokmax.ecn.uoknor.edu> drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes: >That 3.75 bytes per pixel is a pain! I have 5 megs (1 meg chip, 4 fast) and >I cannot load in a 1024x1024x256color picture. My calculations tell me >that that is 1Meg pixels. At 24 bits per pixel that is 3 megs. However, >3.75 megs (even if I run ONLY TAD) is not available so I can't do anything >with these GIFs. Isn't there some work around for this? The 3.75 is derived from 3 (for 24 bit-planes/8 bits-per-byte) for storing the raw image data at its fullest resolution plus .75 (6 bit-planes/8 bits-per- byte) for storing an Amiga displayable rendered image area. Just a little more contiguous fast ram would do the trick. Unfortunately, there's no other work around and still get TAD's quality/speed. IE: you can store less image data (and get speed but less quality) or page from disk (get quality if the package is otherwise as good as TAD, take a big speed hit). -- 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
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/11/90)
In <35817@cup.portal.com>, Classic_-_Concepts@cup.portal.com writes: > >Unfortunately I got caught by this. I have boards from two different >manufacturers (one internal, one external on my 1000) and they were >purchased when memory was not cheap. The largest chunk of *contiguous* >RAM I can currently address, given that I have to use a big chunk for RAD >to make the 1000 even usable, is just over a meg. Not enough to get good >use out of the Art Department. Have you tried 'mergemem'? -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
Classic_-_Concepts@cup.portal.com (11/11/90)
In this discussion of the Art Department, I think it would be appropriate
to let people know about TAD's memory requirements. I think it's impor-
tant not only because it indicates the direction of Amiga software, but
also, in all fairness, should be known to people with 'low-end' systems
before they invest money in software they may not be able to use.
From the manual:
"By its very nature, TAD requires a lot of memory. In fact
TAD will utilize as much *contiguous* (emphasis mine) memory
as you have on your machine. While it can run in as little
as one megabyte of memory, we suggest a minimum of four
megabytes of expansion memory in order to get any substantial
work accomplished."
Point #1 is obvious: with memory getting cheaper and graphics displays
increasing in resolution and bitplanes, manufacturers are producing products
which require more memory. I'm sure this trend will increase rather than
decrease.
Point #2 concerns contiguous RAM:
If you're thinking of adding expansion memory, I'd strongly
recommend against boards which are only expandable to 1 or 2
megs (these recommendations assume your primary interest is
graphics on the Amiga) *unless* you can match up boards which
address contiguous bytes, or which are configurable. This is
usually not the case, however.
If you already have expansion RAM and you need more, either
sell your existing memory to finance a board which addresses
a larger chunk of RAM or check with the manufacturer about
the beginning and end addresses and see that they follow one
from the other.
Unfortunately I got caught by this. I have boards from two different
manufacturers (one internal, one external on my 1000) and they were
purchased when memory was not cheap. The largest chunk of *contiguous*
RAM I can currently address, given that I have to use a big chunk for RAD
to make the 1000 even usable, is just over a meg. Not enough to get good
use out of the Art Department.
So, all of the above is obvious to techies, but there are lots of graphics
and video folks out there purchasing Amigas who need to be aware of the
above so they can put together a 'workable' system. Since lots of them
start with a couple of meg and add on later, I thought a little forewarning
might save a few people some frustration in the future.
The Art Department looks great. (I just wish I could use it.)
Julie Petersen (LadyHawke)limonce@pilot.njin.net (Tom Limoncelli) (11/11/90)
In article <35817@cup.portal.com> Classic_-_Concepts@cup.portal.com writes: > "By its very nature, TAD requires a lot of memory. In fact > TAD will utilize as much *contiguous* (emphasis mine) memory > as you have on your machine. While it can run in as little At one time I considered pre-allocating all the memory that I *might* need right at program start. I figured it would avoid the need to check every my_alloc_mem() for failure. It would also mean that I could deallocate everything easier. The former would completely avoid the "out-of-memory crashes" that people complain about. It turned down the idea because I didn't want to waste the memory; other programs could use that memory when I'm not using it. The phrase I invented to describe the technique was that the program "made it's own sandbox so that it could ignore the others". I thought it that if I wrote a program that did this people would accuse the technique of being a holdover from the C-64 mentality. "If I can't have the whole machine, I'll just make my own mini-machine and stay within it." ASDG's technique has similar qualities but is one step closer to "making your own sandbox" because it's a contiguous block (or "box"?). Now I understand how ASDG makes their software so reliable. :-) This all confuses me because ASDG is the one company that I've never seen have a C-64 mentality. Maybe I'm off the wall and this is an accepted technique that everyone uses. What I do now is try to reduce X, where X is the number of calls to Alloc(). ASDG has taken this to an extreme. I can understand this for a program that will be doing many, many Alloc()s and Dealloc()s, but with TAD there are few times when Alloc()s are done. (This is based on the assumptions since I have only watched TAD being used, I've never seen the source code or monitored it's memory usage as the program is run). Specifically, I would assume that Alloc()s and Dealloc()s would only happen when modes are switched, new pics are loaded, or new pics are being generated based on other pic(s). That's a pretty low X. I could understand pre-allocating everything to do with ARexx handling and some UI work, but this is extreme. This isn't a flame. I'm just wondering if my theory is correct, and how others feel about this programming technique. I understand that Art Department Pro will have some user-settable memory usage control. I'm not against this technique, I'm just wondering if it's a one that should be taken to such an extreme. -Tom -- tlimonce@drew.edu Tom Limoncelli "Flash! Flash! I love you! tlimonce@drew.bitnet +1 201 408 5389 ...but we only have fourteen tlimonce@drew.uucp limonce@pilot.njin.net hours to save the earth!"
seanc@pro-party.cts.com (Sean Cunningham) (11/15/90)
In-Reply-To: message from perry@madnix.UUCP You brought up something I was interested in. Working with a larger file on disk. Even if you can't now, do you think TAD will ever let you work with images that would be just to large for RAM. Like some scanned in photos for a magazine spread or something, where they're sometimes 200MB or more? Have TAD give you a screen version for making color corrections, dithering, etc. And then have the processes you just ran on the screen work on the BIG file. Just a idea... Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.0 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc | B^) VISION GRAPHICS B^) ARPA: !crash!pnet01!pro-party!seanc@nosc.mil | ~~~~~~~~~~~~~~~~ INET: seanc@pro-party.cts.com | Dual A3000 based, custom Help keep the | computer graphics, RealWorld: Sean Cunningham competition // | animation, presentation, Voice: (512) 992-2810 under \X/ | simulation, accident- | scene re-creation, and "Does anyone remember laughter?" Robert Plant| recreation...(whew!) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
perry@madnix.UUCP (Perry Kivolowitz) (11/25/90)
In article <Nov.10.16.35.31.1990.21217@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >It turned down the idea because I didn't want to waste the memory; >other programs could use that memory when I'm not using it. The >phrase I invented to describe the technique was that the program "made >it's own sandbox so that it could ignore the others". I thought it >that if I wrote a program that did this people would accuse the >technique of being a holdover from the C-64 mentality. "If I can't >have the whole machine, I'll just make my own mini-machine and stay >within it." >ASDG's technique has similar qualities but is one step closer to >"making your own sandbox" because it's a contiguous block (or "box"?). >Now I understand how ASDG makes their software so reliable. :-) >This all confuses me because ASDG is the one company that I've never >seen have a C-64 mentality. Maybe I'm off the wall and this is an >accepted technique that everyone uses. Tom's analogy to ``making your own sandbox'' is a good one. In fact, to use his metaphore it would be more accurate to liken TAD's actions to ``making its own construction site''. This is because TAD is constantly reorganizing its pre-allocated memory in ways to best optimize performance for a given image type and size. The reason we made the allocation in one large block was not to ease our programming effort, but rather, to make somethings possible which would not have been possible without our total control over our own memory. Memory bounds and borders within our pre-allocated area are free to shift at will (under our program's control). This freedom has allowed us to make some optimizations which boost performance of some operations by as much as a factor of 10. >could deallocate everything easier. The former would completely avoid >the "out-of-memory crashes" that people complain about. This is another concern. TAD (and even more so, ADPro) are dynamic in nature. It would be very rude to interrupt the user in the middle of a sequence of steps with an out of memory message. While you can still run out of memory while using TAD or ADPro, these occasions are much fewer and more gracefully handled as a result of our choices in memory architecture. Our memory usage is really predicated on the immutable law of computing, that of the trade-off between time and space. TAD and ADPro are optimized for time (performance), the one resource which is sometimes priceless. -- 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) (11/26/90)
In article <5652@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >In-Reply-To: message from perry@madnix.UUCP > > >You brought up something I was interested in. Working with a larger file on >disk. > >Even if you can't now, do you think TAD will ever let you work with images >that would be just to large for RAM. Like some scanned in photos for a >magazine spread or something, where they're sometimes 200MB or more? Actually, we have been working on a uniform and transparent virtual memory model (program specific, not system wide) for more than a year. This work will see its first commercial release in our Dupont 4Cast driver module for ADPro. A print made with the Dupont 4Cast may consume as much as 80MBytes of data so VM was essential. Because we had been working on this aspect for over a year, implementing the 4Cast driver was not as laborious as people on other platforms have found it. With the passage of time, and more work, some future software will employ still greater levels of VM integration. So far we have achieved our goals of designing an extremely flexible VM architecture which impacts performance as little as possible. Some performance hit is unavoidable though, with the conflict between time and space being what it is and all that. But, you know, being able to manipulate massive images is a mixed blessing. Sure, it is nice to be able to do it. But consider that each of the possibly hundreds of millions of pixels needs at least a little attention from the CPU during processing. Doing anything hundreds of millions of times takes time. Doing something hundreds of millions of times from disk, takes a little more time. So while VM gives you the ability to work with massive images, you may find practical reasons why you wouldn't want to. Currently, TAD and ADPro give you the fastest image processing available on the Amiga. Some of our speed advantage is attributable to being RAM-based. But, most of our speed advantage comes from coding. For example, its our coding that allows ADPro's PostScript saver to convert an image to PostScript as much as 100 times faster than ProPage. Summary: VM is great, its coming, but RAM prices are dropping more quickly than faster CPU boards (which make using massive images practical) are becoming available. 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