stymie@d58cont.austin.ibm.com (10/11/89)
Several programming books that I've picked up for the Amiga reference a library 'graphics.library' that is used extensively in their programming examples. Almost every example issues an openlib() on graphics.library. I've looked through my workbench and extensions diskettes, the diskettes that shipped with the Manx C compiler, and all my other diskettes but haven't found the library. Does it exist?, and if so where can I find it? thanks, stymie ( Mike Wertheimer ) ....!cs.utexas.edu!ibmaus!auschs!d58cont.austin.ibm.com!stymie or stymie@cs.wisc.edu
joe@cbmvax.UUCP (Joe O'Hara - QA) (10/13/89)
In article <694@awdprime.UUCP> @cs.utexas.edu:ibmaus!auschs!d58cont.austin.ibm.com!stymie writes: >Several programming books that I've picked up for the Amiga reference >a library 'graphics.library' that is used extensively in their programming >examples. Almost every example issues an openlib() on graphics.library. > >I've looked through my workbench and extensions diskettes, >the diskettes that shipped with the Manx C compiler, and all my other >diskettes but haven't found the library. > >Does it exist?, and if so where can I find it? Yes, it does exist. It lives in Kickstart along with a number of other libraries. In other words, "It's in there!" Your include files contain graphics library structures and defines.
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (10/13/89)
In article <694@awdprime.UUCP> stymie@d58cont.austin.ibm.com writes:
Several programming books that I've picked up for the Amiga reference
a library 'graphics.library' that is used extensively in their programming
examples. Almost every example issues an openlib() on graphics.library.
I've looked through my workbench and extensions diskettes,
the diskettes that shipped with the Manx C compiler, and all my other
diskettes but haven't found the library.
Does it exist?, and if so where can I find it?
Yes, it does exist. "graphics.library" is a dynamically-loadable
shared library. Since its mere presence is necessary for the system
to run, it is part of the system ROM. Shared libraries are either
ROM-based or loaded from disk.
--M
__
\/ Michael Portuesi Silicon Graphics Computer Systems, Inc.
portuesi@SGI.COM
--
__
\/ Michael Portuesi Silicon Graphics Computer Systems, Inc.
portuesi@SGI.COMphorgan@cup.portal.com (Patrick John Horgan) (04/09/90)
Russell Wallace said: |All graphics software that needs to do anything FAST (i.e. animation) accesses |the video RAM and probably the blitter & copper directly because the graphics |library routines are much too inefficient. I used to think this too, and spent long hours when I was in college dis- assembling graphics library routines and commenting them so I could figure out what they were doing, (also because some of the blitter docs in the old RKMs were wrong and I wanted to see how you were REALLY supposed to draw lines:). Graphics is a bit of a specialty with me and I was able to recognize the algorithms used. They really use efficient algorithms. You're right that there is a lot of overhead, but it's not because the code is bad, or the algorithms inefficient. The real problem is that the routines must be general purpose. The routines must work in a multi-window environment. This means that you have a damage-list and complex clipping must be done for almost any graphics call. This takes time. The clipping routines are efficient though:) I was only able to speed up line-drawing using the blitter directly by assuming that my window would always be on top. One way to make things speed up in general is to draw into non-displayed bitmaps with no damage lists, and when done blit the whole thing at once to your display. Patrick Horgan phorgan@cup.portal.com
rwallace@vax1.tcd.ie (04/09/90)
In article <28715@cup.portal.com>, phorgan@cup.portal.com (Patrick John Horgan) writes: > Russell Wallace said: > > |All graphics software that needs to do anything FAST (i.e. animation) accesses > |the video RAM and probably the blitter & copper directly because the graphics > |library routines are much too inefficient. > > I used to think this too.... > ... Graphics is a bit of a specialty with me and I was able to recognize > the algorithms used. They really use efficient algorithms. You're right > that there is a lot of overhead, but it's not because the code is bad, or > the algorithms inefficient. The real problem is that the routines must be > general purpose. The routines must work in a multi-window environment. This > means that you have a damage-list and complex clipping must be done for > almost any graphics call. This takes time. The clipping routines are > efficient though:) I was only able to speed up line-drawing using the blitter > directly by assuming that my window would always be on top. To be sure, given that you have to do stuff with multiple windows, menus etc. the graphics library routines aren't that inefficient. The problem is the same routines have to be used even if you've opened your own custom screen, are using no menus and could just transfer everything straight into video RAM. There should be a separate set of routines for that and given that there aren't and that you need speed, you have to do things yourself. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie
p554mve@mpirbn.UUCP (Michael van Elst) (04/11/90)
In article <5849.26208c08@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: >To be sure, given that you have to do stuff with multiple windows, menus etc. >the graphics library routines aren't that inefficient. The problem is the same >routines have to be used even if you've opened your own custom screen, are >using no menus and could just transfer everything straight into video RAM. >There should be a separate set of routines for that and given that there aren't >and that you need speed, you have to do things yourself. Well, there is a speed difference between drawing into a window and drawing into a screen. All those clipping and locking checks are skipped when drawing into a screens rastport. Nevertheless, the current routines did one thing that made them 'safe' to use. They work synchronous so that you can free the bitmaps they are working on after the call returns. An optimized routine could use the time and calculate the next blit in advance. -- Michael van Elst p554mve@mpirbn.mpifr-bonn.mpg.de
jimm@amiga.UUCP (Jim Mackraz) (04/12/90)
In article <891@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes:
)Nevertheless, the current routines did one thing that made them 'safe'
)to use. They work synchronous so that you can free the bitmaps they are working
)on after the call returns.
That is not true for the Amiga graphics.library routines, in general.
You must do WaitBlit() after a routine if you need to know that the blit
is done.
)An optimized routine could use the time and calculate the next blit in
)advance.
Yep, that's what happens today. The routines call WaitBlit() BEFORE
they use the blitter, but not after.
jimm
--
-------------------------------------------------- - opinions by me
"This voice console is a *must*. I press Execute.
`Hello, I know that you've been feeling tired.
I bring you love and deeper understanding.' " -lyrics by Kate Bushp554mve@mpirbn.UUCP (Michael van Elst) (04/12/90)
In article <5543@amiga.UUCP> jimm@superman.UUCP (Jim Mackraz) writes: >That is not true for the Amiga graphics.library routines, in general. >You must do WaitBlit() after a routine if you need to know that the blit >is done. >Yep, that's what happens today. The routines call WaitBlit() BEFORE >they use the blitter, but not after. Yes, I got a letter from Dale Luck stating this. I've been wrong. But with multi-blit routines (say, multiple bitplanes), the routines work synchronous for all but the last blit. Seems to be that interrupt overhead should be reduced. Even with the WaitBlit() before using the blitter there should be LOTS of cycles wasted. (WaitBlit() busy-waits). -- Michael van Elst p554mve@mpirbn.mpifr-bonn.mpg.de