Page 2 of 3
Re: Thinking clearly about collision detection
Posted: Tue Jan 15, 2013 11:34 am
by Denine
tepples wrote:
MarioWiki.com
This glitch is caused by the collision detection routine not seeing that the lower left corner of Mario is within air when Mario comes out of the crouch.
Ok, but individual 16x16 (pixel) boxes(such a coin block) can do the thing I have in mind, too
In
this video the guy uses the fact that coin block box pushes the player to the left to bring mario closer to the right part of the screen.
Which shape(0-F) is the one that makes this trick possible? Guess it's....01?
Re: Thinking clearly about collision detection
Posted: Tue Jan 15, 2013 11:39 am
by Brickman
Interesting article on MCKid's development with a section on sloped collision:
http://games.greggman.com/game/programming_m_c__kids/
Re: Thinking clearly about collision detection
Posted: Tue Jan 15, 2013 12:25 pm
by Bregalad
I have actually set a size/speed limit in my game as a work around. Objects which can collide with one another must not be smaller than the number of pixels they will move per frame (actually, half of that, I believe). Typically, I don't have objects smaller than 8x8 pixels, and I don't have anything moving close to 8 pixels per frame (or even 4, for that matter).
Hehe, it sounds like it would be "collision alasing".
But the problem is that if you want for example an enemy to move 3 pixels in a direction, and that there is a collision, does it means the enemy can't move ? Of course not, because the enemy could possibly move 1 or 2 pixels in the same direction, and if this is possible, you definitely want it to do that.
Because of this, I think the simplest way is to do it one pixel at a time. Of course it's lazy and inefficient, but my game is not a shooter that will requires lots of fast moving bullets at the same time so I don't care.
Rotating levels aren't any harder provided the object and camera positions are stored in "world space", relative to the origin of the map.
Now that you mention it this is right, you only have to rotate the gravity, and the display. However I still think it is complex to do, and I still show much respect for programmers of SCV4 in this regard.
Re: Thinking clearly about collision detection
Posted: Tue Jan 15, 2013 1:08 pm
by tokumaru
Super Ghouls 'n Ghosts also has a rotating level... Just the other day I was wondering how I would handle a situation like that.
Re: Thinking clearly about collision detection
Posted: Tue Jan 15, 2013 1:38 pm
by Denine
tokumaru wrote:Super Ghouls 'n Ghosts also has a rotating level... Just the other day I was wondering how I would handle a situation like that.
You mean handling collisions in a rotating level? I beat the game and I can only remember
rotating in Level 4, but it immobilizes the player, so no collisions check are actually needed...
As for me-I would never be able to calculate collisions for rotating level...
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 11:32 am
by Celius
Bregalad wrote:I have actually set a size/speed limit in my game as a work around. Objects which can collide with one another must not be smaller than the number of pixels they will move per frame (actually, half of that, I believe). Typically, I don't have objects smaller than 8x8 pixels, and I don't have anything moving close to 8 pixels per frame (or even 4, for that matter).
Hehe, it sounds like it would be "collision alasing".
But the problem is that if you want for example an enemy to move 3 pixels in a direction, and that there is a collision, does it means the enemy can't move ? Of course not, because the enemy could possibly move 1 or 2 pixels in the same direction, and if this is possible, you definitely want it to do that.
Because of this, I think the simplest way is to do it one pixel at a time. Of course it's lazy and inefficient, but my game is not a shooter that will requires lots of fast moving bullets at the same time so I don't care.
Well, if we're talking object to BG collision, there is a displacement routine that checks how far the bounding box is sticking into the solid wall, and moves them in the opposite direction that many pixels. Depending on the scenario, it might certainly be easier to just not allow them in, in the first place. This can be done by moving them one pixel at a time, like you were saying.
And since my game is a platformer, with upwards of 8 enemies + projectiles on the screen at one time, it can be tricky to manage time, so moving one pixel at a time wouldn't work. But for a static screen game, it would definitely be easier. And there comes a point where if the engine doesn't require increased efficiency, it's ok to be lazy

