Rene Z

If you're using an orthographic projection, the area the camera can see has a width height, and depth. Transform the mouse position data to normalized coordinates (a range from zero to one) if you're currently using pixels or something else. Then multiply the size of the camera view with delta mouse position, negate, and use the result to translate the camera.

If you're using a perspective projection this won't work, so let me know if that's the case.

Probably not.

I always use smart pointers, unless there's a good reason not to. A good reason can be performance in tight loops or something like that, but those cases are rare and should never leak out of your interfaces. Note that using smart pointers doesn't mean 'don't think about ownership', which often results in overusing shared pointers. Quite the opposite in fact: different types of smart pointers are a great way to explicitly state ownership of an object.

The linker gives you a hint: some symbols have been defined multiple times. Those float globals in Camera.h can be declared there, but you shoud define them somewhere else, best place is in Camera.cpp. The header should contain float camX, camY, camZ. The cpp should contain float camX = 0.0f;


Now some (constructive!) criticism towards your code:

Why does your FPSCamera class use those global variables? Only use globals when you absolutely have to, or they will come back to bite you in the behind. In this case, camX ect. should be members of the FPSCamera class. Remove the globals in main.cpp too.

Pi is indeed a good candidate for a const global, but doesn't belong in Camera.h. Ask yourself this: you need Pi for some calculations, does it make sense if you have to include Camera.h?

Camera.h includes main.h. Why? Has the camera a dependency on main? Include as little as possible in the header. In this case, you don't have to include anything. Include what you need for the implementation on your cpp file.

Use smart pointers instead of raw pointers.

I may be missing something, but you don't appear to be using shutdown(). Remove this function, move the call to glfwTerminate to the end of main().

Terminate the application by changing 'while(1)' in the main loop to 'while(running)' where running is a bool. When the user presses escape, set running to false. Try to avoid using exit(), it makes it harder to reason about code.

Add parameter names to your function declarations. They're a form of documentation. When peeking at the header, I have no idea what I should pass to moveCamera(float, float).

Never put 'using namespace x' in a header, this kills the benefits of namespaces in every file that includes it, directly or indirectly.

Don't handle keypresses in your camera class. Add functions to the class which allow you to move the camera, call these from another place where you handle all user input.


There is more I can find, but this should be enough for now. Please let me know if you have any more questions.

In glsl, the pow(x, y) function return value is undefined if x < 0 or if x = 0 && y = 0. I once had a situation where the specular multiplier and specular exponent of a specular map were both zero at some texels, which caused pow to return NaN. You can also check for that.

You need to put a ; after the declarations of vVertex, vFragColor and vVaryingColor.

You can call glGenTextures as many times as you want. When adding a texture, call glGenTextures(1, &handle); where handle is a single GLuint.

I'm not familiar with the X file format, but it surprises me to hear that they don't store the number of vertices. If push_back really is your bottleneck, an easy way to improve performance is to use a deque instead of a vector. Copy the contents of the deque to a vector after parsing the file. This still results in multiple allocations though, so it's not perfect. Another method is to do two passes. First determine the number of vertices, allocate the vector, then read the values.

If you really want to know where most of the time is spent, make a test program which only loads an x file and profile it. AMD CodeAnalyst is a decent free profiler:
http://developer.amd...es/default.aspx

Random number generators generating values between zero and one with an uniform distribution are common. You can take the squared output of such a generator, and then use to to scale the vector (B-A) and add it to A.

In pseudocode:

uniformRand = rand();

outputPoint = A + uniformRand*uniformRand * (B-A);

I'm sorting all my transparent objects by distance from the camera so they can be drawn correctly.

Try to use the distance to the near plane, not to the camera position. Often the distance to the object center is good enough, but if it isn't you can use it's bounding volume.

Or do a line segment - rectangle test, where the line segment starts at the previous position of the point and ends at the new position. That should work for all circumstances.

Depth test has been set to LESS_OR_EQUAL, not to LESS?