• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

596 Good

About PunCrathod

  • Rank
  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.   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. 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. 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. 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. 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

    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.