jimomura@lsuc.UUCP (Jim Omura) (11/24/87)
This is partially in response to mail I've received recently
and partially to "set the record straight".
First, the way it all started was like this:
I've been using the CoCo3 for some time now, pretty much
restricted to OS-9 usage generally. I also started using the Atari
1040ST over a year ago. I got involved with some art programs
on the ST and liked them. Early on I bought Jim Kent's Aegis
Animator, which was my first taste of computer generated animation.
At least it was my first attempt at producing any. I also had
Neochrome and Degas and Degas Elite.
With the arrival of Degas Elite by Tom Hudson, Jim Kent
realized the potential for animation on a page/frame image
basis. This lead to Flicker. Now, while Jim was working on
Flicker, I started helping him via beta testing. This gave
me a steady stream of state of the art pieces of graphics
software and Jim evolved Flicker into CyberPaint. During this
time, Tom came up with Delta file animation for the ST and
Jim used some ideas from Delta files and rethought the .SEQ
format for CyberPaint, yielding the highest compression ratio
of any graphics format on the ST. He later took these ideas
and came up with RIFF format on the Amiga.
Although I've never torn down the .SEQ compressed, .DLT
and RIFF formats, I know the basic theories behind them, and
I've done some programming with Degas Elite formats, so I had
a fairly good idea of how they worked. I was, from early on
in the Flicker development interested in porting Flicker to
the CoCo3 under OS-9. Jim Kent and I have discussed it and
he allowed me to use his Flicker design screen format and
user interface for an art program, vaguely defined. Possibly,
if he has time he may port Cyberpaint to the CoCo3 yet.
He's very busy though, so don't hold your breath.
Ok. As I've said, I prefer standards. So, why did I
look for another format? Clearly I could have started with
an ST graphics format or Amiga graphics format right from the
start. Well, I *knew* that eventually I'd want to do page
based animation like CyberPaint. Could the 6809 handle the
unscrambling of the .SEQ format or RIFF format fast enough?
Most likely not, but even if it can, I'd like something faster
to leave the possibility of running concurrent processes in
the background. We need something closer to the CoCo3 hardware
than the Amiga and ST formats.
So, there it was. I wanted a CoCo3
format. The question then was whether there was a good CoCo3
format which could be adapted to animation and was fairly
standard. Answer: no. At least nothing public domain, or
otherwise available to me. So, that's how it all started.
This implies a few things. First, although it's somewhat
generalized, it's mainly designed to be fast on the CoCo3.
If you want to run a .GF9 animation file on an ST or Amiga,
I expect those machines are fast enough that they may even
be able to convert them on the fly.
Second, although I've left some room for users of Commodore 64
or Atari XE 8 bit machines to *extend* this format to their usage,
it would likely not be possible to use most of the CoCo3 formats
by unpacking them on-the-fly, let alone converting on the fly.
About the 1/64th time gradation, I it arises like this:
The CoCo had 1/10 sec. ticks. The CoCo3 has 1/60 sec. ticks.
OS-9 68000 is generally used with 1/60 or 1/100 sec. ticks.
In otherwords, tickrates can't be counted on to work out
evenly for 1/60 sec. field rates (North American TV) or
the 1/50 sec. European field rate. There not being a good
"magic" number possible from that point of view, I decided to
look at it from the programming viewpoint. 1/64 is finer
gradation than the CoCo3 can be expected to produce. That's
typical of my designs. It means that someday really excellent
equipment may surpass what I have and make use of the format
spec.'s capabilities. In fact, I expect that 16 frames per
second is the limit of speed more likely to be useful. So,
that being a multiple of 1/64, it works out pretty well.
Furthermore, working in binary with a 1/64 based time system
might be cleaner when you mix variable duration frames.
Besides that, I noted in the spec that the timing is *not*
to be assumed accurate. Being an interrupt based multi-tasking
system, frames may not occur precisely ontime. A separate
"rendez vous" system may be added later for more precise synching
at certain points. So, you can think of the framerate as 1/60
sec. and work with that presumption. As far as I'm concerned,
it's not wrong.
Anyway, I'll be posting a new revision shortly. I won't
be posting many more. I'll develop it just a bit more and then
stop for now freezing what I'll have done, until someone asks
for further changes. Many of the ideas I have right now are,
as you may have guessed, taken from Jim Kent's work, but with
some of my own thinking as well.
Cheers! -- Jim O.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura