Alternative to ImagesCollide
BlitzMax Forums/BlitzMax Programming/Alternative to ImagesCollide
| ||
| Hey folks! I need an alternative to the ImagesCollide function. I'm making a Grand Theft Autoish game(It's 2D), with a fairly sizable city, and a bunch of little fellas walking around. I need the cops, player, and civilians to be able to collide with the city. What I'm doing right now, is simply recording their x and y coords every frame, and if they collide with any portion of the city their current x and y is reset to the recorded x and y. Thus placing them back where they were before they collided. However this runs very slowly since it has a lot of little guys to check. As soon as I comment out the collision checking line of code it works just fine. So. What other options are there? I can't simply check the city's x and y and the little guys x and y, since the city is comprised of a single image, with several different buildings and the little guys will be colliding with at least portions of the city very often. I suppose I could hard code the exact coordinates of each buildings outline, but that would be very time consuming. Are there any quicker options? Thanks! |
| ||
| use box2d or chipmunks |
| ||
| [edit, after re-reading your post] I would look into automatically generating the (hardcoded) coordinates of the buildings. Perhaps you can create a black&white overlay for the image, and then use a separate parsing program to scan the image, and export this data to a file. |
| ||
| I hope you don't feel offended by this but ImagesCollide and one Large image to collide all objects against is the worst method for collision in a game. When you get a chance look at the max2d source module and you will see what I mean. Your best bet for something like that is to use tiles and some sort of rectangle collision detection. if you insist on doing it your way I suggest you create your own pixel color detection method for collision which can easily be done on pixmaps. |
| ||
| use box2d or chipmunks Checking them out now :) @Warner Ecch, looks like that might be what I have to do. Oh well, it shall be a good exercise for me. @Jesse Worry not about offending me, when you're simply giving your opinion along with good advice. I do insist upon doing it this way, because I am doing something fairly experimental with this game. The entire level image, is a 100x100 image. In game it's scaled by a factor of 60 so that might account for some of the slow down when collision checking. Creating a pixel detection method sounds intriguing. I must investigate all 3 suggested options. Thanks folks! |
| ||
| Divide the city into larger chunks and only check for collision in that chunk and adjacent chunks. |
| ||
| Dont bother with collisions unless the play can see that bit of the map |
| ||
| Dont bother with collisions unless the play can see that bit of the map and movement by that matter. |
| ||
| I figured out what to do(Basically). I'm using the minimap of the city to calculate collisions, with single red pixels to represent the enemies. If imagescollide is still too slow even with them, I can fairly easily switch over to pixel color detection. Thanks again! |
| ||
| There is a collision mod here: http://www.rigzsoft.co.uk/index.php?option=com_content&view=article&id=44&Itemid=25 "collision.mod - Powerful collision module for box, circle, line and poly collisions, including a fast quadtree system" But I have self never tested it. |
| ||
| If you are using Imagecollide to see if single pixels are colliding with the map, then YES you are using the wrong thing. How about making the minimap a pixmap and reading pixels |
| ||
| Already have it handled :) Using imagescollide on the minimap seems to work out just fine, with no slow down. Thanks everyone! |
   |