home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / msdos / programm / 7980 next >
Encoding:
Internet Message Format  |  1992-07-20  |  5.3 KB

  1. Path: sparky!uunet!haven.umd.edu!purdue!bu.edu!decwrl!decwrl!ucbvax!ucdavis!toadflax!zerkle
  2. From: zerkle@toadflax.cs.ucdavis.edu (Dan Zerkle)
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: Video game framework?
  5. Message-ID: <15350@ucdavis.ucdavis.edu>
  6. Date: 20 Jul 92 22:20:24 GMT
  7. Sender: usenet@ucdavis.ucdavis.edu
  8. Reply-To: dz@stl.panasonic.com
  9. Followup-To: sender
  10. Organization: Speech Technology Laboratory, Panasonic Technologies, Inc.
  11. Lines: 101
  12.  
  13. I'm working on a project that involves writing what amount to video
  14. games on EGA systems.
  15.  
  16. Right now, I'm about to start writing a framework for this.  That is,
  17. I'll write all the main system, and the other programmers will
  18. fill in the details on different kinds of games later.
  19.  
  20. The main framework will involve the expected sorts of things:  Routines
  21. for drawing, erasing, and otherwise changing the appearance of images
  22. on the screen; a menuing system so that users can change parameters
  23. and so forth; templates describing the motions of the various objects;
  24. setup routines to draw backgrounds, initialize memory and so on; input
  25. routines to manage the mouse and keyboard; and finally and event loop
  26. to tie the whole thing together.
  27.  
  28. It will also have to do some unexpected things:  The system we're
  29. developing involves some specialized hardware that gets speech data
  30. from the user.  This provides raw digitized sound, intensity
  31. (loudness), pitch, airflow, plosive (if you don't know, don't ask),
  32. and palatograph (you _don't_ want to know) information.  The system
  33. will have to use some rather "interesting" routines to get input from
  34. this device (these are already written).  I'll have to plug them in in
  35. some reasonable way.
  36.  
  37. Also, the data coming in can be _very_ time-sensitive.  It may be
  38. necessary to get data every 10 ms.  The system timer ticks only once
  39. every 55 ms or so, and this might be unacceptably slow.
  40.  
  41. The other programmers will take this basic system and make real games
  42. out of it.  This will involve providing bitmaps that describe the
  43. appearance of all the objects that will move around the screen,
  44. writing functions that describe how the images move in response to the
  45. various input (one for x pos, one for y pos, and one to pick out which
  46. of the bitmaps in this object is the correct appearance), and possibly
  47. write functions that describe anything else interesting that that has
  48. to happen.  Naturally, the framework needs hooks so that all of this
  49. can be plugged in.
  50.  
  51. I'll also put together some tools to help.  I'll need something to convert
  52. bitmaps from paint program format to something that the programs can
  53. use (I've done this before).  I was also thinking of a "game compiler"
  54. that would take a basic description of the game in some new language
  55. or another, then generate code to implement it.  This would save the
  56. other programmers a lot of work later, and keep them from modifying my
  57. code too much....  I'm sure I'll think of other tools, as well.
  58.  
  59. Note:  sound (output) is _NOT_ a concern.  The system will be a speech
  60. training system for deaf kids.
  61.  
  62. We're using Borland C++ 3.0, and I'm not afraid of a little assembly
  63. language here or there.  Assembly  might be asking a little much from
  64. the other programmers, though.  The system has VGA cards attatched,
  65. but we're pretty much assuming that they are EGA cards (not using the
  66. new VGA features).  Right now, the code is all 286-compatible, even
  67. though we're using 386 and 486 machines.  We could write 386-specific
  68. code, although it would probably be over the objections of the folks
  69. in Japan.
  70.  
  71. So, I've got a big project ahead of me.  I've already run into a few
  72. nasty surprises, like:
  73.  
  74. "Gee, the ANDing function of the data rotate register doesn't seem to
  75. "do what I expect in write mode 2.  Maybe I should have used write mode
  76. "0.  Too bad it is such a pain to use.
  77.  
  78. or:
  79.  
  80. "Gee, this screen update seems awfully slow.  Maybe we shouldn't have
  81. "used 350x640 resolution.
  82.  
  83. So, I noticed a product from TEGL systems that's called the TEGL Games
  84. Toolkit.  This is only for Pascal, so it won't help us.  However,
  85. there might be other packages out there that might be a big help.
  86. This engine is going to be a massive project, and it would be nice to
  87. buy something to make it easier.  It would also be good to have some
  88. package that takes care of the nasty surprises for me....
  89.  
  90. Can anyone suggest a similar package?  It would need to be able to do
  91. things fast enough to give better time resolution that that from the
  92. 18.2 times a second timer, and it would need to allow for input from
  93. the special hardware.  It also needs to allow for pull-down menus and
  94. so forth, since these "games" will involve more than typical games.
  95. It would be nice to get such a package and save ourselves months of
  96. development time.
  97.  
  98. Any other hints would be welcome.  Recommendations of software
  99. libraries, books, and so forth might help.  Any tricks to speed up
  100. output to the EGA/VGA card will be read carefully.  
  101.  
  102. Basically, nobody here has much experience with video games over what
  103. we've done here.  Don't worry about not telling use something because
  104. it's too obvious.  Anything you think we might do, I'd be happy to
  105. hear about.
  106.  
  107. However, anyone suggesting that we should switch to developing on an
  108. Amiga will be shot.  I know that already.
  109.  
  110. Please e-mail to dz@stl.panasonic.com.
  111.  
  112. --
  113. Dan Zerkle  zerkle@cs.ucdavis.edu dz@stl.panasonic.com (805) 687-0110 968-1738
  114.