fred@cbmvax.UUCP (Fred Bowen) (04/06/89)
In article <2837@uokmax.UUCP> blpike@uokmax.UUCP (Brian Lee Pike) writes: >How can I possibly tell that sprite A has collided with B, but hasn't collided >with sprite C? Similar (but more complex) problems arise when more sprites >are allowed to move freely and simultaneously onscreen. This problem is faced by many C64 game programmers, and there are few solutions. As you indicate, the problem becomes more complex as the number of sprites increases. You must use all the information you have available- the collision registers are just an indication that something happened. Imagine how difficult the task would be if you did not even have this information! In fact, it may give you a clue how to solve the problem if you do just that. What else do you know about the sprites? You can determine their position, and you know their size. The programming necessary to determine if two areas overlap can be daunting to beginning gamers, but if you break the task down into smaller pieces it becomes more manageable. Does sprite a's x-position lie between sprite b's x-position and (x-position+width)? If not, a and b did not collide with each other. If so, compare y-positions. There are some tricks and optimizations in which you may indulge. For example, compare y positions first, since they require 8-bit math only and that's faster than the 16-bit math necessary to compare x positions. If you can limit the size, shape, location, or number of sprites, that will help of course. Limit the number of sprites you move between collision checks. If you detect multiple collisions, you may want to try to coordinate your code with the raster and disable one or more sprites for one frame and check the collision register again to eliminate some of the confusion. In the end, only this last trick will determine for sure if two sprites have collided since it is unlikely you are using perfectly square sprites. All other approaches are not 100% correct- how many games have you played where you *swear* you were not hit by the bad guy? I have been assuming you are writing machine (assembly) code. BASIC is just too slow and limited for such tasks. I doubt you'll find any existing code to use, as such code depends greatly upon the particular game and in all likelyhood it has been highly optimized. So much so, in fact, it would be difficult to read and understand and would make a poor example for beginners. -- -- Fred Bowen uucp: {uunet|rutgers|pyramid}!cbmvax!fred arpa: cbmvax!fred@uunet.uu.net tele: 215 431-9100 Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380
cygnus@wpi.wpi.edu (Marshall Robin) (04/06/89)
Hmmm.... maybe by turning each of the sprites off and then checking the collision register again you could tell what collided with what before the scan line reached the group of sprites again. If the collision register relies on the scan line, then obviously this wouldn't work. -- Bitnet: |"When they turn the pages of history cygnus@wpi.bitnet | When these days have passed long ago Internet: | Will they read of us with sadness cygnus@wpi.wpi.edu | For the seeds that we let grow?" -Rush