game-editor.com

we seem to have so many problems with collisions but Nintendo games almost never glitch
what did they do different.

I have no idea, but I think it's because they use better tools and work together(I mean, have you ever seen the credits lists of their games? It takes like 50 people just to make 1 minute of bgm)

1. Cap all velocities. Do not allow an object to move fast enough to glitch the collision system. Do not allow an object to move fast enough to be more than halfway through a block from one frame to the next.

2. Use same sized objects for all collisions - all the platforms, etc. Should be same sized blocks so collision results will be predictable. Remember that the 8x8 sprite size in the NES games meant you were ALWAYS comparing two identically sized objects, even if it was a bullet etc. in which the majority of the pixels were transparent.

3. Do not allow random acceleration. All accelerations should be on a speed/time scale that's constant for all characters. This is hardly noticeable, but it's there. You'll find similarities between running speeds and bullet speeds on many NES games. If you jump with mario, you will see him appear in a limited number of pixel spots, but not every pixel spot. It's never left to chance.

4. Don't allow random return velocities either. No physical response type of things. Speeds from collision bouncebacks should be identical to the speeds normally attained, capped and on the global speed/time scale.

5. Simple pixel overlay tests=better collisions. The nes was comparing 8x8 blocks of sprites for collision overlap. The png's we use for graphics today are, by comparison of pixel quantity, huge. This means we tend to use collision routines which bail on the first overlapped pixel found - instead of continuing to test for all overlapped pixels, and determining which is the most relevant, because doing so is incredibly slow when using large amounts of pixels. Remember that 2x resolution = 4x the number of pixels.

Basically, everything is standardized and limited to fit within the requirements of the collision system. And games that didn't - and there were plenty - had poor collisions and glitchy results.

Testing. They did it with testing. I'd bet most of those collision systems are nowhere near as perfect as they seem, they just make sure nothing that could break the rules ever gets to exist in game. DST's #1 is the most important and holds true for 3d as well. I spent a lot of time trying to make a perfect environment for 3d physics in Blender, but no matter how precise my calculations were set there was always a break point. This figures, even calculating physics like 300 times a second is a poor imitation of the precision of real world action. It doesn't need to be perfect it just needs to be perfect for all objects extant in game.

BTW unless I am gravely mistaken the velocity cap for the fastest objects in your game should be half the frame rate. If your goal FPS is 32, nothing should try to move faster than 16.

That said, I hate to contradict the great DST but I feel points 2-4 are more good general practice than things to hold as absolutes. #2 is important in 3d but never something to stress over. Honestly I'm not quite sure of the logic behind 3 and 4, if you keep to 1 they shouldn't matter. Random is okay, uncapped is not. My bullets use random variance, particularly the shotgun, no issues so long as I make sure that variance never causes them to move at game breaking speeds.

5 is the one I have questions about. Given that it sounds like the best way is to make everything super tiny. But that sacrifices graphical quality. A bounder graphic could be simpler in shape and non-animated but would have almost as many pixels. In 3d you use a lower polygon model for the bounder, but there is no good 2d equivalent to that method since I can't make the bounders operate at a lower resolution.

On a related note to 5, I've been using calculate mass in physical response. This is fine most of the time. However sometimes during a massive cluster collision I see a slowdown. My question is, how does calculate mass work and does it exacerbate this? It uses mass by frame but does it actually have to recalculate the mass on the fly each collision? At first it seems a nice convenience but I'm wondering if a hand-assigned mass would be more accurate and faster.

Code: Select all

xvelocity += collide.directional_velocity*cos(2*PI*((360-(180+direction(x,y,collide.x,collide.y))/360)));
yvelocity += collide.directional_velocity*sin(2*PI*((360-(180+direction(x,y,collide.x,collide.y))/360)));

Is a 'simple' method of transfering movement to another object with the same mass. If mass were to differer, it wouldn't matter how much there is, you'd need to take into account of the ratio between the mass of the two objects.

Exemple a 50g boulder hits a 25g boulder. the 50g will loose half it's speed other than all of it while the 25g boulder will move at the same speed the 50g boulder used to.
Why is this happening? It's because 25g of movement (The number of atoms in movement) were transfered to the smaller boulder while the other 25g of movement remained inside the big boulder.
Why did the big boulder slowed down? the 25g of movement got dispersed over the 50g, thus making it slower.

Even though these are observations made on the spot... They're probably true to the laws of physics.

So to calculate mass in self-made collision system, you'd create a variable holding the mass of the objects

Hopefully this post was at least a bit revelent <_<

