home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / atari / st / tech / 6917 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.0 KB  |  39 lines
  1. Newsgroups: comp.sys.atari.st.tech
  2. Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!ilepore
  3. From: ilepore@nyx.cs.du.edu (Ian Lepore)
  4. Subject: Re: Falcon GEM version number please
  5. Message-ID: <1993Jan28.185123.218@mnemosyne.cs.du.edu>
  6. X-Disclaimer: Nyx is a public access Unix system run by the University
  7.     of Denver for the Denver community.  The University has neither
  8.     control over nor responsibility for the opinions of users.
  9. Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
  10. Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
  11. References: <1993Jan27.162501.778@cs.ruu.nl> <1993Jan28.000523.15445@netcom.com>
  12. Date: Thu, 28 Jan 93 18:51:23 GMT
  13. Lines: 24
  14.  
  15. > new (TOS 4.02) AES uses ob_flags instead of extended object type for 3D
  16.  
  17.  Well thank gawd for that!  So many of my applications broke (or appeared so)
  18. with the extended object type hack that I was within a hair's breadth of 
  19. giving up on the ST world altogether.
  20.   
  21.  I'm wondering though:  why didn't the use of 3D objects just become a global-
  22. to-the-application issue, instead of a per-object issue?  I'd much prefer to
  23. see a new aes call, maybe appl_3d(TRUE); that informs the aes this application
  24. was designed with 3D objects in mind, so use them.  It seems to me that mixing
  25. flat and 3D objects in one application would be bad style at best.
  26.  
  27.  Also, I'd like to offer some food for thought for those at Atari working on
  28. AES internals:  please consider setting aside bit 15 of ob_flags and ob_state
  29. for use by the application, and document it as such.  Even better would be
  30. bits 14 and 15, but that may be asking too much.  If prior art holds any 
  31. weight, the GemFast library internals use bit 15 of ob_flags now to define 
  32. a moveable dialog; the object that can be grabbed to move the dialog has 
  33. bit 15 of ob_flags set to indicate such.  I just couldn't find any other
  34. way or place to stuff some indication of what the mover object is.  (The
  35. reason I'd like bits 14 *and* 15 is that then a rule could be formalized 
  36. that says 15 is reserved for library implementors, and 14 is reserved for
  37. the end application.)
  38.  
  39.