someboddy

OK, thanks!

Or do they allocate/release memory each time you push/pop?

Quote:Original post by Numsgil You then put the tentative collision pair into a "collision heap" (again, Chapter 2). If a collision "lower" (sooner) in the heap causes either body to change motion, you find any collision pairs in the heap which might be affected (directly or indirectly) and recalculate them. It causes a sort of "cascade" update, so if two bodies are in isolation somewhere in the simulation you don't have to conservatively advance the entire world. I haven't read Mirtich's thesis yet(I'll do it later), but that was my basic idea. Great minds think alike, I guess... Quote: Using the outer and inner bounding spheres' windows of collision, I'm thinking you can use some more aggressive root finding methods, but I'm not sure what they would be just yet. That's brilliant, Numsgil! At his first reply, snake5 suggested I do a binary-search-like algorithm to find the time of intersection, but I didn't like it, because if, lets say, a bullet is supposed to move 10m. at a certain frame, and it is distanced 5 meters from a 2 meter wide wall, they won't intersect neither at the beginning nor the end of the frame. However, if I use the outer bounding circle time and the inner bounding circle time(or the time when they are closest, if they don't collide) as the search frame, this idea might work! snake5 and Numsgil, thank you very much! I'm gonna try that later.

Thanks... I guess I should just use old method of checking the penetration depth...

Yea... rotation is my main problem here. Two rotations, actually...

O.K., I'm stuck. The problem is that both my polygons are moving and rotating(I asked about segments because I thought it'll simplify things, but what I really want to check if for polygon intersection). Anyways, I've tried that separating axis thingie, but I got stuck at this equation: That I need to apply for each point in one polygon, and each segment in the other polygon, to check when will the point touch the segment(if at all). h is the height of segment that is used as axis, from the center of it's polygon. alpha is the angle of that segment. C is the center of the polygon that contains the point. v is the relative velocity between the polygon that contains the point and the polygon that contains the segment. p is the position of the point, relative to the center of it's polygon. omega is the rotation speed(in radians) of the polygon containing the segment. delta omega is the relative rotation speed(also in radians) between the polygon containing the point and the polygon containing the segment. And, ofcourse, t is the time. All values, except time, are parameters. I need to find the time. With such a complex equation, is it even possible?

Thanks! I'll look into it later.

Quote:Original post by snake5 Here are some algorithm that are in my mind right now... Make one of the lines static by calculating the relative velocities between those lines. Make a polygon out of the "dynamic" line. It might be a concave polygon too if you use rotation. Then check if those objects intersect and calculate the time of collision using the intersection points. I thought about it, but it won't work on fast rotating segments. Quote: OR Do a binary search using a simple static line vs static line intersection test (you still should make one of the lines static) - move the "dynamic" line to time t=0.5 (start being 0.0 and end - 1.0 here). If it collides, subtract a half of the time, if it doesn't add a half of the time between currently used time and previous time (for the first iteration - 0.0). Use as many iterations as you need. Sounds nice, but it won't work on very fast moving segments, that can be on one frame in one side of a polygon and on the next frame on the other side. Quote: OR Make the lines "fatter" and use a moving polygon-polygon intersection test. Now, that sounds interesting. Can anyone elaborate more about that "moving polygon-polygon intersection test"?

Howdy everybody! I have two 2D segments. Each segment has a velocity and a rotation speed. The segments are represented by two vectors - one for each end - the velocity by a vector, and the rotation speed by an angle/time scalar and a vector for the axis - but I can change the representations to whatever needed. Anyways, what I need to know is when(if at all) those segments are going to intersect, if they continue at their current velocity and rotational speed. I tried to calculate it myself, but my math skills are not strong enough... is it even possible? Is there a formula or algorithm or something? Thanks in advance!

How would Zero contribute to the gameplay? Will he do combo moves with Cypher, or will you be able to take control over him and move him separately to places only a wolf can go?

The first language you should learn is English.

You do this after the chain of ifs, when the values of AB are already set. Take a look at this picture: The right part of the picture is the screen. The green area is the collision are between the bounding boxes of the two sprites, and is represented by AB. You calculate the relative position of A from the AB(notice that in this case, relativeA.x and relativeA.y are negative, because A is located up and left from AB). After that, you draw A to tmpA - the left part of the picture. You draw it at relativeA, so only the section of A that is colliding with B will be drawn to tmpA, and it will be draw at the correct location. You do the same thing with B, and you'll have two SDL_Surfaces that represent the colliding sections of tmpA and tmpB. You know what to do from here...

Maybe you can declare that if one of the fields in the creature's database is 0(or -1, if you want to allow 0 valued fields), than that field should be looked up at the base creature's row. For example, if you set Orc Thumpers' height to 0, than it's height should be Orc's height.

Well, take a look at those lines: SDL_BlitSurface(m_Sprite->getBitmap(), &AB, tmpA, NULL); SDL_BlitSurface(obj->getSprite()->getBitmap(), &AB, tmpB, NULL); You draw both sprites at the same position on tmpA and tmpB. You do your calculations as if both sprites' x and y positions are the same - and usually they aren't. You should do something like this: SDL_Rect relativeA; relativeA.x=A.x-AB.x; relativeA.y=A.y-AB.y; SDL_Rect relativeB; relativeB.x=B.x-AB.x; relativeB.y=B.y-AB.y; SDL_BlitSurface(m_Sprite->getBitmap(), &relativeA, tmpA, NULL); SDL_BlitSurface(obj->getSprite()->getBitmap(), &relativeB, tmpB, NULL); You can use the rects A and B instead of making new ones, but I gave them new names to make it easier to understand.

Inline functions must be implemented in the same file they are declared. Either drop the inline or put the function's body in the header file.