From: deadman@garnet.berkeley.edu (Ben Haller)
Newsgroups: comp.sys.mac.games,comp.sys.mac.programmer
Subject: Re: NON-QUICKDRAW GAMES
Date: 11 Sep 1992 00:30:45 GMT
Organization: Stick Software
NNTP-Posting-Host: garnet.berkeley.edu

In article <BuD5Kr.6x2@acsu.buffalo.edu> triantos@acsu.buffalo.edu (Nick B Triantos) writes:
>Recently, bwilliam@iat.holonet.net (Bill Williams) writes:
>   Also why all this talk about animating palletes now and then? isn't it (1)
>   impossible on direct mapped 24 bit devices and (2) only possible at the
>   end of a device VBL (governing it not only to 60 per second, but IDLING
>   THE CPU during the wait? (not sure if it waits in the trap or not though))
>   resulting in an effect leaving 0% free CPU.?
>
>Well, actually, VBL tasks can be activated 60 times / second, but you specify
>how many ticks pass between actual calls to the VBL in <your-VBLTask>.vblCount
>Thus, if you only need your routine to pop up 3 times / second, set vblCount to
>20. (IM-II, p. 350).  My experience with VBLs is limited only to some ultra-
>simplistic testing I did when I first read about them, and so I'm also unsure
>about whether the task _MUST_ complete before control is resumed to the main
>program.
  No, he's not talking about calling SetEntries from a VBL, he's talking
about the SetEntries routine (or actually, the video driver) waiting in a
tight loop for the gun to get to a certain point before doing the
SetEntries operation.  See my other post in this thread (no, not that other
post, the *other* other post - god this is a busy thread!)

>I'm really enjoying this thread, as I'm in the early stages of programming an
>action-style game for the Mac, and I really could use the help (my last game
>was on an Apple ][e, and it was in pure 6502 assembler).  If there are other
>people out there who have information about the following, I'd love to see what
>you have to say about:

> - efficient collision detection algorithms
  My current favorite is, keep a sorted list of sprites (keeping it
sorted, assuming your sprites don't constantly teleport, is O(n)) and
compare nearby elements in the sorted list (again, O(n) for normal cases).
If you get a bounding box intersection, do a mask compare.  This is
pretty efficient, I think.  I hope...

> - computer strategy heuristics (e.g. when does the monster shoot, when does
>   the alien lob a bomb at the player, when does the CPU make the checkmate
>   move, etc.  Only some of these things should be purely, random, no?
You certainly need non-random elements.  I usually have things like a
time delay that the enemy has to wait before firing again, things
like that.  You will find that it's easy to make bad guys that cream
human players.  The hard thing is to make well-balanced enemies, or
enemies that behave in an interesting way.  Books could be written
on this subject...

> - What type of code does the programmer make "reusable" enough that when his
>   or her next game comes along, he/she doesn't have to start from scratch
Everything you can!  I generally don't even attempt to make the
display code general beyond a reasonable point, it is just a fact
of life that virtually every game requires you to rewrite your
graphics code...assuming you want to be fast...
  Everything about dealing with keyboard/mouse, displays, high scores,
sounds, etc etc should be as portable as possible.
  The logic that moves the bad guys and stuff will be game-specific,
unless you want the same bad guy in two games...

> - Proper use of VBLs, and the other suggestions Joe Holt had made a few days
>   ago (uses/abuses of off-screen buffers, clut animation, protecting your
>   screen real estate, masking techniques, & assembly language optimizations)
  Boy, quite a bit could be written about all this.  Want to ask a slightly
less broad question relating to something you're actually trying to
do *right now*?  Just to narrow it down a bit...

-Ben Haller (deadman@garnet.berkeley.edu)