#Gasp! ANIM speed
30 messages in this thread
Aargh!
I just completed my second Imagine animation, this time using a moving
camera. Everything got rendered at 704 X 440, converted down to 352 X 220
HAM-E format (to get some anti-aliasing in there), the ANIM was compiled,
and then…
The whole thing ran at 3.8 frames/second. On a 25 MHz A3000. With static
column RAM. I could scream. I PAID $7,000 FOR THIS?
Anyway, what do I do now? Now don't sweet-talk me into getting rid of
the graduated background to speed things up. I have a 24-bit renderer, an
18-bit graphics add-on, and by golly I'm going to show them off. The
solution as I see it is to do away with all this compression stuff and go
with an animation program that will flip between uncompressed images as
fast as the 68030 can go. Damn the torpedoes, full steam ahead, and let's
buy some more RAM!
Does PageFlipper+F/X work this way? Is there a PD program that will do
the same? At 352 X 220 and 4 bitplanes, I figure my 25-frame animation will
fit comfortably into my machine.
Blaq! – via Whap!
Blaq!'
The best and most painful way is to rent a single-Frame controller 🙂
What is the final format of your anim? You might want to download
CRYOUTILS.lzh. It has a nice collection of anim utilities. DPIII will let
You torpedo ahead with non compression, but You'll have to feed it a format
it likes. At least this will give you an idea how big is big and how fast
is fast…huh? Pageflipper+F/X will do a bit better than "Makeanim" (from
CRYOUTILS"), but "jp" is the expert on that, maybe he'll see this and
comment….. Hi John.
Good luck,
Paul
–pt–not seattle– 😉
Charles, sorry to bear bad news, but…. since you are in HAM-E mode, your
352×220 images are actually 704×220 to the system (remember?)…. so in
uncompressed format you have: 704×220 = 154,880 pixels / 8 (bytes) * 4
(bitplanes) = 77,440 RAM per image * 25 frames = 1,936,000 RAM needed for
uncompressed page flipping.
So, with a 1meg chip ram machine, you can store about 10 frames or so in
chip ram buffers for page flipping. With a 2meg chip ram machine you might
be able to store 22-25 frames, depending on other uses, fragmentation, etc.
The Director will allow you to allocate these buffers, and page flip them
*real fast* for you, if you can get them in chip ram. Unfortunately not
even the Director is very swift are page flipping when the buffers are in
Fast ram (about 4 fps with above image sizes). 🙁
Like Paul suggested, you might try DPaint in its uncompressed anim mode;
what speed difference do you see?
PageFlipper PF/X will not do uncompressed anims, but is about 10-25% faster
than regular anims, at a cost in size. (wow! You could get 4.75 fps!)
There is a shareware anim player called TIV in the BlackBelt library in
AmigaVendor that purports to play regular anims faster than ShowAnim,
etc….
Other misc thoughts: did you lock the palette when rendering to HAM-E
mode? Do you *need* overscan? (the same images above without oscan are
only 64,000 bytes, a 21% savings) All-in-all, you are faced with
comprimises. Are you *sure* you don't want to give away your graduated
background? 🙂 –jp–seattle–
John,
I don't care much about memory; I'm pricing RAM even as we speak. It
just seems to me that a mighty 25 MHz 68030 should be able to move 77K from
Fast to Chip RAM in an instant, no? (Quick, you assembly language types —
how fast is the 68030's block move?) I just can't accept being stuck at
3.8-4.75 frames/second! I don't care what people say about picking up a
used 3/4" pro VCR and a budget single-frame controller. I could justify
buying the A3000, but I can't justify the single-frame stuff, not even to
myself. I honestly think the solution is block-moving uncompressed frames
from Chip RAM, which can hold as much as 16 Meg.
I can't very well lock the palette; I'm using a Globals-created world
where +zenith is dark blue, the horizon is white and -zenith is orange. The
camera flies around in a graceful "p" shape, which means the background
goes through all sorts of colors. Locking the pallette would be great for a
fixed camera, though: I may re-render my Channel 9 animation to see how
much it would improve. And even if I didn't need overscan now, I'll have to
live with it once I create something meant to be sold, so I might as well
get used to it.
P.S. regarding locking the palette, methinks a good way to get a
representative palette is to use ip to create a composite image taken from
representative frames of your animation, using "stretch to clip" to shrink
the frames and "merge" to paste them onto a single screen. The palette
created from this screen will represent your animation as a whole much
better than one created from any single frame, right?
Blaq! – via Whap!
I'm not sure how fast a 25mhz 68030 can move data from Fast ram to Chip
ram. Let's say you want 15fps (a very acceptable speed, in my opinion).
That would mean it would need to move 1,155,000 bytes per second, in
addition to whatever else it is doing.
Remember that Chip ram is 'slow' ram, in that it cannot be accessed by the
68030 every cycle; it is locked out for the custom chips to do their thing
from time to time; maybe that is one limitation? On the A2000 it is also
only 16bit ram, while your Fast ram is likely 32bit, correct? Can a
A2000/25mhz/68030 do over 1mill bytes/second from Fast to Chip, in a real
world situation like an anim?
Here's an area where an A3000 *may* actually help. I understand that the
A3000 Chip ram is actually 32bit ram as far as the 68030 is concerned (but
accessed at 16bits for the custom chips). This would mean that the data
the processor is moving (the Fast to Chip situation) would be moved in
32bit hunks, improving performance 2X? Hmmmm…. I might go down to my
local dealer and give that a shot later today on their A3000. If so it
would speak well for A3000 anim capabilities over the A2000/68030.
–jp–seattle–
Actually, (I may be wrong on this, not having the A3000 specs) I would
expect you could copy to Chip ram possibly as much as *four* times faster
on an A3000 in Hires 4 bitplane mode, which is what we're talking about.
The reasoning goes this way: The A3000 has 32 bit wide Chip ram. Thus,
both the Custom Chips *and* the 68030 is accessing it in chunks twice as
large as an A2000. This not only means the 68030 can do things twice as
fast, but also means the Custom Chips will be reading their data twice as
fast, thus eliminating a lot of the extra contention which you get in Hires
4 bitplane mode (maybe even all of it). Since this results in a loss of
about 50% of the available chip ram cycles on an A2000, take that extra 50%
for processor access as well, you get roughly a 4 times improvement on
speed. Given that, it seems probable that you could transfer upwards of 1
Megabyte into chip ram per second using the 68030, which would be roughly
your 15 fps. Now all you need is a program which plays an anim *that* way.
<grin>
–>Steve Bennett
Steve, While the Chip ram in the A3000 is on the 32bit bus, my
understanding was that the custom chips still only accessed it via 16bit,
so that you would not get the 4X improvement that you mentioned. The Chip
ram is accessible to the processor (68030) however as 32bit, so you
would/might get a 2X improvement. Make sense?
My dealer was closed today. I'm gonna try again on Saturday and do a time
test or two to see if what we are saying is true or not. Will let you
know.
–jp–seattle–
Ah. If that's the case then you're right, I'd only expect to see a twofold
increase in that speed. It's a pity Commodore didn't change the custom
chips to access chip memory in 32 bit gulps, however, or put some kind of
interface between them and the chip memory to do so. (Basically a single
word cache, so that when the graphics chips access two sequential 16 bit
words the interface circuitry can handle it as a single 32 bit access.) It
seems to me that the added circuitry would be relatively minor to add in.
(I know, I know, relative to *what? <grin>)
–>Steve Bennett
You're not the first to wish that! Looks like we'll have to wait for a
redesign of the custom chips and display hardware to get real graphic
thoughput.
–jp–seattle–
Steve,
the graphics chips' data path in the A3000 is still 16 bits wide.
Blaq! – via Whap!
John,
in the Siggraph "Amiga day" videotape, one of the segments shows Brad
Schenck demonstrating a real-time animation on DCTV. He does mention that
the 3000's 32-bit RAM makes things much smoother than the 2000's 16-bit
RAM.
Blaq! – via Whap!
Charles, Given the description of your anim, I sympathize with your
attempts to achieve reasonable frame rates. A recent anim I worked on
(Snoqualmie flyby) was similar in that *a lot* was changing each frame.
Taking it to HAM-E mode I couldn't get frame rates above 2-3/second. I
somewhat solved the problem by shrinking the anim to about 1/2 screen, and
putting it all inside a picture frame, thereby getting about 1/2 the screen
static the entire time. This pushed my frame rate up to about 10/second;
helped, but certainly not what I want to do each time.
HAM-E poses special animation problems (as does DCTV, etc), in that each
pixel we see is actually two pixels on the standard amiga screen. That
makes anim compression really suffer, since if *anything* changes from one
frame to the next you can get all sorts of changes occurring (particularly
with HAM-E HAME mode).
Your thought on getting an optimised palette is a good one. I'll have to
give it a try next time.
Last thought. If you do decide to re-render any of your anim, where the
background is a bit more stable; render the background *seperate* from the
action. Then render your foreground action (all the 'objects', so to
speak) against a black background. You can later composite them in
IP/ADPro. When rendering to HAM-E modes with a locked palette later, the
areas of the background will be the *same*, so will compress better.
Good luck. I don't want to go single frame either, but see the writing on
the wall. Hmmmm. Maybe that $15,000 WORM laser-disk player that Daniel
Wolf was talking about? 🙂 –jp–seattle–
Unless my math is wrong, each full frame (both fields in your 440-line
anim) (30 fps max) is over 150K of data.
Now, most programs create anims whose data are only moved _one_ byte at a
time into chipram… which in the video mode you're using (hires, all
planes, overscan) allows only about 20K-changes per frame-time. Assuming
massive changes are taking place (and it sounds like it), that gives your
3.8 fps.
However, an A3000 can theoretically move 80K/frame in the same mode (by
moving 4-bytes at a time), allowing up to 15fps. So your idea of either
using a different anim format, or copying from chipram, are good ones. You
could quadruple your rate. – kev
Kevin,
the original Imagine renders are 704 X 440. However, in IP I convert
them to 352 X 220, not 440. Since movement hides so many problems, I feel
I'm better off with double the frame rate at the expense of vertical
resolution. And of course there's nothing stopping me from replacing the
final freeze frame with a separate, hi-res image.
The whole idea of moving uncompressed frames seems (a) so simple, and
(b) so fast that I'm surprised nobody's bothered to come up with a program
so far.
Blaq! – via Whap!
Charles, re being surprised that nobody's bothered to come up with a
'moving uncompressed frames' mode of animation. There are people who have
come up with page flipping by copying/displaying from Fast ram to Chip ram.
The Director, for instance. However, the xfer rate is just not up to your
speed standards (for hires/overscan pics, at least).
As mentioned here before, several of us theorize that the major stumbling
block is the Chip ram contention from the custom chips. And the larger
your amiga screen being displayed (and remember that your HAM-E images are
actually 704×220 to the Amiga system) the more Chip ram contention you are
gonna have. So, not only are you trying to move a large amount of data per
second ( >1meg ), but the custom chips are locking out Chip ram a fair
amount of the time.
If your anim will fit (uncompressed) in under 2meg, then I'd recommend
getting the SuperFat (2meg) Agnus and addon board (forgot name) that allows
use in the A2000. Then, using the Director you can *really* fly by page
flipping (I mean blurring fast) by just pointing to different Chip ram
buffers each time. I've done several anims where I put the 10-15 most
changing images of the anim in Chip ram buffers, and stick the remainder in
a compressed anim form, and just chain it all together via the Director.
Good luck.
–jp–seattle–
John,
good news — I already have the 2Meg Agnus! (gotta 3000, remember) One
thing I've always wondered about is filling Chip RAM with the beginning of
my animation and Fast RAM with the next frames, then starting the
animation. As Chip RAM frames are displayed, I can copy over them as soon
as the screen address has moved on; when all Chip RAM has been shown, I
already have some new frames in Chip RAM waiting to be displayed. Since the
processor (we all assume by now) is slower at moving memory than we want,
the screen pointer will eventually catch up with it, but by re-using
"already displayed" frames we can certainly buy time and show sequences
longer than would fit into 2 megs. (By the way — are you using an
accelerated machine or a stock 2000? My 3000 would give much better
performance)
Again, I'm surprised though — am I really the first Amiga user with
that much ambition? Hasn't anyone else wanted to get MUCH closer to
real-time animation like we see on TV all the time? I'll give the Right
Answers Group a call this week and see if I can talk with a techy person.
Blaq! – via Whap!
I'd bet that there were a few who have tried to achieve 'real-time'
performance animation on the Amiga before this (me, for instance) 🙂 …
but have always run up against the same old roadblocks…. amount of change
and image size vs. S->P->E–>E—>D—->.
That is why most people use the lores screens for anims; the same changes
per frame take up less room than the same thing in hires, hence the
speed/size improves. Fast hires animation is possible, but it's not easy.
nd HAM-E is deceiving, since *you* are thinking 320 horizontal, but the
amiga is thinking 640 horizontal. Just not possible to have a lores HAM-E
animation, I'm afraid. Between the hires screen of HAM-E, the more colors,
and how it encodes those colors you've gotta a processing nightmare for the
machine.
Best of luck with your anim. Upload?
–jp–seattle–
John,
I don't really think an upload is warranted. The thing is big and not
that spectacular anyway. If you really want, I could mail you the objects
and staging file so you can recreate the scene; my favorite part is the way
the sky color changes as the camera flies around.
I'll post some news about my phone call to the Right Answers Group.
Blaq! – via Whap!
John,
I was on the phone with Keith from Right Answers today — boy is the guy
talkative! Now I know why it took me all day to get through B^D
Anyway, we did a test on his 3000 right over the phone. He moved a
hi-res picture from Fast RAM to Chip 100 times. The process took 28
seconds, which is darn close to the 3.8 frames/second I got using ANIM!
However, it turned out he was moving true hi-res frames, i.e. hi-res on
both directions — 352 by 440. This means twice the frame rate at vertical
resolutions of 220. In addition, he has both 32- and 16-bit memory in his
machine, so we can't tell for sure if the source frame was coming out of
32-bit wide RAM or not. If it was in 16-bit wide RAM, then speed on my
machine (100% Static Column 32-bit RAM) would be higher again, although not
by a factor of two. (Source would be twice as fast, but destination would
be just as slow –> Chip RAM)
I take it to mean that I can move at least 8 frames/second into Chip
RAM. That's getting more acceptable. I also like the control I'd get with
The Director, for example blitting quarter-frame sized images into a
picture frame or TV screen. This is what you're doing right now, actually.
I'll be ordering The Director 2.0 this week.
Blaq! – via Whap!
The frame rate he/you were getting is about exactly what I was getting on
my A2500, with 704×220 pics. You did tell him to move HIRES (704) didn't
you? (you typed 352)
Since we're all getting about the same rate, I'd suspect that we are
hitting the Chip ram contention barrier, and hence there isn't going to be
much more improvement in this area for now (using this technique). Worth
giving it a shot though.
Just remember that you'll only move data as fast as your SLOWEST link, and
if that link is the Chip ram contention barrier, then all the effort in
other areas just won't show up. Please post when you get everything
optimized. I wish you best luck. TTFN
–jp–seattle–
Charles, another note. Check out message # 27981 in AmigaUser, from Kevin
Darling to Kelly Jordan. In it Kevin explains the exact limitations on the
Chip ram contention, hires, lores, etc…. you might find it illuminating.
TTFN
–jp–seattle–
Charles;
Now you have some idea of why Brad put " Keith Doyle … above and beyond
the call of duty," into the credits for one of his animations.
An Amiga message processed by Whap!,
bill
I whould assume that after reading all these messages on this anim speed
thing that these anims are planing to go to video tape in the end if so I
have a sugestion that may help…. Layer the animation … just like the
first part sugestion of getting rid of the background … do the animation
in parts ie background set to 15 f/s then forground using a good genlock
record the background first then record the forground over it. Timing is
the biggest problem with this technich the background is normaly
Fred E.
Charles;
If you talk with Keith Doyle, you will be in for a pleasent experience. He
is one very sharp individual!
An Amiga message processed by Whap!,
bill
Oh, it's not just theory that 704x220x4 planes gives chip ram contention
🙂
In that mode, 65% of the original open cpu slots are used up, and 75% of
all blitter slots are unavailable (or thereabouts).
As everyone's been saying, chip ram access is the big blockage to doing
really heavy stuff on the Amiga. The 4-byte-wide access on the A3000 is
only a stop-gap measure… hopefully next year we'll see some new chips.
Thanks for the exact number verification, Kevin.
And even that 4-byte-wide access to Chip ram on the A3000 is limited to
just the processor right now….. no wonder things don't get done so fast
🙂
–jp–seattle–
John,
I would only put the A3000's Chip RAM access rates at a POSSIBLE 2x of an
A500/2000. I do not recall seeing any ANIM format (or player) that
instructs the CPU to write more than 16 bits at a time to Chip RAM. Given
that large frame-to-frame changes are where ANIMs needs 32-bit access most,
it would make sense if Aegis, for instance, extended the ANIM standard with
a 32-bit variant for use on the A3000. This will enable the machine to more
fully live up to it's playback potential.
I think you are absolutely right. It would be very nice if someone came up
with an anim player optimized for the 32bit processor/chip ram access of
the A3000. Any other speed enhancements are well, of course 🙂
–jp–seattle–
Charles,
If the output is going to HAM-E, then the frames are 704x220x4 for a
352×220 HAM-E picture. There is a fair amount of competition for the chip
bus at that resolution.
I don't have the HAM-E, or do animations, but it sounds like you should get
better results page-flipping instead of doing de-compression on the fly.
How frames/second are you aiming for? at 704x220x4, each frame is 77,440
bytes long, and your 25 frames would be a total of 1,936,000 bytes. With
the 68030 having 32 bit access to the chip ram, you should be able to fly
page flipping from ram. Heck, if you weren't doing de-compression, you
should get more frames/second from a good hard drive.
Have fun!
73, Kelly
I would like to point out that your image is eqivalent to 352x220x8
bitplanes it IS in fact, a 704x220x4 bitplane image as far as the Amiga is
concerned.