Circle sliding in bitmap... is it possible?
Author
I'm thinking of how to do collision detection & response between a linear moving circle (with constant velocity) inside a black/white bitmap (where black indicates blocked area). I'd like the circle to slide along the walls when collision occurs.
I know how to do collision detection if walls are given as line segments... but how about bitmap? Is it doable in realtime?
Hi!
On the top of my head, im thinking that you just convert your circle position to a position within the bitmap and then just check if the color there is black...
i.e. just load the color data into an array and use it to determine where the walls is using the black color.
On the top of my head, im thinking that you just convert your circle position to a position within the bitmap and then just check if the color there is black...
i.e. just load the color data into an array and use it to determine where the walls is using the black color.
Author
AP: I'm afraid it's not that simple. We need to find the time and position of 1st hit, and find the (approximate?) direction of sliding. It may be a very time consuming task given a bitmap... I'm not sure how to do it.
That'll allow you to check for collisions, but reacting to them is much harder.
Effectively your problem is determining collisions within a regular grid (each grid cell being a pixel in the bitmap). I tried to do this in my last project, but came up against so many problems I abandoned the approach altogether. There are many better ways to do this. Is there a reason you have to do it this way?
Effectively your problem is determining collisions within a regular grid (each grid cell being a pixel in the bitmap). I tried to do this in my last project, but came up against so many problems I abandoned the approach altogether. There are many better ways to do this. Is there a reason you have to do it this way?
Author
Since my artist only have 2D painting software, it's straightforward for him to provide me the game levels in 2D bitmap format. The run-time speed for this game is not a critical requirement, so if this bitmap collision thing is doable (I'm curious how to do it), then I don't bother to write a level design tool for editing walls in vector format.
If this is too hard to do, then I'd definitely do it in other ways.
If this is too hard to do, then I'd definitely do it in other ways.
Ah, so is the bitmap being scaled up to a full sized level? From what you just said, it sounded as if you'll be using the pixel boundaries as walls, in which case you'll most likely not run into the problems I had (which involved fast, small objects that were bigger than the resolution of the grid).
In your case, I'd recommend building some proper geometry after reading the bitmap, rather than trying to use the bitmap itself to collide with. That way, you'll be able to optimise collision tests by implementing spatial partitioning, it'll be a non-hacky way of doing things, and you can optionally use existing libraries to deal with collision detection and/or response.
Does that help at all?
In your case, I'd recommend building some proper geometry after reading the bitmap, rather than trying to use the bitmap itself to collide with. That way, you'll be able to optimise collision tests by implementing spatial partitioning, it'll be a non-hacky way of doing things, and you can optionally use existing libraries to deal with collision detection and/or response.
Does that help at all?
Author
Yeah, no scaling is needed. Pixel boundaries are treated as walls.
I've no idea how to pre-process the bitmap and build "colliding" geometry from it. Any suggestion (other than manually :P)?
I've no idea how to pre-process the bitmap and build "colliding" geometry from it. Any suggestion (other than manually :P)?
wait,
is this a tile based game?
where basically the level is a bunch of tiles, and the tile data is loaded from a color coded bitmap format?
or are you saying that the entire level is one huge bitmap graphic? where the actual bitmap is going to be drawn right on screen?
is this a tile based game?
where basically the level is a bunch of tiles, and the tile data is loaded from a color coded bitmap format?
or are you saying that the entire level is one huge bitmap graphic? where the actual bitmap is going to be drawn right on screen?
Quote:Original post by gamelife
Since my artist only have 2D painting software, it's straightforward for him to provide me the game levels in 2D bitmap format. The run-time speed for this game is not a critical requirement, so if this bitmap collision thing is doable (I'm curious how to do it), then I don't bother to write a level design tool for editing walls in vector format.
If this is too hard to do, then I'd definitely do it in other ways.
Of course its straightforward for him, he isn't giving you any useful collision data.
Seriously, you need your artist/level designer to actually design a level, not just draw pictures.
Unless your level is a heightmap terrain loaded from bitmap, then you Really need to consider an actual level editor with a real level format, one that contains useful collision data....
Author
It's not tile based, the entire level is one huge bitmap (or maybe layers of several bitmaps).
Okay, I guess I had better take the safe way (using level editor)...
Thanks for replies!
Okay, I guess I had better take the safe way (using level editor)...
Thanks for replies!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
