Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: LincolnB on August 25, 2011, 09:40:47 pm
-
Hello,
For a project I'm working on / thinking about (one of three :P ), I made a physics based acceleration/gravity movement engine, inspired by reading through BuilderBoy's physics lessons. I've thought through the game, and the one element I'm having trouble with is working on the collisions.
I can't think of a good way to handle collisions while also avoiding two things: stopping in mid-air above a block, and accelerating right through an object. I would prefer some method based on pixel-test or something like that, but a regular tile map based collision would be fine.
Any ideas?
-
How are the objects in your game able to move (is there rotation), and what shapes will they be? (circles, rectangles, or something else?)
-
Here's a PM from a discussion Builderboy and I had when I first joined Omnimaga. Hope he doesn't mind me reposting it.
So for mathematical collision (which is a must if you are not going the pixelTest way) you just go through several parts of an If Statement.
If X1+W1>X2 AND X2+W2>X1 AND Y1+H1>Y2 AND Y2+H2>Y1
there is a collision!
END
Where X and Y are position and W and H are width and Height. As for collsion velocity tranfer, the equations are this:
V1 = (C*M2*(V2-V1)+M1*V1+M2*V2)/(M1+M2)
V2 = (C*M1*(V1-V2)+M2*V2+M1*V1)/(M2+M1)
Where V is velocity, M is mass, and C is a constant from 1-0. 1 being a perfectly elastic collision (no energy lost) and 0 being a perfectly inelastic collision (objects stick together). Note that when the masses are the same and C=1, the velocities of the objects are swapped. These equations are what i just implemented into Zedd, and they work quite well
-
I don't mind at all ^^ And probably the biggest question is; Do you only have objects colliding with the map, or do they also collide with eachother?
-
/\yeah, objects colliding with one another means that you need to have two loops, one to establish all their locations and then another to check for collisions, rather than just one.
-
I don't mind at all ^^ And probably the biggest question is; Do you only have objects colliding with the map, or do they also collide with eachother?
Just one character to deal with the physics-based collisions is all. There will be enemies that walk around, but I can use a different method for those enemies.
Basically what I've come up with is this: every cycle of the main game loop, after drawing the map (with smooth-scrolling - you'll see why that's a problem in a sec) but before drawing the main character (who is effectively one pixel in size), check to see if the byte below you (found in L6) equals 255 (a straight line of 8 bits). If it is, bounce.
So the code goes something like this: (X and Y are the main character's coordinates, inflated by 256)
Repeat getkey(15)
.Game Logic, movement engine, et cetera. A bunch of crap that works, basically.
ClrDraw
.Draw the tilemap only, not the character or anything
.After that is done...
.set some temporary variables.
Y/256->A
X/2048->B
.X is divided by 256 and then by 8 (256*8 = 2048)
If {A*12+B+L6)=255 or ({A+1*12+B+L6}=255) or ({A+2*12+B+L6}=255)
or ({A+3*12+B+L6}=255) or ({A+4*12+B+L6}=255)
.bounce
End
End
The code works well, however, not with the concept of smooth-scrolling (which I absolutely cannot do without). When I check the byte below the character, to see if it's 255 (which means all bits in the byte are set, thus causing 8 consecutive filled in pixels below the character), it doesn't work unless the horizontal offset (for the smooth-scrolling) is divisible by 8. When it's not divisible by 8, the byte(s) below the character are split between two bytes, and I'm only checking one byte.
My two solutions (I don't like either of them): 1 - use a boatload of Pxl-Test() commands (which I don't really want to do - it'd be slow and a pain in the neck) or 2 - check two bytes below the character, although that would also be a pain and it wouldn't necessarily work all the time (with the way I'm thinking of doing it.
Any other solutions?
Also Qwerty, Builderboy : Could you explain a little more in depth what you posted (reffering to the PM)?
-
Check out the source to SandLand and Stick Ninja (and probably Tag as well); SandLand has a good example of pixel based collision and Stick Ninja is more tile based.
Basically what you want to do is run a For() loop for the length of the current velocity, checking at each point for a collision. I always run the For() loop in pixels even though my engine might be inflated to save on speed. Then if a collision is found, the coordinate is adjusted slightly to rest exactly on the pixel or tile (since it's relatively inaccurate collision testing), and if not then the original inflated velocity is added to the coordinate.
-
Theoretically, you could completely avoid the issue of falling through blocks if you had a super-optimized engine, that had its terminal velocity set at 1 px per frame. Then any slower would be delays, not skips......
Thoughts? It's probably insane to expect on an 84+ :P
-
Thats what PortalX did and it ran in 6Mhz :) And for Zedd, which is my more versatile physics engine, if it ever detected an object was colliding with any number of other objects, it just moved the object back to its original position, that way you were guaranteeing that your objects would never manage to end up inside eachother
-
Would you be able to push multiple objects that way? It seems they'd get stuck next to each other.
-
You tell me 8)
(http://www.omnimaga.org/index.php?action=dlattach;topic=2068.0;attach=3819;image)
-
+1 for epic screenshot response and using the " 8)" emoticon
-
(http://www.omnimaga.org/index.php?action=dlattach;topic=2068.0;attach=3819;image)
Holy crap.
-
(http://www.omnimaga.org/index.php?action=dlattach;topic=2068.0;attach=3819;image)
Holy crap.
Well said.
Builderboy, do you remember what that screenie was from? I remember it from something. Was it Zedd?
-
Yeah it was a demo screenie from the 2nd revision of the Zedd engine ^^
-
It looks like the blocks don't all have the same densities...O.O
-
They all have the same density, rather, their different sizes mean they all have different masses :)
-
ok, so mass is based entirely on size? Makes sense.
-
Well actually mass is independent of size, but in that simulation I set all the masses such that they all have the same densities
-
Ah, so it does have different densities, but it's a variable dependent on the mass?
-
Each object has a specific variable for mass, which is independent of size or anything else. Density isn't an actual variable, its just a way I describe the objects relationship between size and mass.
-
So you can make a 1pix*1pix object with 99 mass that you throw at a stationary block that takes up half the screen and has 1 mass and the larger object bounces around like a pinball. Fun ;D
(Is zero mass possible? What's the max?)
-
Zero would cause some... problems :P Max is around 24 or so before overflow errors start happening
-
hmm, would overflow errors cause it to reverse direction when hit (signed #) or simply slow down a lot? (in case of 1 var for direction, 1 for magnitude)