Text from Silicon Dreams
| Description: | Silicon Dreams text from Loadstar issue 192, with notes from Todd Elliot (Eyeth) on the demo and its development |
| Text: |
S I L I C O N D R E A M S
Program and Text by Todd Elliott
{FENDER'S PREMUMBLE:} Todd Elliott
emailed me SILICON DREAMS recently,
making my day and allowing those of
us with SuperCPUs to finally put some
of that extra RAM into use. It's an
animation engine with two modes: one
for playing an animation; and one for
creating an animation file from
hundreds of individual pictures. The
demo is the infamous "dancing baby".
The docs below refer to the original
file sent by Todd, one that was over
800 blocks in size. The file on this
issue (1581 version only) is half
that size. You must have a SuperCPU
to use this program. Our thanks to
Todd for addressing this niche that
needs to be filled. Those of us with
SuperCPUs love them. Now here's
Todd...
Way back in 1998, when I first
got my SuperCPU, I began to dream of
the possibilities that this little
box offered, with its directly
accessable and plentiful amounts of
RAM. Hence, the title of my latest
demo, 'Silicon Dreams'. If a piece of
silicon can dream, it would conjure
up vast amounts of numbers and the
number crunching to go with it, to
create animation sequences which were
previously thought impossible to do
on a Commodore 64.
I first set out work on a
multicolor version of the animation
player and converted an uga chaka
baby AVI commonly found on the modern
computer platforms to a usable CBM 8-
bit format. The resulting animation
ran smoothly, but there were numerous
color clashes as the stock multicolor
mode format was too limiting. Plus,
when the animation data file was
fully uncompressed into SuperRAM, it
took up nearly 2.5Mb of RAM!
Undeterred, I went to the Vintage
Computer Faire in Santa Clara, CA,
exhibited my CBM setup and displayed
the dancing baby demo nearly all day
long.
Suffice it to say that it stopped
casual observers on their tracks and
they mutter, 'Is that a c64?' or 'Is
that the dancing baby?'. Little did I
know that a reporter for the WIRED
(tm) magazine would do a
retrocomputing piece on classic and
vintage computers. He made a brutal
review of the dancing baby demo, "One
computer is playing a video of what
looks like a grainy clip of the Thing
from the Fantastic Four dancing the
frug. But I can barely make out the
infant in the jumble of crude
polygons. This is what happens when
you try to view the 21st century
through an 8-bit platform - you get a
baby that looks like it's assembled
from brick shards."
Despite the negative review, at
least I can take solace in the fact
that it was actually reviewed in a
national U.S. magazine with a
circulation of at least 475,000
copies! I continued more work on this
project and am now glad to present
you an another version of my
animation player, which can display
the dancing baby in FLI resolution,
which is like the stock multicolor
mode, but allows more color freedom.
The resulting animation looks a
little bit slower, but much more eye-
pleasing. More importantly, the
animation footprint in RAM when
uncompressed from a disk file was
just a tad under 409Kb!
Before you try out Silicon
Dreams, you need at least a SuperCPU
with a 1Mb of RAM in a SuperRAM card.
Ideally, get 16Mb of RAM for your
SuperCPU. The title screen with the
greetings will appear. Just press any
key to continue. You'll see four
options; Play Movie, Create Movie,
Help and Exit. The Help option is
currently disabled as I've had no
time or space to stash the help text
with the program. Just select Play
Movie, and use the requestor to
choose a disk device and select any
.CVF file to start loading the
animation. Look for the babycha.cvf,
which contains the dancing baby
animation and enjoy it at your
leisure. When the animation is done,
just press the space bar to exit, and
you can replay the animation w/o
loading or load in an another
animation file.
Creating animations require a
little bit more work, though. You
need MS-DOS or windows95 tools to
convert an AVI movie file into
individual BMP frames. I use Fast
Movie Processor, a windows95 tool to
break up the AVI into individual
frames with a .BMP extension. Then I
use ConGo, which is an another
windows95 tool to convert the
individual BMP's into 4bit files,
which is a native file format for
Godot, the image processor for the
c64. Fast Movie Processor and ConGo
can be found on the web using a
search engine, as their exact URLs
escape me at the moment.
Next, I zip up the 4bit files
into one archive and transport them
into my CBM system. I use Errol
Smith's UNZIP utility to extract the
4bit files into a single directory on
my CBM system, usually using my CMD
HD. With the Create Movie option of
Silicon Dreams, it will locate the
4bit files and batch convert them
into TMP's. It will load up to 127
4bit files at one time, compress them
and save them as a single file with a
.TMP extension. If you have more than
127 files, just use the Create Movie
option again on the remaining files
to create more TMP's. Next, I
transport the TMP's back to my
windows95 computer, and use gzip
utility to compress them further.
Please use only gzip, not zip. If I
have more than one .TMP file, I
concatenate them into a single file
and then gzip it up. (Note: You may
need to make sure that the resulting
single file does not exceed the
maximum memory of your SuperCPU, or
up to 16Mb.) Lastly, I transport the
gzip archive back to the CBM system,
and rename them with an extension of
.cvf and I'm in business with the
Play Movie option of Silicon Dreams
and enjoy the animation. (Note: Be
sure you can transfer it to your CBM.
It makes no sense in creating a gzip
movie file of 3Mb in size when you
can only transfer them on 1.44Mb
disks.)
Silicon Dreams, while is nearly a
fully realized piece of software, it
is still incomplete. I need to
install range checking routines, for
the inevitable movie data files that
can be too big and overrun SuperRAM.
I need to polish my disk routines,
especially for error detection, and
to allow partition switching,
subdirectory support, etc. It does
have disk and file requestors, so
it's pretty much user friendly as it
is. Lastly, this is the major reason
why it can never be fully realized;
it has no sound support. I really
would like to add the ability to
exhibit sound, dialogue and music.
But I do not know how to program the
SID, much less understand sound and
music theory in order to do this
right. I'm asking for other
Loadstarite's help. I need to know
how I can extract sound/music data
from an AVI file into a usable CBM
format, such as a WAV or a MOD, files
which have been successfully ported
over for CBM playback. If you can
help with the sound and music, let me
know through email to
eyethian`juno.com.
For those who want to know how
the animation is accomplished, let me
assure you that there's a lot going
on behind the scenes! First of all, I
settled onto the FLI mode because it
allows more color freedom at 160x200
resolution. However, the FLI mode
requires 17Kb of memory, 7Kb more
than the multicolor mode. While 7Kb
might not be much, when you add up
hundreds of frames, it can be very
significant indeed. Secondly, while
the FLI mode allows more color
freedom, it pales in comparison to a
mundane 256 color .BMP file. So, how
does Silicon Dreams do it? Trust its
larcenous heart, as it cheats on your
eyes... :)
This is where lossy techniques
comes in handy. When it comes to
graphics, lossy techniques, ones that
can lose one or more bytes of data,
is not fatal to the actual display of
the graphic. The reason is that the
human eye can discern a lot of
things, but can also overlook missing
pieces, if this is done right. This
is how JPEG works, mixing bytes until
optimum display for the human eye is
achieved, even if the decompression
missed out on several small and tiny
pieces of the graphic.
An ordinary BMP file has up to
256 different colors. When ConGo
converts it to a 4bit file, it has to
make judicious decisions in rendering
a bitmap having only a maximum of 16
colors. A lot of color information
has been lost in the conversion, but
thanks to ConGo's algorithms, it
tries its best to create and optimize
a graphic, one that is equally
pleasing to the eye at 256 colors or
16 colors. A 4bit file, having
sixteen colors, is now converted to a
FLI format. The FLI format can handle
up to sixteen colors, but only up to
a certain limit of colors in a 8x8
pixel boundary, due to the card
arrangement of the VIC-II chip. The
conversion of the 4bit file to a FLI
format will drop some colors, average
colors and render optimum colors for
a good display that the human eye can
appreciate. Once 127 frames of FLI
data has been created, the program
then compresses them using
compression similar to delta codes.
This method of compression is
lossless, unlike the previous
conversion work that was done in
changing a .BMP frame to a FLI frame.
Delta codes are used in compressing
movie files, because they only record
the differences in otherwise
identical frames. This compression
method takes advantage of the fact
that many consecutive frames are
almost identical. My program uses RLE
compression of byte zero of frame
zero, byte zero of frame one, byte
zero of frame two, and so on, until
all 17,408 bytes which make up a FLI
frame is done across 127 frames.
Hence, the dancing baby animation
only takes up a 409Kb footprint in
SuperRAM as opposed to 2.5Mb being
occupied by the multicolor version.
This means longer animations can be
loaded in and the only limit is the
available memory of up to 16Mb. The
Silicon Dreams program decompresses
the animation in real time,
decompressing a single frame at a
time and displaying them in sequence.
The real-time decompression takes up
85Kb of SuperRAM alone just for the
pointers and other compression
information. There are better ways to
decompress it real-time in less
memory, but I chose this method
because I wanted the option of having
the user replay the animation without
having to load it again from a disk
device. For a good measure, the
compressed animation data is further
compressed with the gzip algorithm so
they take up the smallest possible
footprint on disk devices.
Unfortunately, the cost has been the
high bandwidth as I had to massage up
to 34Kb per frame at 20MHz speeds,
the animation is slower than the
multicolor version. Future plans are
to reduce the bandwidth overhead and
to optimize the real-time code as to
make it the fastest as possible.
As you can imagine, with the
lossy conversion methods and the
unique compression method, this
program has been unquestionably the
most difficult to code and debug. Add
to that I had to learn 65816
architecture and its tendencies and
quirks as I went coding. But, I'm
glad I did it as I proved animations
of FLI quality can be achieved on the
SuperCPU with SuperRAM, and in the
process, learned quite a lot about
65816 coding, color optimization, and
compression methods.
I'd like to hear from you! Please
drop me a line at eyethian`juno.com
regarding the animation player, both
good or bad opinions, suggestions,
etc. I do have other .cvf files that
I can share via the means of email
attachments so that you can enjoy
more SuperCPU animations. May the
good karma generated by the dancing
baby do wonders for you and your
family and keep on computing at 8
bits...ahem, 16 bits. :)
-Todd Elliott May 5th, 2000
|
<-- Back
|
|
|
