Dual Ranges??
36 messages in this thread
Downloaded 6.3 from here today (finally got this pass straightened
out – long boring story). Anyway, what *DID* you have in mind with these
dual ranges. The effects I'm getting are very unusual and spectacular but
can't seem to find "dual ranges" in my Imagemaster manual :*). I
particularly like dual warped ranges but am not understanding what they do
when I blend them into other areas – at an unblended state, they "carve"
the area and leave weird interesting lines. When using the blend
percentages and the edge percentage blending they behave as I expect. Very
very nice with the flood fill (of which I do not understand either). The
manual is pretty complete but when I start putting one effect upon another
I get lost. Howabout a "freeze panel" so when I reload an image I can have
my old settings where they were? Just a thought.
Which panels would you like "frozen"? I think the suggestion is good, but
it needs to be more detailed.
The dual ranges, of course, aren't in the manual. They *are* in the new
addendum, which you'll be receiving soon. By the way, we added some NEw
range stuff on top of the dual ranges… we just finished implementing
"Poly-Ranges". Poly ranges take the colors in your range, put one at each
vertex of a polygon, rect, screen, or – they "spot" the colors around the
circumference of a freehand or elliptical region – and then the spread from
one to another in MANY directions at once. Best to use only a few colors,
or the computation gets unbelieveably long. You can use 256 if you want,
but that takes *forever*.
You know the color triangle? You can make that with a three color range of
red, green and blue; set poly range, smooth range, and draw a triangle.
Bingo. :^)
Anyway, we'll have that up this week, I think. Looks like IP 6.4 will have
a large number of bug fixes, too. :^( At least they're fixed. :^)
Ben
Hope I can explain this. Well I'd like to have my Blends frozen, ranges
frozen, what is in the palette, previous region and the panels in fill
modalities and line modalities, current brush. Maybe this is too much, just
want a snapshot of the panels even if the data isn't around anymore. So I
have something to work with. So if I say to you I'm using 75% edge blended
transparency horizontal dual range warp you'll know what I mean. I think
you do anyway but *I* can't remember all of that from picture to picture.
Is there anyway Ham-E hardwar-wise could assist screen redraw? I
know, go buy a 3000 and stuff a '40 in there. Well, in the awful PC world
they appear to have hardware screen redraw assistance. Not cheap though and
looks like afterthought hardware anyway. But is there a way?
Margaret, to "freeze" blends, and the palette, simply save a file called
"Default.ipb" from the blend panel, and a corresponding default palette
file from the palette screen. The paint modes and so on, I get you. I'll
talk to Barry about it.
Accelleration – yep, an actual accellerator is the way to go. Do you still
have a 500? If so, I think there are few means open to you. If you have a
2000, yes, buy an accellerator. It's more than worth it, and you'll thank
yourself for weeks (even if you're not able to eat :^)
Ben
I spent some time at the last Amiga show chewing the fat with the CSA guy
miget whatever. Still not too clear as to what would get me by. To assist
the screen display he said I'd see drastic(?) improvements with the '30, no
MMU and no math chip. When I ran into my Amiga user group Gurus – they said
that I would not be happy unless I had the 32bit wide Ram – they panned the
static Ram. (Yeah lady, go buy a 3000). I am hoping that the '40's will
push the price down on the '30's and I can pick up the accelerator used.
Then I have to get 2.0 in here. Oh well you can't win at this game, I just
have to buy it piece by piece. There is only so much tofu my kids are
willing to eat.
The optimum configuration for the CSA Mega Midget Racer is to get a 030
with the MMU option, and some 32-bit RAM. (Not static ram). A almost
identical situation would be to tget the 030 without MMU, but get teh
Static RAM, and some 32-bit RAM. The thing that will give you a dramatic
increase in visible speed is moving your system ROM into 32-bit wide RAM.
With a MMU you can do it with the SETCPU program; without the MMU you need
to get Static RAM and CSA's board will do it for you. Static RAM is more
expensive that normal RAM. My board configured with 4 megs of 32 bit ram,
25mhz 030, 25mhz 882 cost me $1799.00 about a year ago.
But why on earth would I want System stuff in ROM while I'm running IP.
Does IP ask for that much system stuff. I just want the display to draw
down more quickly. What would MMU do for me? How much 32bit wide Ram would
get me where I want to be in terms of manipulating images 640X480 max most
of the time. I gather that when you "run out" of the 32bit wide Ram that
your Amiga goes looking for the 16bit RAM. What is the threshold? Believe
me I've gotten about 10 different opinions here – still confused. exit
Margaret – you do NOT need to have the system ROM remapped into the 32 bit
ram when you're running IP; performance improvements will occur when the
panels are being created for you, but that's about it. The other effect it
will have is lose you 512k of memory, which is not a worthy tradeoff in my
estimation. FYI, I *never* put the system ROM in the RAM; I use that ram
for images and etc. MY system screams.
Ben
What kind of system are you running? If it is a 3000, I can see why you
may not need to push the system ROM into RAM. But, on my 500 I see a
dramatic increase in screen re-writes (In both IP, and just plain
Workbench, and ANY application I run such as Impulse's Imagine [the hires
screen updates considerably faster with system ROM in RAM as opposed to not
having it that way]). I think it is well worth the 512K of lost 32-bit
RAM. On the CSA system, you can purchase Static RAM for this purpose – that
way you will not essentially be eating up your Fast RAM, and you do not
need SETCPU to perform this function. (The board is setup to do it
automatically if you have Static RAM).
I'm running a 2500/030. And you do NOT see any kind of performance speedup
when IP redraws, for the simple reason that (a) we don't use the system
routines to access the screen, and (b) when you put the ROM into RAM, you
just chewed up 512k bytes of what IP *could* have used to put images and
it's other data structures into.
I I'm sure you see speedups on the WB; and that's fine. My WB is fast
enough to suit me (I have run fastrom, and aside from the problems it
causes, it does speed things up on the WB and etc) But for optimum IP or IM
operation, fastrom should NOT be used unless you have more 32 bit ram than
you'll ever need.
Ben
Depending on how Black Belt writes to the screen, the speed up in IP could
be great, or virtually -0-. I think what Joe meant my 'system' (OS) speed
ups were things like menus, window moving, requestors, etc… moving the OS
into 32bit ram makes them much faster; like driving a ferrari in
responsiveness rather than a tank. 🙂
If IP uses the OS routines to redraw the screen, then moving it to 32bit
ram would speed things up considerably. But I doubt they do. Most 'high
performance' software seems to write to the screen directly, bypassing the
OS routines. That means that moving the OS to 32bit ram will not have much
(if any) effect. I'd bet Ben will chime in here with a response 🙂
The MMU is responsible for relocating the 'system' OS stuf into the 32bit
ram, fom the 16bit regular rom. That's why you need the 68030, the MMU,
and the 32bit ram.
I have an 030 accelerator, with plenty of 32bit ram. Also have 2meg of
16bit ram (chip). To optimize IP and HAM-E, I would think you'd want
basically what Joe has, the 68030 with MMU, and four meg of 32bit ram. That
way your system would have five meg total (incl your 1meg chip?). More than
fast and space enough for most IP operations, even on hires images with a
couple buffers.
Of course the 040's out now seem to be blowing the 030's away in terms of
performance! The image calculations would sure be FAST, I'd bet!
–jp–seattle–
Whoa wait a minute, this thread is getting more turgid by the moment. Now
if screen redraws aren't helped by having the OS in the 32bit ram, then why
in the devil would I need the MMU? Never could understand why I'd need the
MMU anyway. The CSA salesguy told me I would not need the MMU unless I
wanted to install UNIX. Don't think I'm ready for a multitasking
environment, lex and yaack (yuk?) and all that stuff yet on my 500. So to
recap, the '30 would make the mice run faster and if I had the 32bit wide
Ram, my images would move faster, don't need a math chip if I avoid
ray-tracing and CAD. Not sure about the static Ram.
It seems as if all you want a 030 for is speedier IP operations, then you
do not need the MMU. According to Ben, IP does not use standard OS calls
for their screen IO therefore using the MMU to push ROM into 32-bit ROM
will not be benefitial, and you'd be better off using that extra 512K as
Fastram. I use my MMU with SETCPU to speed up my workbench, and programs
such as Pagestream's screen I/O, Imagine, etc.
Since the CSA MMR is a modular system, you can get one without the MMU and
then always add on to it in the future. Of course you can not add a MMU to
a non MMU 030, but on the CSA board you can add Static RAM and utilize its
built in circuitry to push system ROM into 32-bit RAM if you so desire that
need in the future.
Thanks for the information.
The reason you want the system ROM in 32-bit fast RAM is that it will
increase your screen performance dramatically! Your normal screen IO is
being handled with ROM running at 16-bit speeds; that redirected to 32-bit
FAST RAM will turbo charge your display. I was shocked at the difference
in screen updates.
I would suggest 4 megs of 32-bit RAM, that will give you enuf to work with
most images at 640X480 max (there are some that are too large, mainly due
to large amounts of colors), and leave you some space to push your system
ROM into RAM for that extra performance boost.
I'm not sure, but I believe on the CSA board you can only have it config
with either 2, 4, or 8 megs of RAM. 2 megs of RAM is fine, only if you
have conventional memory available to you (ie: another memory card). Most
folks don't, therefore I'd recomend 4 megs. You should really buy as much
memory as you can afford. (And as large a hard drive as you can afford).
When talking about memory, accellerators, etc you're bound to get differing
stories. That's because different people have different applications, and
desires in mind (and some may have other motives in mind, ie: a sales
commission if your talking to a salesman).
What is it that you are confused about? Is it getting so much memory?
Whether or not to get a MMU 030 or a 030 without a MMU (Shall I call it a
030SX :->)? Or getting the CSA board as opposed to an alternate solution.
Whoa. Whoa! <grin>
A 24 bit iamge can have any amount of colors. It takes 4*X*Y to hold the
image, and 7*X*Y to hold the iamge *and* the undo buffer (very important,
IMHO). The number of colors has NO bearing on how IP or IM handle them, nor
the amount of memory they take. Period.
We don't use the system ROM routines to write to the main image screen.
Ever. So you see NO speedup from putting the ROM image in ram for
redrawing.
You do see speedups in the WB and other s/w, also in things like our gadget
panel generation, which uses ROM routines extensively – but not the image
operations.
Here's a hint for you, though – there's a utility (somewhere) that can move
your system stack from the 16 bit ram to the 32 bit ram. It's called "VBR"
and I got it from CIS at some point. *This* helps everything, bar none.
Ben
VBR – (Vector Base Register) – moves the vector table to fast ram, not the
system stack.
MoveSSP – (Move System Stack Ponter) – moves the system stack to fast ram,
unless you have 2 MB chip ram, because it thinks the second MB of chip ram
is fast ram, so figures SSP is already in fast ram. Have to find this
sucker again and see if it has the source code so it can be fixed!
73, Kelly
Ooops. :^)
Kelly, you're saying that I should not use MoveSSP if I have a 2meg Agnus,
is that right? I was going to find that utility after seeing it mentioned
here.
What about VBR? Does that offer any significant speedup?
Finally, on both of them, what about RELIABILITY? Any known
incompatibilities? I have a 68030 based A2000 w/2meg Agnus/8meg 32bit
fast. Anything I should look out for or NOT use? Advice? Thanks in
advance.
Perhaps my misconception occured from not being able to load various images
that have the same resolution, or let me say some images can not allocate
undo buffers; whereas, others can (all the same resolution). I assumed the
difference was in color size.
I'll check out VBR!
No – the difference has to be somewhere else. It could be with having a
local mask or not, in the latest version; or, it could be that your memory
is fragmented more one session than in another; or, it could be that other
software is running and taking more than was in use previously. Or, you
could have more buffers in use… there are lots of things that can get
you, but all images of a particular resolution take the same amount of
memory, regardless of the number of colors.
Ben
So well put. :^)
You will see some pretty drastic improvements with an in-system 030,
though. The midget racer will surely help a lot. Although some 32 bit ram
is a VERY good idea, just the CPU will definitely help.
Ben
Prob is that because the 32 bit ram goes on another board that CSA
supplies, you pay extra for that then you have to horsetrade for the ram.
I'm not sure how they work the static ram but I think it comes with 512K
and you can add more right there.
I have a 500, and the CSA 030 board with 4 megs of 32-bit RAM. The board
works perfectly on my 500 and performance is wonderful! If you have a 500
I'd highly suggest the CSA products!
hey… resend this to Margaret Copeland. I think she needs to hear such
goodness.
Ben
Never mind – I saw you did talk to her
Ben
Oh yeah – you can also save ranges. :^) Default.rng (I think – chk the
manual) will cause a range set to be automatically loaded when you start.
Ben
I save lots of ranges to their own directory and load them up. I can
certainly save and load blends. What I want is a "snapshot" of the way I
have the whole mess set up.
Ok. We'll discuss the way to approach it here, and see what we can dig up.
We're currently putting the co-ordinates in, so be nice. :^)
Ben
I'm always nice. Go Barry go…
Margaret, a suggestion: you have ARexx, right? If so, you could work up a
macro that would automatically save whatever you wanted under one 'name',
whatever that was savable via ARexx, at least.
For instance, after starting the macro you would be asked for a dir and
file name, say "DH1:BOB", for example. The macro would then proceed to
save the main image, the palette, the blends, etc… anything that really
has a 'save xxx' command in ARexx. All would be saved to your dir, with
the name 'DH1:BOB.BLEND, DH1:BOB.24, DH1:BOB.XXX, etc'.
There would be a corresponding LOAD macro that would automatically load
these various items back into IP. As much as possible of the system setup
would be saved/restored.
Question is, is enough of the setup info available via ARexx to make this
worthwhile? I'd have to peruse the ARexx section of the manual (if I ever
get it 🙂 before I could answer that.
Finally, I'd be willing to take an initial cut at such a macro set for you,
if it sounds useful. Would be an interesting project. Just a thought….
TTFN
–jp–seattle–
Hey why don't we wait and let Black Belt make it a feature??? Lazy here.
Where did I put that AREXX manual. Surprising how many Amiga power users I
know who are learning Arexx and they are all women. Look out!
Ben,
your new Poly-ranges sound like something I meant to ask you about. Is
there a way to create an angular fill? Here's a quick description: think of
the face of a clock. If I set 12 o'clock to 100% red, 4 to 100% green and 8
to 100% blue, then any point lying on the straight line between the center
and 12 o'clock will be red. Going from the center to 1 o'clock would be
orange, 2 o'clock would be yellow and so on. You see it on many TV
identifications these days, like the CBS ads. (They are usually animated
too, where the colored disk rotates about its center)
This doesn't sound quite like Poly-range, since your description implies
that if one were to travel from the center of the filled area to its rim,
the color would vary. In my angular fill, all the pixels lying on the same
angle from the center would be the same.
Blaq! – via Whap!
What you're talking about, I *think*, is poly-range with smooth range
turned off. That produces a "pie" as you describe.
Ben