PunCrathod

Members
  • Content count

    48
  • Joined

  • Last visited

Community Reputation

596 Good

About PunCrathod

  • Rank
    Member
  1. If you don't need to read the vbo on the cpu side and if you don't have to update many different parts of the vbo it would propably be faster to just push updates to the vbo using GL.BufferSubData. That way the driver doesn't have to retrieve the data back from the gpu. This is because mapping the buffer has the driver retrieve the specified part of vbo from vram into ram and then on unmap transfering the whole thing back to vram. With buffersubdata it never retrieves anything from gpu and only updates the part specified in the command.   But all of the methods suggested here are valid and the only way of knowing wich one has the most performance is to profile them with your actual use case. And when doing that you propably should look into highprecision timer and timing individual frames. Keep a list of say 600 frames and you can get the shortest the longest and the avarage. Measuring performance in how many milliseconds or if you want even in nanoseconds is important as that gives a much better idea of just how much your performance drops than frames per second. Also keeping a record of individual frames lets you see the longest frames and help you find stutters and such more easily. All you have to worry about is if your frame time exceeds 16 milliseconds then you can no longer quarantee 60 fps and you might need to optimize. Or if you are targeting a differrent fps(for vr i think you need over 90 and for mobile 30 should be enough) you can calculate the millisecond limit by 1000/fps.
  2. Sony C#/.NET Component Set Analysis

      It's actually correct. If the status is Aborted then the first test will always be true anyways. So it's redundant. Really what I dislike about the code is that the reliance on order of operations instead of brackets.   It is not correct. If the loop is meant to run until the status is either complete or aborted. What you are suggesting to be correct would still keep on looping if the status is aborted. Unless the code is meant to go into an infinite loop when the dispatcher aborts then what ferrous said would indeed be correct. Tough I would have made it like so for readability. while (res.Operation.Status != DispatcherOperationStatus.Completed && res.Operation.Status != DispatcherOperationStatus.Aborted)) { Thread.Sleep(50); }
  3. C# Color Wheel

    The problem here is that there are a few thousand different methods to do this depending on what you are using to interact with the user. For example the most common approach would be to use winforms but you can also use mono, unity or pretty much anything else ever concieved to interact with the user. For all we know you might be using a COM interface to make a grid of leds go on and off. Or if you don't have anything at all then I suggest you start looking at winforms tutorials and when you have a window with some interactivity you come back and tell us what you used to make the window and we will happily figure out a way to make a color picker for that. Making a simple color picker from nothing at all is several months of work even for a professional. Even if we picked a library at random and made a ready to use color picker for it it would propably take a long long time for you to integrate it into your project. So help us help you and give us little more details. You are right that you don't have to tell us what your project is about but everyone else is also rigth that we need more information to be able to help.
  4. I should have mentioned this in the original post, sorry. I'm not getting any errors while compiling or linking.   Do you use glGetError, glGetProgramInfoLog and glGetShaderInfoLog. Shader errors do not always show in glGetError. You can also try to use glValidateProgram. If none of these show anything then we can consider a driver bug.
  5.   As far as I know those games didn't use normals or anything similar. They just used a predrawn tileset. There just isn't any algorithm that could be used 20 years ago that could do that realtime so they faked it by using predrawn images.
  6. Why do you want to scale it during creation. What is wrong with letting opengl scale it for you during drawing? Unless you want to implement your own scaling algorithm or use a library to get slow but better quality scaling you are betteroff just letting opengl do it during drawing.
  7. How to display all explored nodes with A*?

    There is no such thing as a discarded node in A*. There are only open and closed nodes. You always close the node that has the lowest heuristic value and make new open nodes around it. You can't discard any unused open nodes or you break the whole idea. Looking at the code it seems to be doing the right thing so I assume you are just using different terminology because of a language barrier or something. If you want to display rest of the nodes you need to save the opennodes and closed nodes into the AStar2.Path2.
  8. Need help creating procedural rivers

    A 1024x1024 for A* is a really simple problem if you are running it on a processor faster than a handheld calculator. Especially when you only need to run it during worldgen. Also what I would do is just repeat three steps after a swawnpoint has been found. 1. You find the steepest downward slope around the current point and go there. 2. If there isn't a downward slope you floodfill towards directions that are even with current position until you find a downward slope and then you A* a path to that location and go back to 1. 3. If you cant find a downward slope with the floodfille you make a lake that fills the whole floodfill area and go back one step of the river and go back to 1. where you handle the lake as if the height of the terrain was one level higher(as there is now a lake there). You should also allow multiple lakes to be on top of each other to form a deeper and bigger lake.   If you continue this the river will eventually reach the ocean and it will generate nice and realistic lakes as well.   Also if you reach the spawnpoint when going backwards in step 3 then you can stop the river there and you have a nice lake there. Not all lakes have a river that leads to the ocean.
  9. 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.   https://www.opengl.org/wiki/OpenGL_and_multithreading
  10. cross shader

    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.
  11. 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       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.       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.   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.
  12.   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. [attachment=26235:figurea.png] 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 rotatevector(rotatedvelocity,angle) float t=abs(surfacepenetration.length/rotatedvelocity.y) blue.pos-=blue.velocity*t .   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.
  13. 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.
  14. 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.
  15. OpenGL Sprite batching performance

    Ummm.... Correct me if I'm wrong but isn't the point of a sprite batcher to render as many sprites as possible with as few drawcalls as possible. Why are you only rendering 800 sprites at a time when you could just render them all at once. The only reason that I can think of are memory constraints but a batchsize of 800 is kinda low even for that.