home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18270 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!dkuug!imada!news
  2. From: breese@monet.imada.ou.dk (Bjoern Reese)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: OS 'Move/Draw' speed
  5. Message-ID: <1993Jan7.115153.1364@imada.ou.dk>
  6. Date: 7 Jan 93 11:51:53 GMT
  7. References: <1993Jan7.035143.5678@gn.ecn.purdue.edu>
  8. Sender: news@imada.ou.dk (USENET News System)
  9. Organization: Dept. of Math. & Computer Science, Odense University, Denmark
  10. Lines: 34
  11.  
  12. In article <1993Jan7.035143.5678@gn.ecn.purdue.edu> seifert@gn.ecn.purdue.edu  
  13. (Michael S. Seifert) writes:
  14. > 
  15. > The other day I ran a simple test to compare the speed of the Draw function
  16. > to a simple direct line blit taken from the 1.3 hardware ref manual.  Ive
  17. > always heard that the Draw routine is terribly slow, but in my tests, it
  18. > wasnt much slower than the blitter example...
  19. > 
  20. It's wrong to say that Draw is terribly slow. It uses the blitter too.
  21. As the line blit from the hardware manual is propably the same as the
  22. one in Draw (I haven't checked though) you'll only gain a minor speed
  23. increase by avoiding the system jumps.
  24.  
  25. > Now, I know the Draw routine is slow, so whats up?  What kind of line
  26. > routine would be the wisest to create-- or do real programmers code their
  27. > own line routine and use the cpu to draw it???
  28. > 
  29. > mike
  30.  
  31. "Real programmers" make their own blitter line routines (some of which
  32. can be found on some ftp sites - I forgot where) The only possible
  33. gain is cutting away overhead (and sometimes relying on preservation
  34. of the values in the hardware registers - take care though.) The
  35. calculation of the octants is an obvious place to optimize. Using
  36. MOVEM to hit more hardware registers at once is also seen, but take
  37. care not to write to any unknown registers.
  38.  
  39. With a M68000 there's no idea in using the CPU instead of the blitter;
  40. it's too slow.
  41.  
  42. --
  43.  
  44. Bjoern Reese                   |     Email: breese@imada.ou.dk
  45. Odense University, Denmark     |     Voice: +45 65 932 182 (private)
  46.