home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / atari / st / tech / 6405 < prev    next >
Encoding:
Text File  |  1992-12-26  |  2.9 KB  |  79 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!gatech!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!debug!Cford
  3. From: Cford@debug.cuc.ab.ca (Conan Ford)
  4. Subject: Re: Sending objc_draw to a buffer
  5. Reply-To: cford@debug.cuc.ab.ca
  6. Organization: Debug Computer Services
  7. Date: Fri, 25 Dec 92 19:52:33 GMT
  8. Message-ID: <1992Dec25.195233.1417@debug.cuc.ab.ca>
  9. Followup-To: comp.sys.atari.st.tech
  10. Keywords: 
  11.  
  12.  
  13. References: <1992Dec22.130323.2260@email.tuwien.ac.at>
  14. Sender: Cford@Debug.cuc.ab.ca
  15. Lines: 62
  16.  
  17. Marinos Yannikos (nino@vmars.tuwien.ac.at) wrote:
  18. : Cford@debug.cuc.ab.ca (Conan Ford) writes:
  19. : : Here's a suggestion:
  20. : :  
  21. : : Set the logbase() to a 32000 byte buffer.   That way all drawing will be
  22. : : done there but the user won't see it.  After each objc_draw, use BIT_BLIT
  23. : : to save the drawn stuff into another buffer.  After you are done, set the
  24. : : screen back.  Make sure to hide the mouse for this.
  25. : : -- 
  26.  
  27. : And if you want your program to be usable by other people than ST users
  28. : without graphics cards, Overscan etc., better think about that logbase()
  29. : and 32000 bytes buffer again...
  30.  
  31. : -MY
  32.  
  33.  
  34. I should have said,"a buffer the size of the screen buffer currently
  35. being used."  Since the logbase is the place where writes are done, the
  36. user will not see the objc_draw calls occuring provided that the
  37. physbase() is not changed.
  38.  
  39. So this would be the procedure:
  40.  
  41. 1. Hide mouse
  42.  
  43. 2. Set the object tree so that the objects will originate at 0,0
  44.  
  45. 3. Allocate a buffer the size needed by the screen plus 256 (the plus
  46.    256 is for old TOS versions so that you can ensure that the screen
  47.    is on a 256 byte boundary).
  48.  
  49. 4. Save current logbase value and set the logbase to the beginning of the
  50.    buffer just allocated (be sure that it is on a 256 byte boundary).
  51.  
  52. 5. Create x buffers of y size, where y is the size of the memory needed
  53.    by each "page" when saved with BITBLT, and x is the number of
  54.    "pages".
  55.  
  56. 6. Use objc_draw to draw each "page", and then use BITBLT to save it.
  57.  
  58. 7. Restore logbase() to old value.
  59.  
  60. 8. Deallocate the buffer which you are using for logbase().
  61.  
  62. 9. Show mouse.
  63.  
  64. 10.If that doesn't work with all screens I don't know what will.
  65.  
  66. N.B>  It's not a good idea to use MALLOC seperately for each "page".  If
  67.       you're using C or Basic, you should be able to use arrays, and if
  68.       you're using assembly language you will have to allocate them as
  69.       one and set up some pointers to each "page".  This is because of
  70.       the problems GEMDOS has when you use MALLOC for more than 20
  71.       seperate buffers (e.g. system crash :-)  ).
  72.       (Though you probably know :-)   )
  73.  
  74. -- 
  75.  Conan Ford 1:134/9,201:5500/9,1:134/21    | Save our forests - ask for
  76.  Cford@debug.cuc.ab.ca                     | plastic bags :-)
  77. ------------------------------------------------------------------------
  78.  I do not represent Debug Computer Services.
  79.