.
Denine wrote:tokumaru wrote:Super Ghouls 'n Ghosts also has a rotating level... Just the other day I was wondering how I would handle a situation like that.
You mean handling collisions in a rotating level? I beat the game and I can only remember
rotating in Level 4, but it immobilizes the player, so no collisions check are actually needed...
As for me-I would never be able to calculate collisions for rotating level...
It might actually be easier to see the objects as being rotated in relation to the level. Then again, I've never done collision detection for an object with a rotated bounding box. You might also use a square bounding box that just changes dimensions as the objects rotate, to more appropriately accommodate the object it houses.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 12:01 pm
by Bregalad
Denine wrote:
You mean handling collisions in a rotating level? I beat the game and I can only remember
rotating in Level 4, but it immobilizes the player, so no collisions check are actually needed...
As for me-I would never be able to calculate collisions for rotating level...
Pardon me but it sounds like this should have been a joke to code. The hero is immobilized during the rotation, and the rotation only do it 90° at once.
Look what a real rotating level looks like :
http://www.youtube.com/watch?v=EAkSpq0FZJE at 1:35
Then at 3:25 you have 2 layers.
and here too :
http://www.youtube.com/watch?v=jkKDPFUUDHU at 1:05
Now THIS should have been hard to code.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 12:35 pm
by tokumaru
How is this different from what Super Ghouls 'n Ghosts does? Can you release that switch before the level snaps to a multiple of 90 degrees?
Then at 3:25 you have 2 layers.
I don't see anything rotating at 3:25 besides the funky tunnel background.
Doesn't seem so hard... there are no walls to collide with, the slope doesn't cause the player to slide down, and the movement is jerky as hell.
For a second I though you were going to point me to a level that worked at odd angles, filled with objects moving around and properly colliding with slopes and walls. That would've been impressive. I really don't see how this stuff in Super Castlevania 4 is way more advanced than what Super Ghouls 'n Ghosts has.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 12:41 pm
by Bregalad
How is this different from what Super Ghouls 'n Ghosts does? Can you release that switch before the level snaps to a multiple of 90 degrees?
Yes you can. And the collision detection is not only with walls, but also with spikes. It's true there is no enemies DURING the rotation, but come on. This is still very impressive.
I don't see anything rotating at 3:25 besides the funky tunnel background.
Nothing rotating but pehaps if you wait until 3:30 then you will see 2 independents backgrounds, which should have been hard to code for collision detection. You can also die by being crushed between both backgrounds.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 12:47 pm
by MottZilla
The rotating of the level in Super CV4 has very limited collision going on while the level actually rotates. There is the ground plane that you need to escape by whipping the hold. It gradually slopes and I believe eventually you'll slide off and die. Then it rotates once more where again you'll slide off the small platform and fall to your death if you don't whip the hold. There isn't a whole lot going on. I'm not sure how difficult it would be to program something to handle this. You may not need to involve the background map array at all, you could simulate these things were game objects that you don't actually see as sprites. The big swinging things in the later level are just some kind of game object platforms that behave in that swinging pattern probably.
So I'd agree that neither game does anything completely amazing with scaling while actually navigating a level. It's just a visual effect but in practice probably only the minimal amount of effort to compute whatever needs to be done. I think you'd need a coprocessor to calculate everything if the whole level was rotating without some sort of tricks. But then again those tricks are part of the fun of figuring out how to do such effects.
The two backgrounds at the 3:30 mark, the scrolling up part actually might be sprites. The SNES has enough sprites per line to do that. All the pieces moving up could be game objects that it tests collision with.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 5:09 pm
by tepples
The part with two background layers was done in some of the castles in Super Mario World. What you need to do for levels like these is run collision against both layers, then make sure the push vectors returned by the algorithm don't point in opposite angles.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 8:37 pm
by tokumaru
Bregalad wrote:Yes you can.
I'm curious to see what that looks like... is there a video?
2 independents backgrounds, which should have been hard to code for collision detection.
My initial though was to just check for collisions against both planes and react as normal. Crushing happens when one layer ejects you into the other.
Re: Thinking clearly about collision detection
Posted: Wed Jan 16, 2013 9:40 pm
by Sik
tokumaru wrote:How is this different from what Super Ghouls 'n Ghosts does? Can you release that switch before the level snaps to a multiple of 90 degrees?
At 2:17 the level starts rotating while the player is still on the floor, giving away that the game has at least to be able to handle such stuff.
tokumaru wrote:My initial though was to just check for collisions against both planes and react as normal. Crushing happens when one layer ejects you into the other.
I believe this is exactly what happens in Sonic & Knuckles in Sky Sanctuary (except for the crushing part as maps can't crush you, only objects - that's why there are some invisible solid objects in some areas).
Re: Thinking clearly about collision detection
Posted: Thu Jan 17, 2013 11:04 am
by Celius
Sik wrote:tokumaru wrote:How is this different from what Super Ghouls 'n Ghosts does? Can you release that switch before the level snaps to a multiple of 90 degrees?
At 2:17 the level starts rotating while the player is still on the floor, giving away that the game has at least to be able to handle such stuff.
Another thing that must be tricky is factoring in gravitational effects. If you're standing on the platform as the level rotates, do you end up sliding off? Or do you stay on it until it is completely rotated 90 degrees?
Re: Thinking clearly about collision detection
Posted: Thu Jan 17, 2013 2:41 pm
by Bregalad
I'm curious to see what that looks like... is there a video?
I don't know but honnestly you should just play the game. It's one of the best on the console, and I'm not the only one who is in this opinion. And it's really quite easy, especially at the beginning, so you shouldn't have trouble passing the first 3 levels if you are a platformer veteran.