From: oahvenla@galactus.cs.hut.fi (Osma Ahvenlampi)
Subject: Re: Well over 2000fps (yes THOUSAND!)
Organization: Helsinki University of Technology, CS lab
Date: Thu, 8 Oct 1992 18:41:58 GMT

In <1992Oct8.103327.59531@cc.usu.edu> slbfn@cc.usu.edu writes:

>In article <35657@cbmvax.commodore.com>, mks@cbmvax.commodore.com (Michael Sinz) writes:
>> Yes, the system calls in Release 3 that do double
>> buffering can do it basically the same speed in all
>> of the video modes.  Well over 2000fps...
>>
>> /----------------------------------------------------------------------\
>> |      /// Michael Sinz  -  Senior Amiga Systems Engineer              |
>> |     ///                   Operating System Development Group         |
>> |    ///   BIX:  msinz      UUNET:  mks@cbmvax.commodore.com           |
>> |\\\///                     When people are free to do as they         |
>> | \XX/                      please, they usually imitate each other.   |
>> \----------------------------------------------------------------------/

>Now, you guys tell me why you'd have to pound the hardware if the system
>calls can do over 2000fps.  That is *damn* fast.

>I realize that peoply *like* to hit the hardware... but for speed?  Sounds
>unnecessary.  What other techniques reqiure hitting the hardware besides
>speed?  Copperlists?  Blitter stuff?  What?

I hope you realize that 2000fps speed is with 3.0. The old (or current,
whatever) system calls are horribly slow, you can do something like 10fps. And
that's only changing screens. Where would you do the animation? Now, the
3.0 2000fps means that it takes 1/40 of a PAL screen refresh to change screen
buffers. You can do animation with that framerate, but it is slow. 1/40 is
several scanlines, when you could do it with a hardware in less than one.
And that's with 68000. 3.0 works only in A4000 at the moment, so one could
suppose that 2000fps is with 25MHz 68040. Get the idea? It is more than enough
for an anim-player, but what if you want to calculate your animations realtime
using doublebuffering? You lose a lot of rastertime using system calls even
with 3.0.
In fact, I'm all for using system calls, as they ensure that your softwar
works, no matter what the model running it is. But I can see why demo coders
would use hardware. Unfortunately, direct hardware access means you can't
use AGA modes, unless you find out the registers yourself, and I wouldn't
recommend using them even if you did, as it is not at all sure they are the
same in the next model.
This leads to two kinds of programs: the ones which take out everything the ECS
chipset can give, and the ones using AGA and system calls. If both are done
right, it is pretty likely that they will work with all at least ECS equipped
models at least until something like 98... ECS support will be dropped
sometime, if the Amiga can survive until that.. Hopefully it can.
How are AGA using programs gonna work on ECS? Read it again, they will if done
correctly, so that they drop colors/resolution if needed. For example, in
comp.sys.amiga.programming there was a article about possible ways of doing
Wolf 3D-routines on Amiga, which had a good idea how to make a routine that
uses 256 or 32 colors with only a very small change.
--
Osma Ahvenlampi  -  oahvenla@niksula.cs.hut.fi
My opinions are mine, and though someone else may share them, that's not my
fault. You may freely agree or disagree with me, I don't much care.