🚀 go-pugleaf

In article <jbickers.0loz@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes:
>
>> recally anyone mentioning anything about decompression from disk), but no one
>> has claimed that this can be done at 2000 frames per second, nor do I believe
>> that it is possible.
>
>     I mentioned decompression from disk, in the form of buffering the
>     data before decompressing it. The other approach, which is done
>     for some trade shows but which isn't "normal", is to read the
>     data directly into display RAM from disk, for the duration of the
>     animation. This requires a special disk format and custom code,
>     apparently.

That's a pity. Systems like Apple's QuickTime and Microsoft's Video for Windows
do it by storing their data in ordinary files--even on CD-ROM. They get most
of their speed from careful design of the compression algorithms. A Mac LC,
for example, can do 10 frames per second at 320*240 resolution, sustained,
straight from a hard disk. I have one animation (Todd Rundgren's "Theology")
that is only 160*120 in size, but plays back perfectly smoothly at 15fps,
straight off a CD-ROM.

>     As for a conventional animation working at 2000 fps - if you use
>     the OS, then yes, you'll quickly run out of frames (unless your
>     animation is a very short loop, like the spinning coin Psygnosis
>     use), because you haven't got any spare time to decompress
>     anything. :)

That's pretty much what I suspected. How long can you go for at that speed? Is
the limitation the amount of chip RAM, or total RAM?

>     If you do the double-buffering yourself, then you can pick an
>     animation that will work quickly, like a dot moving around the
>     screen... :)
>
>     BTW, do you know what's involved in double-buffering on the Mac?

Depends on which Mac. Video hardware is a bit more varied on the Mac than it
is on the Amiga. When a full-size, full-colour screen can take several
megabytes of VRAM, it can get a little expensive to provide enough for a
second buffer. This is probably the reason why there is no OS support for
double-buffering. In any case, I think the QuickTime solution is a better
general-purpose one.

Lawrence D'Oliveiro                       fone: +64-7-856-2889
Computer Services Dept                     fax: +64-7-838-4066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00