Downloads - Categories » Graphics » Animations
Author Details Thumbnail
Name: Top fun  1999  
File: OLLY_-_Top_fun.lzx
Download: Download! No deductions from user account.
Size: 738.42 KB
Clicks this month: 0
Overall clicks: 3
Author: Olly
Author website: n/a
Alternative Download: n/a
Rating:
This download was added on Sat Apr 23, 2016 5:59 pm by AmigaDemos

Last download on Thu Feb 02, 2023 1:35 pm


Demo tested on/with: WinUAE
Requires: Amiga 1200
How the demo works: Well, more than the standard 50-60Hz scanrate isn't necessary, but it's
true.. For more details on this read the Tech.doc.


A long time ago in a galaxy far, far away.. well, more like Melbourne
Australia in early '94. It's been a long time in getting this one to the
public, but - here it is.. finally :รพ

My brother and I decided to test our skills with DPain(t) 4, and the
original anim was supposed to be about a jet taking off, losing power and
becoming the proud owner of its rear end on its front end. It never turned
out that way tho.. but it was a rather large and funny ordeal.

It took near on 5 days without sleep, countless coffees and more smokes
than Rothmans make in a year. We had to create it in 3 parts, as the old
A500 me brother had was running short of mem. He had a habit of
overclocking the damn thing too, and in a fit of OFS corruption part 2
(Pish-Posh Pony Club - the funniest bit) was gone. It had to be redone
from scratch.

The entire TopFun anim is in 16 colours ECS with 2963 hand-drawn frames.
You'll have to watch it several times to catch all the funny little bits in
between. The TFIntro is in 32 colours with 600 frames. TFIntro was
rehashed a bit sometime later (you'll notice the face of Mimi from the Drew
Carey show).

REQUIREMENTS:

Any Amiga (A500 68000 KS1.2+) with at least enough mem..


TFIntro Playback set to 25 FPS
-------
CHIP: 52,024
FAST: 183,704
ALL : 235,728


TopFun Playback set to 12.5 FPS
------
CHIP: 41,648
FAST: 1,790,664
ALL : 1,832,312


Enjoy - Olly.

__
__///
XX/ 10-Nov-99 - Brought to you by Amiga Smile


Ever since I learned what bitplanes were and how they were used I've been
fiddling with my own anim coding, mainly due to the mystery of ANIM5.

I understand ANIM5 now (sorta) but I don't bother with it anymore as it
produces files bigger than my own format. I've produced a non-lossy
compression of animation data, which compresses much better than ANIM5,
and also a lossy compression, mainly used for digitized images with lots
of moving pixels which are usually very difficult to compress.

I tried compressing frames with LZX as a comparison, but that didn't even
come close.

I've also coded a display routine that's capable of expanding a 160x128
format animation to 320x256 real time with only 35% overhead.

TopFun is coded with non-lossy compression, and without the timing loop
will play back at 1200 frames/sec. TFIntro being 5 bitplanes rather than
4, will playback a little slower, but not by much.

This isn't C2P kind of stuff, and you don't need an FPU or 020+. Playback
code is 100% assembler.


Here's some info:

The test machine is my own 1200/030/50/60ns Fastram Amiga at 50Hz PAL
video (Australia).


TopFun
------
2963 frames (320x256x4 AGA/ECS)
Raw picture data : 121,364,480
ANIM5 format (Dpaint): 2,925,530
Non-lossy compression: 1,719,781
Max FPS obtained : ~1,200

TFIntro
------
600 frames (320x256x5 AGA/ECS)
Raw picture data : 30,720,000
ANIM5 format (Dpaint): 276,564
Non-lossy compression: 97,317
Max FPS obtained : ~960

CODING FORMAT
-------------

Normal ANIM (Dpaint) format flickers badly when played back using only a
single screen, and even worse on slow machines. Each bitplane of data is
byterun encoded in column format from left to right, requiring decoding of
an entire bitplane before decoding the next. The video raster beam will
try to update this picture while it's being decoded, causing visible
and very unsightly flicker of the picture.

This can be countered by using 2 screens, drawing on one while displaying
the other, then flipping the newly drawn one to the front (called double-
buffering), or by waiting for the raster beam to reach the top or bottom of
the frame before decoding, but if you've got too much data for the speed
of your processor, you're not going to beat it.

My format always uses a single screen, saving memory and further overhead
by not having to juggle 2 screens, and the entire picture is encoded in
8x8 pixel blocks. 8 bytes make up 64 pixels of one bitplane on the Amiga,
and I draw that block, then the next block for the next bitplane etc.

Finding the correct screen location for each block, and even expansion of
each data byte is handled by optimised lookup tables created before the
first frame is shown. The overhead for this is then reduced to virtually
nothing. If writing to CHIP ram wasn't so slow, then speeds would
increase further by about 30%!

Now seeing that very little time is expended drawing data on each bitplane,
there's no flickering, so I don't have to try and beat the raster beam, or
care where it is at all. The encoding format uses more codes, but is
capable of much greater compression than byterun.

- Olly.

Download statistics Overview list for all downloads