From: olavka@ifi.uio.no (Olav Lur}s Kalgraf)
Subject: Re: New hardware reference guide?
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Mon, 16 Nov 1992 13:41:53 GMT
Originator: olavka@kjerringa.ifi.uio.no


In article <1992Nov12.215020.20036@ultb.isc.rit.edu>, eas3714@ultb.isc.rit.edu (E.A. Story) writes:
> In olavka@ifi.uio.no (Olav Lur}s Kalgraf) writes:
> >
> > Although I agree that it is a step in the right direction, there is a
> > small problem with using the OS for games etc. Last weekend I tried
> > to make a small vector routine using the graphics.library. The results were
> > absolutly PATHETIC! And I use an A4000 for gods sake! After that big
> > dissapointment I rewrote the code to some giant pseudo OS/hardware hack.
> 
> Code please?  It doesn't mean anything if you don't know HOW to program
> fast graphics under 3.0... (and you don't, most likely, since MOST people
> don't have any documentation on 3.0 as of yet).
>
Actually I used the 2.0 includes, and used calls to old graphics lib
fillpoly functions. BUT if 3.0 was coded in a sencible way, these functions would
be optimized, and recoded to use the AGA chipset, NO? Anyway all I
did was making a 1 BITPLANE rotating polygon and timing it with the raster

 
> > This worked quite well, but anyway I came to a few conclusions:
> >
> >       1. The graphics.library is incredibly slow and most likely
> >           not updated much in release3. This needs to be rewritten
> >           entirely to satisfy the needs for speed in todays games.
> 
> Again, graphics.library isn't gonna help you much if you insist on using
> old routines in slow ways.

And again, my result didn't have anything to do with the way I am using
gfxlib. ONE filled polygon, five points rotated about 3 axis......
OK, I used the fillpoly or something, function. And I am sure I could
have done it faster by using the blitter functions, BUT won't these
functions be kind of obsolete when DIG is introduced. They are assuming 
things about the hardware you know.......


> 
> >       2. The dream of DIG can not include the blitter unless 1.
> >           comes true. We really need the blazing speed of optimized
> >           assembly to take advantage of the amigas chips with todays
> >           incredibly slow OS graphics support.
> 
> We need blazing speed, not necessarily optimized assembly.  Two different
> things.
> 
Different, true. But also very closely connected, optimized assembly
means blazing speed. 


> >       3. Anyone claiming that the speed difference between using
> >           OS and optimized assembly+hardware hacking is minimal
> >           does not know what he is talking about.
> 
> Depends on what you're doing... I'd suggest that you optimize the way you
> USE graphics.library, not the way graphics.library is written.
> 
Have you ever tried hitting the hardware with pure optimized assebly????
I can tell you that it can't be compared to OS snailcode. I mean, there is
a reason why most games are written in 'trash the metal' code......


	Yours, Olav Kalgraf..


PS: I really hope you are right about 3.0 gfxlib, it would be nice if
	there were some functions for fast gfxoperations there, in 
	pre 3.0  stuff like that was NONEXISTANT!!!
	pre