• What Do You Need Help With? V6
    7,544 replies, posted
I'm working with sound at the moment (which I don't know a whole lot about) and I'm finding that some sounds won't play if triggered in the same method as some other sounds. I assume it's because they want to use the same channels or something, but I don't really know. Any tips for how to avoid this?
I've just started playing with SDL and I'm having an issue with key events. The SDL_KEYUP type is being fired both when the key is released and when it is initially pressed, this is the same for the SDL_KEYDOWN type which is also both called when the key is pressed and released. This is the relevant code: [CODE]while(SDL_PollEvent(&event)) { if(event.type = SDL_KEYUP) { switch(event.key.keysym.sym) { case SDLK_SPACE: cout << "Space pressed" << endl; break; default: break; } } } [/CODE] If I run it and tap space once I get: [CODE]Space pressed Space pressed[/CODE] While I'm kind of expecting: [CODE]Space pressed[/CODE] Is this me misunderstanding how it works or is something strange going on? [editline]30th June 2013[/editline] Scratch that, noticed the problem the second I posted. = isn't == Sigh. Spent ages looking into that.
I hope someone with some serious knowledge about the A-Star algorithm can help here. I'm currently working on a A-Star algorithm that I need to modify to yield better performance for my specific scenario. So far it's working correctly but is very slow. I'm using the algorithm to find a way for a bird (an actor that can freely move in every direction) trough some static geometry. My game does [B]not[/B] have a grid-like structure in my game (like in minecraft for example). So I cannot find the "neighbour nodes" easily. Instead my a-star works like this: - Pick a suitable "grid size" - When I need to find all neighbours, I do a trace-line in all 26 directions (front, front-left, front-left-up, etc...) - The length of the traceline is "grid size" - A neighbour is found when the traceline doesn't collide with the world. (This would be the "is cell free" check in a grid-based 2d game) The slow part in my algorithm is the tracing function, it's already heavily optimized and there's not much more I can do to make it any faster. So the bottleneck in my algorithm is determining the neighbour nodes. What I tried so far: 1.) Increasing the gridsize. This actually helps a lot (10x-100x speedup) since I get much closer to the target with every "expand node" step and I don't have to do so many tracelines to explore "neighbours" Disadvantage: If the route needs to go through a small door/hole this increases the chance that no path can be found. To guarantee that a (existing) path can be found, the grid size has to be smaller than the radius of the smallest hole that needs to be passed. But often the holes/doors in my geometry are so small that I would have to make the grid-size so small that it would take [B]minutes[/B] to find the path. 2.) Caching both result-paths and the knowledge about what neighbours are available at each node. This results in a more than 100000x speedup, but only if a path has already been found or the path only uses nodes that have been explored previously. Disadvantage: Doesn't help anything at all if a route is required that goes through an "unexplored" region of my games geometry. 3.) I though about pre-calculating all neighbours (idea #2) and then saving that information to a file. This would give me the huge speedup for free all the time. I didn't implement this yet because of its disadvantages. Disadvantages: - [B]Hours[/B] of pre-calculating - Data gets invalidated if geometry changes (which might very well happen) - Resulting data would be too large. Without compression at least 1-5 GB per level and compression wouldn't help at all since I obviously need the uncompressed data when working with it... Any ideas?
You could try "voxelizing" the level geometry to an octree. Essentially you would pre-calculate the entire level at a very high gridsize, then for any node that's colliding, you would subdivide into 8 octants and test again recursively with a smaller gridsize. Your base case would be a specified gridsize. This is basically #3 without any of the disadvantages. Precalculation can basically happen on-the-fly since you can calculate a few levels into the octree and have "rough" navigation while the higher details are generated. When you change part of the world, you only have to invalidate the octant that contained that object, and an octree can be compressed quite well on disk seeing as you only need to keep track of a single bool. Depending on how you index it, you might be able to get away with 2 bits per node.
[QUOTE=Wickedgenius;41251625][editline]30th June 2013[/editline] Scratch that, noticed the problem the second I posted. = isn't == Sigh. Spent ages looking into that.[/QUOTE] Set your compiler to emit more warnings.
[QUOTE=Felheart;41253664]-snip- Any ideas?[/QUOTE] You need a navmesh. If you start with the vertices of your level geometry and trace between them you should be able to divide them into groups that describe the surface of convex polyhedra (by merging for example) and are connected with planar polygon portals. This will work with (probably) less memory and any hole size, and you can use A* by using the distance vector between connected nodes for the heuristic.
[QUOTE=Tamschi;41255361]You need a navmesh. If you start with the vertices of your level geometry and trace between them you should be able to divide them into groups that describe the surface of convex polyhedra (by merging for example) and are connected with planar polygon portals. This will work with (probably) less memory and any hole size, and you can use A* by using the distance vector between connected nodes for the heuristic.[/QUOTE] I know that a navmesh can be used for stairs and multiple floors, but I always thought "real" 3d navigation isn't possible with it, because a navmesh is just "many connected convex 2d faces". I think I'd need something like connected 3d volumes? Well anyway, I think that your suggestion would be way more efficient as it yields perfect solutions, but too complex for my purpose. (as in it would take me too long to implement) @robmaister12: Thats actually a really good idea too. I'll see if I can whip up a quick and dirty proof of concept. Then, with the other ideas combined I think it will be good enough. Thanks everyone.
Yeah, so the idea for actually navigating through mine would be to calculate all the neighbor nodes for any given node and throw those on the open list. There are a bunch of papers out there on efficiently finding neighboring nodes in quad/octrees, some quick searching brought this one up: [url]http://ww1.ucmss.com/books/LFS/CSREA2006/MSV4517.pdf[/url]
I decided to delve into some OpenGL so I set up a project with glew/glfw and got it to compile but I can't seem to find any decent documentation. Know of any?
[QUOTE=reevezy67;41261860]I decided to delve into some OpenGL so I set up a project with glew/glfw and got it to compile but I can't seem to find any decent documentation. Know of any?[/QUOTE] Documentation for "glew/glfw" or OpenGL itself?
Sorry, I should have specified. OpenGL.
[QUOTE=reevezy67;41262154]Sorry, I should have specified. OpenGL.[/QUOTE] [url=http://open.gl]open.gl[/url] is a good introduction, otherwise read the official specification, it's very well documented.
[QUOTE=Tamschi;41262314][url=http://open.gl]open.gl[/url] is a good introduction, otherwise read the official specification, it's very well documented.[/QUOTE] There's also [URL=http://www.arcsynthesis.org/gltut/]"Learning Modern 3D Graphics Programming"[/URL] and the [URL=http://www.amazon.com/exec/obidos/ASIN/0321712617/khongrou-20]OpenGL SuperBible[/URL] (which I've read and recommend).
[cpp] char * shaderSource; std::ifstream fIn( "vertex.glsl", std::ifstream::binary ); fIn.seekg( 0, fIn.end ); shaderSource = new char [fIn.tellg()]; fIn.seekg( 0, fIn.beg ); fIn.read( shaderSource, fIn.tellg() ); fIn.close(); const char * vertexSource = shaderSource; delete [] shaderSource; [/cpp] What is wrong with this code? I'm trying to copy the content from vertex.glsl -> shaderSource -> vertexSource.
[QUOTE=Cassel;41263807][cpp] char * shaderSource; std::ifstream fIn( "vertex.glsl", std::ifstream::binary ); fIn.seekg( 0, fIn.end ); shaderSource = new char [fIn.tellg()]; fIn.seekg( 0, fIn.beg ); fIn.read( shaderSource, fIn.tellg() ); fIn.close(); const char * vertexSource = shaderSource; delete [] shaderSource; [/cpp] What is wrong with this code? I'm trying to copy the content from vertex.glsl -> shaderSource -> vertexSource.[/QUOTE] Two things. Let's look at this part first: [cpp] fIn.seekg( 0, fIn.end ); // Seeks to the end of the file shaderSource = new char [fIn.tellg()]; // fIn.tellg() returns how many bytes in the file we are. Since we are at the end of the file we get the number of bytes the file contains. fIn.seekg( 0, fIn.beg ); // Goes back to the beginning of the file again fIn.read( shaderSource, fIn.tellg() ); // fIn.tellg() now returns 0 since we went back to the beginning of the file, which means you are reading 0 bytes from the files. [/cpp] You need to store the size somewhere. Something like this: [cpp] fIn.seekg( 0, fIn.end ); int filesize = fIn.tellg(); shaderSource = new char [filesize]; fIn.seekg( 0, fIn.beg ); fIn.read( shaderSource, filesize ); [/cpp] The second thing might not be a problem, but I'll mention it anyway. [cpp] const char * vertexSource = shaderSource; delete [] shaderSource; [/cpp] You are only copying the pointer to vertexSource, which means that vertexSource and shaderSource is pointing to the same memory location. So when you do delete[] shaderSource, vertexSource is deleted too. If you want to copy the contents of shaderSource to vertexSource you need to call std::strcpy.
Great! Thanks a lot!
I'm going to texture a sphere. When googling for alternatives, I often see the term "cubemap texture". Unfortunately I can't seem to find a really easy description of it, but perhaps I've grasped it. Is it essentially six textures representing the faces of a cube, which when sampled at a point returns the value of the texel on the same line from the center point to the sample point? I've got a (bad) picture which illustrates what I mean, well actually the 2D equivalent of it: [img]http://i.imgur.com/MYuN1hR.png[/img] Black dot is center, yellow dots are the points I request to sample, and the blue dots are where it's actually gettings its samples from. Am I correct in believing it works this way?
snop
I'm looking for a 3d physics library, or some tutorials on the matter. C++ with OpenGL(though the library shouldn't matter I think).
So, i'm trying to make a program that shows the world map and all the flights and their positions(LIVE). There's a JSON online hosted file with almost 700.000 characters on a server that is fed with a lot of these flight's info. This is the JSON string for a single flight: [QUOTE] "QTR80":["06A097",41.7951,12.2428,"340","0","0","2000","F-LIRF1","A320","A7-AHP",1372708809,"FCO","DOH","QR80",1,"0"][/QUOTE] But there are hundreds of thousands of flights and the JSON file changes a lot every second. Right now, it takes like 10 minutes for the program to download the string and input everything on the console. I want the delay to be minimum. Any clues? Or is this impossible? What i'm using right now: Visual Studio, C#, WPF GMaps.NET for the map. JSON.NET for JSON reading.
Question: If I am clicking on a field of 3D-terrain, how to I get the world-space coordinate from where I clicked if all I have is the X and Y position of the mouse on the screen. In Laymans terms, if I click on a terrain map, how do I get where I clicked?
[QUOTE=MatheusMCardoso;41272638]-flight data-[/QUOTE] You most likely can't reduce the download time (although with less than 1MB either the server is throttling or your internet is horrible if it takes more than a few seconds). Run a profiler to see what takes the most time. Why would you "input on the console"? If you mean that you're Console.Write[Line]-ing all the data then that is already a major slowdown. If the culprit is really the parsing (which I think is unlikely) you can speed it up a lot by improperly parsing the numbers and flights from the source string, without splitting or sanity checks. Also, you can stream the data onto the map while parsing by dispatching the updates to the UI thread from the background. [editline]2nd July 2013[/editline] [QUOTE=MatheusMCardoso;41272638]GMaps.NET for the map.[/QUOTE] GMaps violates the map providers' terms of use (because the developer circumvents the official APIs by grabbing tiles directly from the static servers), so using it as it is right now is likely illegal. This is because of licensing issues with the map data, the companies have to ensure applications comply with certain rules so they forbid access outside of the API's methods. [editline]edit[/editline] It looks like OpenStreetMap doesn't have this restriction, so you can use that for the map without any legal sketchiness afaik. [editline]2nd July 2013[/editline] [QUOTE=Xystus234;41272691]Question: If I am clicking on a field of 3D-terrain, how to I get the world-space coordinate from where I clicked if all I have is the X and Y position of the mouse on the screen. In Laymans terms, if I click on a terrain map, how do I get where I clicked?[/QUOTE] Project the click into world-space by reversing the projection or calculating the clicked direction from the view port parameters, then you can ray-march against the terrain to find the closest intersection.
[QUOTE=WTF Nuke;41272393]I'm looking for a 3d physics library, or some tutorials on the matter. C++ with OpenGL(though the library shouldn't matter I think).[/QUOTE] Bullet, Newton and ODE are three popular ones. I'm not sure if Havok and PhysX have free plans available. Bullet, Newton and ODE come with example programs, not sure about the other two.
im about to blow my goddamn fucking brains out if i cant get the intersection of 3 planes i have spent at least a hundred hours trying to figure it out (not even lying) And now that the rage is over with, I'd really like a way to calculate the intersection of 3 planes in any way imaginable. I think I've tried about every way and I get bogus results each time. So far, the only solution that has worked was a bloated matrix library that drastically slowed down my program.
[QUOTE=elevate;41281111]im about to blow my goddamn fucking brains out if i cant get the intersection of 3 planes i have spent at least a hundred hours trying to figure it out (not even lying) And now that the rage is over with, I'd really like a way to calculate the intersection of 3 planes in any way imaginable. I think I've tried about every way and I get bogus results each time. So far, the only solution that has worked was a bloated matrix library that drastically slowed down my program.[/QUOTE] First get the intersection of the first two planes (a line, [URL="http://mathworld.wolfram.com/Plane-PlaneIntersection.html"]direction is (parallel to) the cross product of the normal vectors, the anchor can be found by choosing one degree of freedom (there is no catch-all dimension) and solving the distance to each plane = 0)[/URL]. Then you can intersect that line and the third plane. You can make it a bit faster by not normalizing the directions in the intermediate results, but then you may have to keep track of that factor, unless it cancels out somewhere.
[QUOTE=Tamschi;41281337]First get the intersection of the first two planes (a line, [URL="http://mathworld.wolfram.com/Plane-PlaneIntersection.html"]direction is (parallel to) the cross product of the normal vectors, the anchor can be found by choosing one degree of freedom (there is no catch-all dimension) and solving the distance to each plane = 0)[/URL]. Then you can intersect that line and the third plane. You can make it a bit faster by not normalizing the directions in the intermediate results, but then you may have to keep track of that factor, unless it cancels out somewhere.[/QUOTE] Well as usual right after I'm done with a rant or post a question on a forum, I find an answer shortly after, even if I spent a hundred hours on it before. The "bloated" library I'm using, it's not bloated at all. I'm just a dumbass because I called a function that initialized a matrix each and every single time I called it, which DRASTICALLY slowed down my program. It's a shame I still wasn't able to figure out plane intersections by myself. I knew the formulas, but when I tried to implement them, they would give me bogus results. Perhaps it was something on my part, but I don't know. Thanks anyways. Here's the matrix operation I implemented. [quote="http://www.gamedev.net/topic/304411-three-plane-intersection-point/"] ( A1, B1, C1 } ( x ) ( -D1 ) { A2, B2, C2 } * ( y ) = ( -D2 ) ( A3, B3, C3 ) ( z ) ( -D3 ) Let the matrix [M] be ( A1, B1, C1 } { A2, B2, C2 } ( A3, B3, C3 ) so [M] * (x, y, z) = (-D1, -D2, -D3) so (x, y, z) = inverse([M]) * (-D1, -D2, -D3) [/quote]
[QUOTE=ZeekyHBomb;41276662]Bullet, Newton and ODE are three popular ones. I'm not sure if Havok and PhysX have free plans available. Bullet, Newton and ODE come with example programs, not sure about the other two.[/QUOTE] Any recommendation?
I'm looking to use Bullet for a project of mine. No particular reason I chose it over the other options; it's open-source, industry proven and still active. Should be good enough.
Are there any languages I can use in java that I can fully sandbox, only let them return a variable, not make any modifications to anything else?
[QUOTE=hogofwar;41284601]Are there any languages I can use in java that I can fully sandbox, only let them return a variable, not make any modifications to anything else?[/QUOTE] Are you talking about isolated functions that do not modify global variables? That's available in pretty much any language.
Sorry, you need to Log In to post a reply to this thread.