home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1707 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 22 Jan 1996 22:55:30 +0100
  6. Organization: dis-
  7. Message-ID: <4e114i$4o8@serpens.rhein.de>
  8. References: <38232020@kone.fipnet.fi> <9PxXx*kka@aargh.incubus.sub.org> <4des65$bgk@serpens.rhein.de> <38232076@kone.fipnet.fi> <4djpni$t6h@serpens.rhein.de> <4dm07g$ouh@sunsystem5.informatik.tu-muenchen.de> <4dmm79$9hu@serpens.rhein.de> <4e0jhq$f0q@sunsystem5.informatik.tu-muenchen.de>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  12.  
  13. >don't you think someone knowing about OS-coding, but beeing 
  14. >a friendly, non-agressive fellow, couldn't achieve more ? ;)
  15.  
  16. Ignoring the discussion as always.....
  17.  
  18. No, I am quite sure that noone can achieve anything if the other
  19. side is as stubborn as you.
  20.  
  21. >|> Right. It depends on lots of things, so at least a straight
  22. >|> copy can be optimized by the driver.
  23.  
  24. >? how to optimize move.l (a0)+,(a1)+ ;) 
  25.  
  26. By starting the DMA channel ?
  27. By using movem.l to send bursts of data ?
  28. By funneling the data into a FIFO at a constant address ?
  29.  
  30. You do not know. The driver does.
  31.  
  32. >I'd suggest the driver gives you a buffer you can render to,
  33.  
  34. And again you are limited to a single possible architecture.
  35.  
  36. >If the card can display multiple buffers and writing bytewise to it
  37. >is faster than writing bytewise to fastmem + copying the buffer,
  38. >the driver will give you an adress in vram. voila :)
  39.  
  40. But why should writing bytewise be faster ?
  41.  
  42. >So making the OS more sucking
  43.  
  44. Again just insults.
  45.  
  46. >would keep then from using 
  47. >OS-functions to get fast animation ? 
  48.  
  49. Fast animation doesn't need user-level access the graphics buffer.
  50.  
  51. >any games showing fast gfx naturally want to have a screen (better
  52. >say screenbuffer) they can render to. also OS-coded ones will still
  53. >want "a complete screen allocated to you." because no game is fun
  54. >on half screens.
  55.  
  56. This surely depends on the screen, especially on the screen _size_.
  57.  
  58. >you can keep game programmers from doing this in providing a powerful
  59. >interface that doesn't suck
  60.  
  61. again just insults.
  62.  
  63. >and so won't force them to do direct poking
  64. >something.
  65.  
  66. Nobody is forced.
  67.  
  68. -- 
  69.                                 Michael van Elst
  70.  
  71. Internet: mlelstv@serpens.rhein.de
  72.                                 "A potential Snark may lurk in every tree."
  73.