home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / c / 20028 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  3.3 KB
  1. Xref: sparky comp.lang.c:20028 comp.lang.c++:19695
  2. Path: sparky!uunet!noc.near.net!news.centerline.com!jimf
  3. From: jimf@centerline.com (Jim Frost)
  4. Newsgroups: comp.lang.c,comp.lang.c++
  5. Subject: Re: Graphics
  6. Date: 21 Jan 1993 20:31:01 GMT
  7. Organization: CenterLine Software, Inc.
  8. Lines: 62
  9. Message-ID: <1jn166INN535@armory.centerline.com>
  10. References: <1jko2nINNnmh@msuinfo.cl.msu.edu>
  11. NNTP-Posting-Host: 140.239.3.202
  12.  
  13. learman@cps.msu.edu (Jerome M Learman) writes:
  14. >I what to do some graphical programming and I want to get some comments on a 
  15. >couple of things. I want to you high quality graphics VGA or SVGA.
  16.  
  17. Hmm, VGA and SVGA are hardly what I'd call high quality, but then
  18. again I'm a snob :-).
  19.  
  20. >What is best to use for portabilty between unix and ibm compatablies?
  21.  
  22. There are very few graphics packages that are portable between them (I
  23. know of none I'd recommend).  What I've done in the past to handle
  24. graphics portability is to write my own graphics description layer and
  25. then port *that*.  Depending on what you need it can be a lot of work
  26. though.
  27.  
  28. In a previous life I wrote a "portable" object-based graphics library
  29. under X11 that myself and a co-worker ported to SGI GL in about a day
  30. and tuned in a week.  That library was rather complicated (it
  31. supported object collision detection and multiple overlays in software
  32. along with a healty supply of graphics primitives and extremely
  33. efficient repainting) and it took some months to write and debug, but
  34. simpler drawing libraries wouldn't be so hard.  If you keep the
  35. necessary primitives to a minimum the porting task isn't too hard, as
  36. demonstrated by the fact that we ported our library so quickly.
  37.  
  38. Without a set of graphics primitives for DOS machines it would be a
  39. big hassle, though.
  40.  
  41. >I have use Xview for but I believe this is exclusive to X windows.
  42.  
  43. Xview is based on SunView and it's rather primitive.  It's good for
  44. simple applications but isn't particularly good for anything more
  45. complicated.  It's certainly not the least bit portable.
  46.  
  47. >What is exactly is motiff?
  48.  
  49. Motif is a look-and-feel specification.  There's a library that
  50. implements a bunch of Xt widgets which implement the Motif
  51. specification that's also commonly called "Motif."  It's not portable
  52. either and it doesn't implement generic graphics commands.
  53.  
  54. >What did the best way to create motion?
  55.  
  56. There are a couple of "best" ways, depending on what you're working
  57. with and what you need to do.  The most generic way is to
  58. double-buffer -- you set the display up with two frame buffers, draw
  59. on the one that's not visible, then make it visible while you draw on
  60. the other one.  Most good graphics hardware has double-buffering
  61. capability, but almost no X servers support this capability and I
  62. don't think VGA/SVGA does either.  Without double-buffering the best
  63. you can do is to draw onto an area that's not in the frame buffer (an
  64. X Pixmap or an area in memory, for instance) and then blit it onto the
  65. display.  If the object's not very big and you limit your blit to the
  66. size of the object it'll work fairly well.  Given the limited
  67. resolution of SVGA I think it'd work quite well.
  68.  
  69. There are a lot of other techniques for accomplishing animation that
  70. aren't as general; if you're really interested in the topic you should
  71. hit your local library for some books.
  72.  
  73. jim frost
  74. jimf@centerline.com
  75.