Jump to content

  • Log In with Google      Sign In   
  • Create Account

powly k

Member Since 01 Aug 2012
Offline Last Active Sep 27 2014 04:21 AM

#5148243 Custom view matrices reduces FPS phenomenally

Posted by on 19 April 2014 - 05:20 PM

Upload them only once just before rendering - though the driver will probably already do this for you behind the scenes.



The more important point you might want to consider is how you measure your performance. If you get >1000fps with those various effects, your scene is probably too small to test on. If your rendering is not the bottleneck, then your memory lanes are. So you could probably throw a way more complex scene at the program and it'd run at the same speed. Another point is that measuring with fps can be deluding - a drop from 1200fps to 170fps is not that massive, the render times went from 1ms to 6ms - you should maybe measure which parts take how much time, opengl has time query objects for this.

#5122563 Path tracing - Direct lighting

Posted by on 10 January 2014 - 04:11 AM

This is all about the probability of each path. As with all monte carlo integration, you have to compensate the values of each sample with the probability of choosing that sample. The probability of hitting a point or directional light with a random chance is exactly 0; they're a single point on a continuous hemisphere. On the other hand, such lights act as dirac functionals; their contribution is only non-zero at a single point and infinitely large there. This, when integrating over the hemisphere, means that you can just pull them out of the integral and sum them with the approximation of the integral; the indirect lighting.


In a mathematic sense all surfaces and lights are equal (which makes sense, secondary or tertiary light sources are just as much light sources as primary ones) but when actually tracing the scene it makes sense to try to focus on the important stuff; this also leads to importance sampling of materials and multiple importance sampling of materials and lights together.


A lot of these approaches result in the exact same results - you can trace two bounces per incoming ray, for example, just keep track of your probabilities and you'll be fine as in the result will be unbiased. The vast majority of the ideas and research on the subject don't really focus on getting the result right, but reducing variance (which is visible as noise). With bidirectional path tracing using multiple importance sampling and materials that are importance sampled accurately, you can save a lot of rendering time (orders of magnitude) and get the same level of noise in your results.

#5113371 Display Loop with Win32

Posted by on 30 November 2013 - 05:37 PM

glFlush() is a signal to the driver that you want to have all the submitted rendering ready before you go on with the code. And you're correct, as far as I know the wait occurs on SwapBuffers() and there's nothing you can do about it - why precisely would you, though? The best you can do is probably to measure frame time and if your frames are consistently shorter than your desired frame rate, do some extra stuff. It would also kind of fight the nature of VSYNC to be able to control it - the display works on a specific rate, it cannot be altered by programs.

#5113367 Some ideas for a tic tac toe

Posted by on 30 November 2013 - 05:28 PM

There are languages that index arrays defined for N elements in [1...N] (matlab comes to mind) or even [0...N] (Blitz Basic).


There is a good reason for the typical choice of [0...N-1], but it goes somewhat deep. You need to remember that the end result of the code is meant to run on actual hardware. In this case you want to access memory, but memory itself doesn't know the concept of an "array". It knows what data it holds and what index it's at. The most important thing is that an array is actually some index to the memory, and more precisely it's the index of the first member of the array. To access this, there is the typical array[j] syntax, which pretty much means "give me the j:th element of array 'array' " which is the same as finding the bit of memory that's at array+j. Since array is an index in the global memory and j is the index inside that array, we can just sum them to find the location of j in the memory.


Now, it (hopefully) makes sense to choose that the first element of "array" is at memory address "array", not at "array+1", so the first element should be at array[0] instead of array[1], since it gets translated to an actual memory address. Why it ends at N-1 instead of N is because we still want to have N elements - and if we count from 0 and go forwards until we have N elements, we reach element N-1.


This is, of course, only a chosen convention but it implies other nice things, like for(int i = 0; i<N; i++) /*operate on array[i]; */ instead of for(int i = 1; i<N+1; i++) /*operate on array[i]*/; the length of the for loop can instantly be seen from the ending condition instead of having to remember to take one out - it's a simple thing, but would cause (I believe) even more headache, especially for beginners or less enthusiastic programmers.

#5096137 Good book or online tutorial to learn modern OpenGL

Posted by on 23 September 2013 - 07:32 AM

What? Last time I checked the red book was about what people did in the 90s.


http://www.opengl-tutorial.org/ should be a nice introduction to OpenGL if you already generally know what's going on but want to learn the API.

#5088383 Is SSAO view dependent?

Posted by on 23 August 2013 - 08:32 AM

The last few paragraphs of this post explain the reconstruction from Z buffer quite nicely, but go ahead and show a bit of your code if you're still having troubles. Your second picture looks just like a typical SSAO, so your problem is indeed most likely in the reconstruction.


The real problem here is that corners don't look like that. SSAO is a fakey trick and doesn't really resemble real world lighting too much. If you tone it down enough so it's not black noisy bars but a slight darkening at some places, it can be a nice artistic touch.

#5081578 GPU Normal Maps Artifacts on a Quadtree Terrain

Posted by on 29 July 2013 - 05:45 PM

I would definitely try adding 0.5*PixelSize to your UV coordinates - sampling at texel edges tends to be problematic. I'd also play around with the size of hpix, at least halving and doubling are usually good candidates to fix sampling artifacts.

#5058590 Is there anything faster than A* pathing?

Posted by on 02 May 2013 - 05:31 AM

Things faster than A* include, for example, summing two numbers, calculating a dot product or doing nothing at all. Most problems have many good solutions, and the best one must be picked by you depending on the specifics. And even better than a good solution is avoiding the problem altogether, which is also sometimes possible.

#5047421 OpenGL core profile question