AnarchCassius wrote:That said, I hate to contradict the great DST but I feel points 2-4 are more good general practice than things to hold as absolutes. #2 is important in 3d but never something to stress over. Honestly I'm not quite sure of the logic behind 3 and 4, if you keep to 1 they shouldn't matter. Random is okay, uncapped is not. My bullets use random variance, particularly the shotgun, no issues so long as I make sure that variance never causes them to move at game breaking speeds.

5 is the one I have questions about. Given that it sounds like the best way is to make everything super tiny. But that sacrifices graphical quality. A bounder graphic could be simpler in shape and non-animated but would have almost as many pixels. In 3d you use a lower polygon model for the bounder, but there is no good 2d equivalent to that method since I can't make the bounders operate at a lower resolution.

You aren't contradicting me - the question was 'how did nintendo do it', rather than how should you do it.

The thing about random velocities is that you're just asking for ...well, randomness. Randomness is an enemy to predictability. A good program has very little randomness in it, but works in such a way that the user sees lots of random. Artwork and music are the same - a warrior's blade or shield may have random chips taken out of it, but likely the illustrator plans those out carefully.

5 isn't something we can necessarily do anything about. It's just the way of modern computing. If they used bits to store states of an object in old 8-bit games, and we use a single 32 bit integer just to store one single facet of an object...Well that's 32 times the data for the same effect. (i. e. canjump = 1 or 0 but canjump is 32bit integer....).

We shouldn't go back to graphic simplicity by any means, but it does mean more complexity in everything we do, that's all.

First of all thanks to DST for outlining these very important topics regarding collision detection. Collision detection is not trivial.

GE's collision system is called "pixel perfect". It does go down to a pixel level and compares every single pixel if objects intersect.
This is a exact system but not the most efficient in some cases. Many games wouldnt require tests to go down to a pixel level.
In my eyes this system is perfect. Have seen many other collision systems much much bader than this.

I tried to replace it with a occlusion query system which is supported by most of the opengl grafic cards. It turned out that the opengl
way was slower than the cpu way which is implemented in ge!!! I wanted to have this because the new ge supports scaling and rotating.
Therefore its very hard to continue with the bitmap driven pixel perfect system. Pixel perfect systems use sprite mask to compare.
Each time you change a sprite e.g. with rotating and scaling this mask would need to be recomputed. So I dropped the occlusion query system.
It was very hard to code and took me a lot of time to get the prototype running.

Now ge1.5 uses a vector based collision system *in addition* to the old one. The pixel perfect enging will persist and be unchanged
not only for compatibility reasons.
Complicated sprites will require a wireframe boundary which will be called collision path in future. This path needs to be set in the actor
settings and will approximate a sprite (e.g. a pic of a car) vector based. I came to the conclusion after studying a lot of collision systems
that this is the fastest one and most compatible one without the need to have opengl supporting occlusion queries.

Simple bodies will calculate their collision path automatically by calling "b2CreateDynamicBox()" or "b2CreateDynamicCircle()". Easy.

So what I want to say is that collision detection is not trivial. Its not only the engine which needs to be perfect. Also the user in front
of the screen needs to be aware of what he is doing to prevent tunneling effects like DST described.

Here is what will come in ge1.5. This was adopted from box2d. Thanks to Erin Catto for this wonderful piece of code and how it handles tunneling:

"Bullets

Game simulation usually generates a sequence of images that are played at some frame rate. This is called discrete simulation. In discrete simulation, rigid bodies can move by a large amount in one time step. If a physics engine doesn't account for the large motion, you may see some objects incorrectly pass through each other. This effect is called tunneling.

By default, Box2D uses continuous collision detection (CCD) to prevent dynamic bodies from tunneling through static bodies. This is done by sweeping shapes from their old position to their new positions. The engine looks for new collisions during the sweep and computes the time of impact (TOI) for these collisions. Bodies are moved to their first TOI and then halted for the remainder of the time step.

Normally CCD is not used between dynamic bodies. This is done to keep performance reasonable. In some game scenarios you need dynamic bodies to use CCD. For example, you may want to shoot a high speed bullet at a stack of dynamic bricks. Without CCD, the bullet might tunnel through the bricks.

Fast moving objects in Box2D can be labeled as bullets. Bullets will perform CCD with both static and dynamic bodies. You should decide what bodies should be bullets based on your game design. If you decide a body should be treated as a bullet, use the following setting."

I noticed that in the demo and was wondering if that was what it did. Thanks for the info. Also that bullet effect sounds amazing, properly used it sounds like it should eliminate tunneling and fall-through altogether. Is there any ETA on these features being usable in exported games?

what if we made another physical response that was a basic this cant go through this
so that one pixel moves past the other it would just put it back
and not have it calculate angles and such

the collisions on GE are the best they can get for lazy people who dont want to work with angles and speeds, you simply have to deal with that.