[HELP] Collision system

[mr_malee]

really all you need is an efficient loop, maybe a simple cell data structure. Will you know the max speed of any projectile?

if so you can create cells the size of this maxspeed and add/remove objects from the cell, so you only need to loop over objects in the current bullets cell. Very simple and efficient.

I think computing collisions at the spawn time of a bullet is going to be much more CPU intensive than a loop. Especially if objects are going to move, you'd have to loop over every single object, find its future position compared with the bullets future position and see if an intersection happens. You also would have to keep the loop running until all objects have been checked otherwise you'll get inaccuracy problems. Sounds bad to me.

[Viza]

Yep, I see what you're saying Malee. I had a similiar idea not so long ago but ditched it because I thought I was starting to get a lil too ambi,tious in creating a nice collision system when it could get away with crappier (yet suitable) methods such as hitTest.

Imo, the most CPU consuming part of this system will be calculating the arrows position between movements/frames (because it onvolves a large, repeating loop). So far I got this working with pixel-perfect accuracy and I'm only dropping one or two frames (it actually uses your method Malee, so thanks! ).

I'm going to decide between 3 simple methods:

Solution #1:Have an array containing all mc's of grouped obstacles (so 2-3 obstacles per mc). Loop through array to find a bounding-box collision between mc's. If there's a hit break the loop and look for a shapeFlag collision between all obstacles inside mc (this use the loop that I was talking about in the above paragraph). If there's a collision break the loops, find the pixel colour of the shape in collision layer, and act accordingly.
Solution #2:Find a collision between all obstacles and the arrow using a shapeflag hitTest accompanied by a loop to get pixel-perfect accuracy. When a collision is found break the loops, find the pixel colour of the shape in collision layer, and act accordingly. [NOTE: This is the same as solution #1, but ignores all of the extra fuss of grouping mc's as I thought that would be overkill with only 10 obstacles on screen most of the time]
Solution #3:With the use of a loop (to get pixel-perfect results), check the pixel colour of collision layer every step between movements of arrow. I figured this would be OK as long as the getPixel command isn't so demanding on the frame rate.

So yeah, they seem to be the best and simplest options, but i just need to find the most suitable one (solution 1 seems to be the least demanding, followed by 2, and solution 3 comes last (but I'm not completely sure, as I've never experimented with finding pixel colours and such)).

Sorry for making this simple scenario appear to be a lot more complex than what it trully is, but I just want to make sure I'm not throwing away a good frame rate because I took an easy way out.

Viza.

[mr_malee]

putting all hittable objects within 1 mc is a good idea, so you only check for a shape flag hitTest on the movement loop, then when a hit is found go into that mc and find which specific object touched.

Its not like every arrow will be hitting something every frame, so sounds good to me.

remeber you don't need to be super pixel accurate, you can move in steps, but make sure that the step size is never bigger than the smallest enemy/ obstacle and you'll cut the movement loops down heaps.

[Viza]

HAHA. So it looks like after all of those helpful replies I'm pretty much reverting back to my original plan in the very first post ... Unless someone else can point out that one of the other solutions will be just and easy and more beneficial?

Oh and yeah Malee, I've optimized the loop and so far there's no slow down.

Viza.

[mr_malee]

well I dunno, its my personal opinion that the loop method will work better.

anyway, get a demo up so we can shoot stuff

[Viza]

Yup, thanks Malee, That's exactly what I wanted to hear.

Eh.. I wasn't planning to give anyone a peek this early, as there's not honestly a lot to show. Here's a demo of the current build anyway (thanks ever for the quick 'n free hosting): v.4 Firing Test demo

As you can see this is certainly no game yet and there's still a few kinks that needed to be fixed, but you'd be suprised with how much of the core engine is ready... Once I sort a few more things out and have made a couple of levels, I'll show it off again to hear some of your comments.

Viza.

[TOdorus]

Uhm, dead link?

[samvillian]

it is flatlining is what it is...

[Viza]

This one should work:
http://truimagz.com/hosting/viza/Pri...0test%201.html

It was an error with Everfornever's free file hosting.

Viza.