home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / atari / st / tech / 4726 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.2 KB
  1. Path: sparky!uunet!wupost!uwm.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!andrew.cmu.edu!sm86+
  2. From: sm86+@andrew.cmu.edu (Stefan Monnier)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: "fast" sprites in C
  5. Message-ID: <UefNt=q00VorIjCEdL@andrew.cmu.edu>
  6. Date: 8 Sep 92 22:48:43 GMT
  7. Article-I.D.: andrew.UefNt=q00VorIjCEdL
  8. References: <61138@aurs01.UUCP>
  9. Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
  10. Lines: 60
  11. In-Reply-To: <61138@aurs01.UUCP>
  12.  
  13. Excerpts from netnews.comp.sys.atari.st.tech: 8-Sep-92 "fast" sprites in
  14. C John M. Klassa@aurs01.UU (1651)
  15.  
  16. > Hi All-
  17.  
  18. > I've attempted, on a couple of occasions, to write silly little games
  19. > for my own amusement.  What I always run into, though, is terrible,
  20. > terrible performance when I try to put objects on the screen and
  21. > animate them.  My mind keeps going back to that ST classic
  22. > "Megaroids," which was claimed to have been written in C (although I'm
  23. > not positive that they didn't use assembler in there somewhere).  How
  24. > do you, the readers of comp.sys.atari.st.tech, get good performance
  25. > when doing sprites?  *Must* I use assembler, or can it be done in C?
  26. > (My problem is that I don't know assembler...)  On a related topic, I
  27. > remember a long discussion between (I think) Dave Baggett and somebody
  28. > else, on the topic of double-buffering & handling it during vbl and so
  29. > on...  Is double-buffering pretty much the only way to give animated
  30. > games that "smooth" look?  If so, I would imagine that assembly is
  31. > required there, too...
  32.  
  33. > Thanks for any and all input!
  34. > John
  35.  
  36. > P.S.  How do y'all handle keyboard input?  i.e. How can I detect when
  37. >       multiple keys are in the down position?  How can I turn every
  38. >       key into a "shift-like" key, so that the player can hold it down
  39. >       as long as he/she wants to without it going into repeat mode, etc.?
  40.  
  41. > Thanks again!
  42.  
  43. >  o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
  44. >  o                               John M. Klassa                              o
  45. >  o      Alcatel Network Systems, Inc. --- Raleigh, NC --- (919) 850-1246     o
  46. >  o        Email: klassa%aurfs1.aur.alcatel.com@rockdal.aud.alcatel.com       o
  47. >  o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
  48.  
  49. Sure, assembly is necessary if you realy want to get the speed of 
  50. current games. But, you can do games without !
  51.  
  52. Double buffering is available from about any language (XBIOS)
  53. And for fast animated sprites, you HAVE to do 'precomputing', 
  54. that is preparing the data so that wherever your sprite should
  55. appear, it just has to be put there without having anything more
  56. to compute (bit shifting,...).
  57.  
  58. But, sure this precise part of sprite display should be written in
  59. assembler, as you sure can get a speed improvement of about 2 to
  60. much more (depending on the compiler and on you).
  61.  
  62. In general, high speed can be achieved with a little of assembler
  63. on the critical points and a lot of C for the rest. Of course
  64. all assembly can give you a bit mor speed (helpful to 
  65. get the real 'video-game' feeling, I think)
  66.  
  67.     Stefan Monnier
  68.  
  69.  
  70. -----------------------------------------------------
  71. -- On the average, people seem to be acting normal --
  72. -----------------------------------------------------
  73.