Posted by on 27 March 2013 - 05:32 PM

The OpenGL wiki itself has a few tutorials on the subject, though they're not using glfw.


Though I'd guess that the way you use vertex arrays or something related is the problem itself - if you got the context without any errors, it was probably working correctly. The OpenGL vertex array object thing makes no sense anyways. I'd double check that you're actually getting an error of some sort from GLFW or GL related to context creation, not the rendering code itself, before jumping into conclusions. Checking for errors is usually a good idea anyway.


The way I like to use OpenGL extensions is with a small offline script that generates me a header with all the function pointers and a function to load all the extensions based on a core specification I give as a parameter. It took a couple of nights to code, but works like a charm and whenever the ARB releases a new header, I can just ask for the new core (when the drivers arrive, of course) without being tied to anyone elses code.

#5046286 Help me understand .cpp vs .h in C++

Posted by on 24 March 2013 - 01:09 PM

This is a hard topic unless you know just a bit about what's going on behind the scenes when compiling. What happens is basically the compiler looks at what .cpp files you have in the project (or folder or the ones you tell it to compile, this depends), turns each one of them into an object file (.obj with visual studio, .a and .o also exist with some compilers IIRC) and it's done. After this the linker jumps onto the scene and starts looking at what pieces of code it needs to make the program into an actual executable - this is why you, for example, tell the linker, not the compiler, where the execution starts. Here you can have so called statically linked libraries too, that's the list of .lib files you feed to your linker. The most usual linker errors occur when you either forget to link against something or have multiple definitions - the same variable or function exists in several object files and the linker can't figure out which one to use.


Now, you might notice I didn't mention headers at all. This is because a header is never compiled itself, it's just included into (usually several) other files. So if your header has a global variable definition (for example "int x = 5;"), it'll be in all of the .cpp files and the linker won't like this. So you want your headers to only hold declarations, not definitions. int foo(int x); is okay, int foo(int x){return x*2+1;} isn't. Unless it's code you only use in one file, though then you don't even have to keep it in the header at all.

#5046004 Direct3D 11 Deferred Shading Banding

Posted by on 23 March 2013 - 11:54 AM

Indeed, that seems to be just the unavoidable banding you always with such a slowly changing gradient and current monitors. Another thing you can do is apply some very slight noise, it won't be visible as noise but will smooth out the gradient.

#5045008 How do I manage loaded geometry?

Posted by on 20 March 2013 - 03:13 PM

A texture can easily be read in a shader and written to on the CPU, so you can upload your positions and orientations as a texture, though you probably should do it with uniform buffers or something. The draw calls i was referring to are glDrawArraysInstanced and glDrawElementsInstanced.

#5044713 How do I manage loaded geometry?

Posted by on 19 March 2013 - 05:32 PM

In OpenGL, there are specific draw calls for instancing (drawing multiple copies of the same thing) so you don't have to care about keeping them all in memory - just keep their locations in a texture and render based on that and instanceID. Just write a class that handles a single model and load all your geometry as instances of that class in the beginning of your program.

#5041802 First Game Help Ideas

Posted by on 11 March 2013 - 05:32 AM

Ah, that's the stuff you had in mind. A couple of things come to mind, though lots of coding is experimentation and depends a lot on the game and the guy writing it.


Hexagonal movement isn't always easy - having a clear idea of your coordinate system should be very helpful, since lots of things require you to fiddle with positions - you might want to have a class to handle a position, so you can ask where things are, move them without problems (maybe turn them to look at a certain point) and change between world and screen positions for rendering and mouse interactions. Your unit class, for example, could have the position it's at and the position it wants to get to once it has enough movement points (or however you limit your movement per turn).


For a battle you might actually want a class instead of a function, so you could handle everything that goes on in there separately from the possible overworld view and possibly interrupt battles to continue different ones. And archive them somehow, if you want statistics. But it's already justifiable for a nicer flow for the program and having less global variables to care about - they're not as evil as many people say, but having a few member variables in a class is usually easier to handle than the same globals. And you clearly see where they should be used and it's even enforced by the language if you use privates.


The other option would just be a battle function that gets some details as a parameter - which map file to load, maybe a briefing text, goal of the battle, stuff like that. You might even want to have a map file complicated enough to hold all scenario details.

#5041646 First Game Help Ideas

Posted by on 10 March 2013 - 05:39 PM

About the whole idea: It does sound big, but also you seem to be going nice and slowly about this, so it just might work.


You'll want to have a nice class setup thought out before writing anything - a tile might have its own class, and so could troops, objectives, collectible things or buildings. Depending on what you want to do with them. It's also a good idea to consider how many of each thing you need and how it's bounded - dynamic allocations can be hard to manage and are surprisingly rarely absolutely necessary, just keeping large enough arrays cuts it most of the time. Especially with this kind of a game - if your player would have thousands of units, a single turn would become a very long and possibly tedious task to complete. Lots of things will be like this - you can go with the "proper" approach or with whatever works - someone put this nicely into words; "you can either write good code or good programs". Usually getting the thing done is more important.


Another a big thing to consider is interaction; graphics, audio, inputs. There are tons of ways to handle it, some fitting and some less fitting. As you're probably going for some sort-of-isometric 2D projection instead of 3D graphics, I'd recommend looking into things like allegro, SDL and SFML - they handle pretty much everything you need, aren't too hard to grasp and are widely used so getting help won't be a huge problem. They're also cross-platform, if that happens to be your thing. As a small disclaimer, I've only used SDL out of those three. But from what I hear, SFML does things "the C++ way" and is very modern with its approaches to things so it might be the first one you should try when learning how to do things.


Good luck - though it's not as necessary as determination.