2d sidescroller (collision detection)
Author
how to make a 2d level (bigger than the screen) and have efficent collision detection.
I was originally using a collection class and randomly placing object along the screen and looping through the collection class to see if the player hascollided with any level object in the collection class.
I wanted an easier and more efficent way of doing this.
I was thinking of making a huge picture and just putting it on the screen and scrolling along it but I would know how to do collision detection since i couldn't put a e.g. square/rectangle around it.
p.s. what technique did there use on sonic 2d games?
thanks for looking
later
UF
Hi,you may want per-pixel collision detection.Making a masked array of the map and objects,like :1 if there is pixel,0 if there is nothing.
In sonic ,like most 2D games ,they use tiled-base maps.They are squared bitmaps of 16*16 /32*32 pixels for example.You check if the player's bounding box collides with some of the objects' such box,and if it does you may want to perform further per-pixel check .
In sonic ,like most 2D games ,they use tiled-base maps.They are squared bitmaps of 16*16 /32*32 pixels for example.You check if the player's bounding box collides with some of the objects' such box,and if it does you may want to perform further per-pixel check .
For collision systems, you want the collision checks themselves to be as cheap as possible, but you also want to limit the number of collision checks as much as you can. When there's a thousand objects a mile away, why check against them?
For that reason, people often divide their world into smaller area's, and they then keep track of which object is in which area. This is commonly called 'space division', and for 2D situations, you can use a quadtree or something similar. When you're inside a node, you only check against the objects in the same node and in the parent nodes. Granted, you'll have a few extra checks agains the node boundary boxes, but these checks prevent you from checking against a lot of other objects, which can lead to a good performance gain.
For that reason, people often divide their world into smaller area's, and they then keep track of which object is in which area. This is commonly called 'space division', and for 2D situations, you can use a quadtree or something similar. When you're inside a node, you only check against the objects in the same node and in the parent nodes. Granted, you'll have a few extra checks agains the node boundary boxes, but these checks prevent you from checking against a lot of other objects, which can lead to a good performance gain.
Quote:When there's a thousand objects a mile away, why check against them?... These checks prevent you from checking against a lot of other objects, which can lead to a good performance gain.Is performance even an issue with 2D games, these days? I agree that a quadtree would definitely improve performance, but isn't that a little bit overkill?
Quote:Original post by KG_BradQuote:When there's a thousand objects a mile away, why check against them?... These checks prevent you from checking against a lot of other objects, which can lead to a good performance gain.Is performance even an issue with 2D games, these days? I agree that a quadtree would definitely improve performance, but isn't that a little bit overkill?
Depends. Let's say you're creating a real-time strategy game with hundreds, maybe even thousands, of units which all need collision checking and response with the environment and each other.
With 100 moving objects, you end up with 10.000 checks per frame already. With 10 moving objects and 1.000 static ones, you end up with 11.000 checks per frame. It depends a lot on the game whether or not it will be an issue, and with somewhat large and complex levels, a platformer can get trouble with this just as well.
But yeah, if collision takes just a few percent of the total frame-time, then implementing a quadtree for a 60% performance gain will only yield you a few percent in total. Profile your code before optimizing it, but also build your code so, that it's not hard to implement such optimizations later, when they're needed.
But yeah, if collision takes just a few percent of the total frame-time, then implementing a quadtree for a 60% performance gain will only yield you a few percent in total. Profile your code before optimizing it, but also build your code so, that it's not hard to implement such optimizations later, when they're needed.
In my games, I store the location of solid tiles in an array. When I move a sprite, it checks if the location the sprite is moving towards is occupied by a solid tile. If so, the sprite doesn't move. If not, it moves to that location. It might not be the best method of collision detection, but it gets the job done.
I was thinking of doing a grid-based system. My game (2d) has tiles that are 256x256. The server maintains a list of tiles in the game space, and within those tile squares there is a list of object IDs.
Only those object IDs, if there's more than 1, are tested against each other (and there are more filters from there, certain flags... such as stationary objects or non-collidable objects).
On the side I keep track of player characters (this is an mmo-type game), and only collide objects deemed in their "relevant" range (for replication), otherwise, the server performs no collision checks, since there's no players around to see them.
Well, this is the outline design, it's not in full force... yet.
I think the basic principle is what Captain was saying... use a quad tree, or some other sort of segmentation, to build object relevance... Don't test an object to another object if it doesn't make sense to.
That alone will increase performance tremendously. On top of that, box or sphere collisions are extremely quick if you don't mind them being a bit on the innaccurate side as far as shapes. If you need pixel-perfect collisions, it'll cost a bit more, but it'll look better.
Clanlib has an interesting way to handle collisions, using outlines (scalable and rotatational).
www.clanlib.org
Only those object IDs, if there's more than 1, are tested against each other (and there are more filters from there, certain flags... such as stationary objects or non-collidable objects).
On the side I keep track of player characters (this is an mmo-type game), and only collide objects deemed in their "relevant" range (for replication), otherwise, the server performs no collision checks, since there's no players around to see them.
Well, this is the outline design, it's not in full force... yet.
I think the basic principle is what Captain was saying... use a quad tree, or some other sort of segmentation, to build object relevance... Don't test an object to another object if it doesn't make sense to.
That alone will increase performance tremendously. On top of that, box or sphere collisions are extremely quick if you don't mind them being a bit on the innaccurate side as far as shapes. If you need pixel-perfect collisions, it'll cost a bit more, but it'll look better.
Clanlib has an interesting way to handle collisions, using outlines (scalable and rotatational).
www.clanlib.org
You're making an MMO that's a sidescroller? I've never seen any before, so hopefully you're the first!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
