Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 16 Jan 2012
Offline Last Active Today, 10:22 AM

Posts I've Made

In Topic: Multithreaded mesh loading and 0xcc returned from glGenVertexArrays

Today, 09:25 AM

You can't use the same context in multiple threads at the same time. You can "release" a context and "bind" it to another thread but that obviously makes you unable to use it in the original thread. You can however use multiple contexts and have them share resources with each other wich is propably what you want.



In Topic: cross shader

27 March 2015 - 04:42 PM

If I draw the stars each with its own texture and quad, even if I draw the "cross" in a shader, I don't benefit of parallelism, as the stars are drawn sequentially.

Yes and no. The vertex shader does infact work on multiple vertexes in parallel and the fragment shader will also be working on multiple pixels in parallel. If you use a textureatlas and put all the stars in a single vbo you can issue a single drawcall to draw all the stars and the shaders will do it all in parallel. You will most likely get more performance this way as it doesn't have to work on all the pixels in the "void" space and you can predraw the cross in the textureatlas so you don't have to do any blur shaders.

In Topic: Handling collisions with multiple bodies and unwanted collision with internal...

05 March 2015 - 03:02 PM

Sorry I made a mistake in the calculation of t. The length of the penetration vector was supposed to be divided by the y component of rotatedvelocity.


Also I chose the vector (0,1) for the surfacenormalrotation so we can use the y component of the rotatedvelocity. You can use vector (1,0) if you want but then you need to use x component from the rotatedvelocity. This rotation is done so we can treat the surfacepenetration as an axis aligned vector so we can compare a single component from velocity vector to the length of the surfacepenetration.


Also in the unlikely event where t happens to be larger than 1 or rotatedvelocity.y is 0 then the chosen surface was invalid and you need to choose a new one. This can happen if we approach from an angle that is too steep compared to the penetrationvector wich means that blue could not have come from that direction in the firstplace. If you can't find a surface that results with t between 1 and 0 then blue was already inside red before it even moved.


Please note that the only valid surfaces are those that are between two adjacent corners of blue or two adjacent corners of red if we are evaluating surfaces of blue. It must be done both ways or otherwise you miss the collisions where a corner of red is inside blue



i think it will not work for circles


This does work on circles. Altough it can require multiple iterations(solve t and move blue backwards a lot of times until it finally is outside) and could take a long time but it will eventually get there.



But what if the blue body moves straight from up to down?


This shouldn't require any special handling.


Oh and because floats and doubles(64bit floats) can be a bit inaccurate at times you may need to modify the calculation of t by adding a little padding.

float t=0.001+abs(surfacepenetration.length/rotatedvelocity.y)



Another thing that comes to mind is that when choosing the surface you could try to optimize it by choosing a surface where the angle between the surfacepenetration and velocity is closest to pi radians or 180 degrees instead of the shortest one. In most cases they are the same but there are some cases where t will be over 1 if you use the smallest penetration length and in these cases choosing a surface where the angle between surfacepenetration and velocity was closest to 180 degrees would have been the correct one.


Also instead of checking if a surface is between two adjacent corners you can just check if the angle between the surfacepenetration and velocity is over pi/2 radians or 90 degrees as that indicates that blue is approaching the surface from the wrong side.


Checking the angle instead of penetrationlenth also fixes this.


that must work if the body do not penetrate too deep so the minimum transaltion vector is calculated on the right (first intersected) edge


Edit: Noticed that choosing the surface with the angle would make incorrect choises in some cases. But checking if the angle between surfacepenetration and velocity is between 1/2pi and 3/2pi radians or 90 and 270 degrees does fix the case where blue made it deep enough to make the penetration to the otherside be smaller than the side it came from.

In Topic: Handling collisions with multiple bodies and unwanted collision with internal...

04 March 2015 - 12:46 PM

I cant understand properly your solution. Could you explain it better or give a pseudocode example, please? Also, notice that im using different polygons in my engine, not only AABBs.



Ok let me try.

All of this should work with any size and shape polygons and the image has axis aligned rectangles only because I was using mspaint.

Attached File  figurea.png   7.05KB   2 downloads

First we need to find a corner from blue polygon that is inside red polygon and call it corner A. Then find the surface in red wich is the closest one to corner A that is between corner A and an adjacent corner from blue and call it surface B.

In order to move the blue outside of the red polygon we need a vector from corner A to surface B and call it surfacepenetration.

Then we calculate the angle between surfacepenetration and a vector(0,1) and call it surfacenormalrotation.

Then make a new vector called rotatedvelocity by copying and rotating the original velocity by surfacenormalrotation.

Now we take the length of surfacepenetration  and divide it by the Y component of rotatedvelocity.

This gives us a float t between 0 and 1. This is the precentage of velocity you need to move blue one backwards to make corner A be outside of red polygon.


Here is a pseudocode for the moving blue backwards part.

float angle=findangle(surfacepenetration,upvector)
vector2d rotatedvelocity=blue.velocity.copy
float t=abs(surfacepenetration.length/rotatedvelocity.y)



When we enter the collision handling we repeat this until blue is not inside any red polygons. Then we process what happens to blue based only on the last collision that was detected this way as that is collision would have happened first if your simulation steps were small enough. In your first example picture it would always be the collision with the left red rectangle and the blue stops because of hitting the right red rectangle horizontally never happens.


Also if we store the percentages of velocity we moved blue backwards we know how many percent of "frametime" blue actually moved and we can then move blue again with the remaining percent after the collision has been resolved and blues velocity has been updated. This way no "frametime" is lost when collisions happen and the simulation looks smoother.


In a case where red corner is inside blue polygon you can use the same method. Corner A just comes from red and surface B comes from blue.



We still need to solve the case where the right red polygon is a tiny bit higher than the left and blue moves along the surface from left to right. When it hits the right polygon its going to hit it horizontally again and again and never get past it. That is why we need a variable to override the behaviour. When we search the closest surface if we find a surface that is less than minypenetration away and the resulting surfacepenetration vector would be mostly vertical we need to choose that one. And in this case we also don't move blue backwards but upwards instead to avoid getting stuck. If you don't do this then your seams must be perfect or you get "wierd stops" when you hit the seams from the lower side.


Edit: Ohsnap I had the vectors in the calculation of t wrong way around.

In Topic: Handling collisions with multiple bodies and unwanted collision with internal...

04 March 2015 - 09:17 AM


You could try to just move the blue backwards along its velocity until it no longer collides with anything like you are doing now but only alter the blue velocity in the last collision. you also could define a minimum Y penetration(could even be a variable inside blue) so that if the Y penetration is smaller than that then even if X penetration is smaller than Y you still take the Y one. You should get pretty satisfactory results if you do both of these.

Calculating how far to push body along its velocity is not that simple, as finding its minimal separation vector, but is almost the same as finding exact collision time in continuous collision algorithm. As i already said, continuos collisions involve more problems like corner-corner collisions, which i also dont know how to solve.

It is relativily simple. Just rotate both velocity and surfacepenetration the same amount so that the surface vector is upright(x==0). Then multiply the original velocity vector by vel.y/surface.y and thats it. I assume you already have the distance blue has penetrated along the surface normal. And you may need to use vel.y/-surface.y if your surfacepenetration vector goes from surface to inside instead of from inside to surface. Also if you store the percentages of velocity used(the vel.y/surface.y part) you can then after the last collision has been processed move the character again by velocity*(-sumofstoredvalues) as to make it move more physically accurately.


As for the second approach. It is actually quite common in platformers as it makes characters able to climb stairs and slopes and run over small gaps without having to make complicated code to detect those special cases.