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