Bunny Spawning completed

October 29, 2007

I reworked the collision function and it now has better functionality for future use. The bunny system is almost complete, as far as spawning and killing bunnies onto the stage without errors of collision occuring. Tonight I’m going to have to probably put this project on hold while I finish up some other things, but I’m going to try and implement the plants onto the stage at least before it is do tomorrow. We have a meeting for class tonight to show the work that we have done so far, so I guess I’ll find out how much I need to add before tomorrow’s class.


Brain shutdown and Bunny Spawning

October 29, 2007

Inside of the game, bunnies will begin to spawn from various holes through out the stage. I had this implemented in my original version well enough, but with the new collision detection system, I need to develop a new way of spawning bunnies. The problem arises because the hole itself has it’s own collision sprite. As the bunny gets spawned, it obviously must be outside of the collision sprite of the hole, otherwise it is stuck in permanent “collide” mode and will never move. This is simply enough, but the real problem comes about when I want the bunny to spawn into a location where another bunny already is.

I think a simple rework of my collision detection function will make this work. As it is, the collision function is called whenever there is an update to the object array of the graphics engine and checks against a fixed color value. I need to update the function to be called by the object that is moving, instead of the engine, and pass an argument with a color value so that I can get more functionality out of the… function.

Unfortunately, my brain has shutdown for the day and I’m not sure if I can get it to keep working for the next couple of hours. I also need to work on my outline for Speech class that’s due this week, so I might have to put this project on hold for the rest of the day and get back to it tomorrow.


October 28, 2007

I had a moment of epiphany for the collision detection of my game. And it works! Perfectly! With over 100 objects on the stage. No lag what so ever from what I can tell.

How it works

Pretty easy actually, once I thought about it. Each sprite on the stage has a corresponding collision sprite, just like in the old system. The flaw I ran into was that I had to either A) Draw a separate collision buffer for each of the objects on the stage (resulting in lag from redrawing an image multiple times) B) if I drew a single map, then the object would collide with itself, since it would register it’s own collision sprite. The solution was so simple I can’t believe I didn’t think of it earlier.

Right now, the collision sprite is automated by the code. When I create a new sprite, a collision sprite is automatically made for it. The collision sprite is exactly twice the size of the normal sprite with a color of 0x88000000, IE semi-transparent. This way, the sprite will only detect a collision if the sprite interacts with another collision sprite. The value of a single collision sprite is not strong enough to stop it.

I’ve also created two functions to update sprite registration points (right now it’s just set for the middle of the image) along with updating a collision sprite. This way, in the future, when I start creating background images, I can make a custom collision sprite so that it doesn’t fill the entire screen.

You can see all this here. Pressing the space bar will show you the collision buffer instead of the frame buffer.

On a side note, it does seem that WordPress doesn’t like Safari, so I’m going to have to switch back over to Firefox when I want to post on WordPress. No big deal, just an inconvenience.

WordPress and Safari

October 28, 2007

So far, posting with the Safari browser has been a major headache. It seems that the functionality of the posting feature through WordPress’s posting forum is not compatible with Safari. I’m trying out firefox right now to see if it is any better. Hopefully I won’t have to go back and manually fix this post like I have had to do with my previous ones.

Check. 1. 2.

Simplified collision detection works well

October 28, 2007

So, I replaced my original collision detection system for the graphics engine with a more simplified version. What it does is given three arguments, an index value of the sprite to check collision for, a sprite type for the types of objects to check collision against and the distance to check against collision, it cycles through all objects on the stage. If the object is of the right sprite type and isn’t the sprite being checked, it then checks to see if it is at least within the distance in both the x and y direction. If so, a specific distance using the Pythagorean theorem (Yay for Pythagoras), is used to see if it is less than distance away. If so, it returns true. If not, false. Obviously a simplistic form of my previous version. It works very well though, with 50 objects on the stage, I see little to no performance decrease.

I was wrong

October 28, 2007

Collision detection isn’t the bane of my existance. My redraw functions were. It seems that a “small fix” I had implemented last night is what was causing all of my problems. Instead of, as I had originally done, calling my DrawBuffer() and SwapBuffer() functions on each EnterFrame event for the root mc, I had changed it to only be called when a sprite or objects is added, updated or removed from my rendering array. Once I implemented the automated movement function, the image was being updated many, many times more than it should have been. Once I switched back to my original onEnterFrame handler, it runs much smoother with collision detection enabled.

I still need to work on the efficiency of the system, though. I can get about 20 rabbits on the scene before it starts slowing down. Without collision detection on, I can get around 200+ on the stage before I notice any sort of performance decrease. 

Collision detection is the bane of my existance

October 28, 2007

Right now I’m trying to develop a collision detection system that won’t bog down the flash scene as the number of objects increase. The current method I’m using involves drawing a collision buffer, which then gets checked against by each object in the scene. Basically, I cycle through an array which contains the location of all objects on the scene and draw a collision sprite. This buffer is a grayscale image, and I simply check each movement location for each object against this image. If the pixel that the object wants to move into is black, no movement occurs.It works flawlessly as far as actually preventing collision, no matter how many objects are on the screen. The problem arrises because I have to draw a new collision map for each object in the scene. Each single objects collision map does not include it’s own collision sprite, so that it doesn’t register as colliding with itself. As the number of objects increase, the number of collision maps that have to be draw each frame also increases. This is a problem, since basically to draw 1 frame with 10 objects, I end up having to draw 11 frames. Not efficient at all.

Some ideas that have gone through my head include setting each collision sprite to a different color, but then the problem of depth buffering comes into effect. Since the draw order is determined by the objects location in the array, the last object draw will have it’s entire collision sprite overlap other sprites, thereby making it impossible to check if it is colliding with another object. What I need to figure out is a method for ignoring the object that is checking for collision’s collision sprite.