Transitioning to blitting: MouseEvents and Collision detection issues

13 posts

Flag Post


I have started to learn how blit in an effort to make the type of games I want, mainly ones with a lot of projectiles/units. I have been using this 3 part video tutorial:

I can blit now IE: render my bitmaps to the screen using a single bitmap and copyPixels(). But I have run into a few issues of things that I take for granted when using displayObject:


I have created a simple tile map for a rudimentary TD (To learn concepts only, no one needs me to release another generic TD) using 2 tiles I have created one that will be a path and is used for units to travel on and the other will be non pathable ground that will be buildable; pretty standard stuff. So the first issue is simple, I want to click on a buildable tile to create a tower. The problem is, bitmaps can’t handle mouseEvents. FRom what I have read this leaves me with 2 possible solutions. Solution:

1) Wrap my bitmap objects in sprites – This solution seems to defeat the entire purpose of blitting. If I am going to wrap my bitmap in a sprite I might as well just use a sprit in the first place as I will have all the overhead I was looking to avoid.

2) Math – Attach an event listener to the main class (extends sprite) and use math to determine which tile I am clicking on. I am unsure of how to do this. The thought I have on doing this right now is that I pass the coordinates of the mouseclick to an event that checks the the coords against an array ot tiles. My tiles have x and y properties and width and height so I should be able to determine which tile I am clicking on. This could also get pretty intensive on maps with a lot of tiles. Any thoughts on this would be great.

The next issue is collision detection. I have no idea how to go about this with bitmapData. I am just getting past using hittest (A sin, I know) and am not sure how to go about implementing a simple system. Am I supposed to check actual pixels for overlap or am I supposed to define a geometric shape in my classes that I use to test for overlap based on the position of the bitmapdata render?
Flag Post

What I do is simply register a single mouse event to the main bitmap that I blit everything onto. When it is clicked, I simply do as you yourself suggested, compare the mouse x and mouse y to the x,y,width,height (a simple box shape) of the things that should be clicked. It might sound scary at first, but once you start building it you will see good ways to organize it with your classes and code.

As for collisions, it’s one of the biggest topics when it comes to game programming. When I first started out with my own collisions, I simply had AABB collisions (and I recommend you do too), which can be described as four IF() statements in a row, comparing the x,y,w,h of object 1 and object 2 to see if they “overlap”.

Flag Post

If you have a full square grid of equally sized tiles, finding which one you clicked by just the x and y of the click is easy. But if you have irregularly spaced/sized tiles, I don’t really know how you’d do it apart from simply checking every tile.

Flag Post
Originally posted by feartehstickman:

If you have a full square grid of equally sized tiles, finding which one you clicked by just the x and y of the click is easy. But if you have irregularly spaced/sized tiles, I don’t really know how you’d do it apart from simply checking every tile.

Setting an ID for the tile should do the trick

Flag Post

You should define your game model separately from the display form. That means your objects should have a simple geometric collision hull, which you can then use for collision detection and resolution, and for ‘picking’ (i.e. ‘which object did I click on?’) through the display/interface layer.

Flag Post

My graphics are separate from my logic, that is where the issue comes from. I am used to using graphic objects as concrete entities to preform logic on, this is my first attempt to abstract the physical properties of them and I am a bit lost.

Flag Post

Instead of working directly with graphical objects, have a hierarchy of GameObject classes. At the most basic level they can be like

class GameObject {
 var view:DisplayObject;
 var collisionHull:CollisionHull;

… where CollisionHull is a class that represents the collision geometry (i.e. what you use for hit testing). A simple 2D one with bounding box and circle collisions is fairly easy to create. In your game logic, instead of doing obj1.hitTest(obj2) or whatever you are currently doing, use obj1.collisionHull.collides(obj2.collisionHull).

Instead of DisplayObject you now want whatever mechanism you use for blitting.

Flag Post

I have some trouble seeing how this


would work. Unless collisionHull contains a set of coordinates stipulating where in the world the collisionhull is located, how would obj1.collisionHull know where obj2.collisionHull is in space? Come to think of it, how would obj1.collisionHull know where it itself is in space? Can’t call on the container’s x and y properties. On the other hand, maintaining a copy of the coordinates of obj in collisionHull seems cumbersome, but passing this info separately into collides is inelegant.
I guess one could store x and y in collisionHull and only have get and set functions at the GameObject level.

Another option would be to have the collision detection at the GameObject level, so basically use


which struck me as flawed logic at first (the objects themselves don’t collide, their hulls do) but is looking more appealing as I think about the alternatives. I’d justify it as: the objects themselves do collide, using their hulls to precisely pinpoint the instant and location of the contact.

Edit: No, actually, the spatial location makes sense as a property of collisionHull, with get and set at the object level. This way a collision box could use its x and y for the reference point (center, top-left corner, top-left corner of the bounding box in the cases where the collisionHull box is rotated, whatever) and a collision circle could use it for the coordinates of the center, or whatever other point of interest one might need. Since collisionHull handles all collisions it should work fine. But one would have to be careful because the display coordinates and the collision coordinates might not match. So was that what you meant? Or did you imagine the object keeping track of the display coordinates and the collisionHull keeping the collision coordinates?

This is giving me a headache.

Flag Post

I usually provide the coordinates along:

collisionTester.collides(obj1.hull, obj1.x, obj1.y, obj2.hull, obj2.x, obj2.y);

(rewritten to a singleton for clarity)

This gives the added advantage of being able to test collisions that haven’t actually happened by providing fake hulls or coordinates, for things like “is there room to teleport over there?”

Flag Post

I store the location (and orientation) in the parent object and give the hull a reference to it. The hull then stores information about what ‘shape’ it is relative to that point.

Flag Post

@ Bob – Since all the objects that I have displayed are blitted to my canvas, how would I store their information in the ‘parent’? Wouldn’t they essentially be orphans? I mean I am not calling addChild on them at any point.

@ Drakim – In your solution are you is collision tester its own class or is that a method of any collidable object? If it is wouldn’t that introduce interdependence between every single object? Such as the need for everyone to check against every other one every frame?

Flag Post

What class it is put in isn’t that important, the point is that it’s a static method rather than a member method, so I can provide any hull or position I want to.

The fact that you have to test every object against every other object isn’t a problem that appears because the code is written as a singleton. It was already there from the beginning.

The problem can be combated with techniques such as spatial indexing of various kinds.

Flag Post

I don’t mean ‘parent’ in terms of the display tree. You still have objects, which you are blitting … they presumably have an object representation with properties (position, velocity, etc). That’s the object that the collision algorithm needs to know about, whether from the hull directly or by passing it to a method like Drakim does.