KaiserJohan

I will strongly recommend http://www.arcsynthesis.org/gltut/index.html. I am using it and it is way more in-depth than anything else I've found on the internet, I have bought the OpenGL Superbible but I never really use it anymore

+1 for refactoring, it is a little dishearthening to know you are writing code you know you are probably gonna refactor soon but it's impossible to get it right on the first attempt. Gets your brain working though and that's important, I do it all the time in my hobby projects. It is also pleasing mentally to clean up old code. There's a good book called "The pragmatic programmer" (http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X) I highly recommend.

 

A little bit harder to convince people at work, especially non-programmers, the value of spending some time and go back refactoring old code instead of adding new features though...

I can recommend http://unity3d.com/. Very easy to use, powerful and you can become productive quickly. It has support for multiple platforms, including iOS/Android. I believe you can make games for those platforms even with the free license (although under restrictions).

 

I'm not sure if you can access the accelerometer directly from their engine, but I'm certain they allow you to write wrappers to access the underlying OS features. I know a project where we had our native cross-platform library which we could load independently of the platform used through the same C# wrapper code in Unity and through it we could directly use android/iOS library.

 

Typically you code the game in C#, Javascript or Boo. You also have access to .NET through Mono, which is extremely handy. 

 

If I was an indie just wanted to create a game that would be my engine of choice any day of the week. 

I recommend looking into Assimp.

 

I second this. You can also use Assimp to build your own engine-specific binary 3d model fileformat outside of the engine through some CLI tool you create, and use this in your engine.

 

If you do this, I can recommend boost::synchronization for file read/write. It is very easy to read/write data structures from/to files with it. 

GLM is awesome, I havn't bothered to look for something else. Definately go for it

So far I've used a static camera which simply sits at Vec3(0.0f) and stares down negative Z axis. I've got geometry like cubes to play correctly when translating, scaling, rotating etc, but now I want to try get the camera move correctly.

 

I am using glm, and to get a view matrix I am using the glm::lookAt method with the Vec3 data provided from my camera struct

 

Mat4 CreateViewMatrix(const Camera& camera)
    {
        return glm::lookAt(camera.CameraPosition, camera.TargetVector, camera.UpVector);
    }

 

 

Here is my camera definition:

 

/* Camera definition */
    struct Camera
    {
        Vec3 CameraPosition;
        Vec3 TargetVector;
        Vec3 UpVector;

        Camera();
    };


    /* Camera inlines */
    inline Camera::Camera() : CameraPosition(0.0f), TargetVector(0.0f, 0.0f, -1.0f), UpVector(0.0f, 1.0f, 0.0f)
    {
    }

 

 

I basically try to move it like this between the rendering:

 

 // move camera
            if (evnt.KeySymbol == LEFT)
                activeScene->GetSceneCamera().CameraPosition -= Vec3(0.1f, 0.0f, 0.0f);

            if (evnt.KeySymbol == RIGHT)
                activeScene->GetSceneCamera().CameraPosition += Vec3(0.1f, 0.0f, 0.0f);

            if (evnt.KeySymbol == UP)
                activeScene->GetSceneCamera().CameraPosition -= Vec3(0.0f, 0.0f, 0.1f);

            if (evnt.KeySymbol == DOWN)
                activeScene->GetSceneCamera().CameraPosition += Vec3(0.0f, 0.0f, 0.1f);

 

 

but this creates some strange results. For example, instead of the 'strafing' effect I would expect when moving the camera on the x-axis, it is as if I am rotating it, standing still. And when I try to move it in Z-axis, I really cant quite explain how it looks like, kinda like 'zooming' down the Z axis or something..

 

So I guess it's not as easy as I think?

 

Centered around the origin; like this?

 

// front vertices
1.0f, -1.0f, 1.0f,           // bottom right
-1.0f, -1.0f, 1.0f,          // bottom left
-1.0f, 1.0f, 1.0f,          // top left
1.0f, 1.0f, 1.0f,            // top right
 
// back vertices
1.0f, -1.0f, -1.0f,           // bottom right
-1.0f, -1.0f, -1.0f,          // bottom left
-1.0f, 1.0f, -1.0f,          // top left
1.0f, 1.0f, -1.0f,            // top right

I strongly recommend learning modern, shader-driven OpenGL. The vast majority of OpenGL resources on the net cover the classic, fixed-function pipeline, but there are a few good tutorials out there to help get you off the ground. I really like the Learning Modern 3D Graphics Programming tutorial by Jason McKesson. I've been around OpenGL for years, but only recently got into the modern stuff. And that's what I used. And I know a few newcomers to OpenGL who found it useful.

You might also find the 5th edition of the OpenGL Superbible useful to start with. I first learned OpenGL from the 2nd edition some years ago (still have it on my shelf). I picked up the Kindle version of the 5th edition earlier this year to help me along with the tutorial above. I think it's perfect for beginners. The author shields you from the nitty-gritty details of shaders for the first few chapters via a utility library he put together. I think it's a great way to get started with the concepts and without getting bogged down by the technical details. But he gets into the shaders around Chapter 6.

Once you're comfortable with simple OpenGL stuff, another book you might find useful is the 6th edition of Edward Angel's Interactive Computer Graphics book. It teaches some graphics theory and algorithms specifically using shader-based OpenGL.

All 3 of these books together should go a long way toward getting you where you want to be. Of course, there are other great books out there that any graphics programmer should have on his shelf, but these are good to get started.

EDIT: fixed the links.

I echo http://www.arcsynthesis.org/gltut, it is the best and most in-depth OpenGL tutorial you could ever ask for.

I highly, highly recommend looking into Boost function (http://www.boost.org/doc/libs/1_52_0/doc/html/function.html). I use it for some callbacks and it works wonders.

This probably isn't the thread for it so pardon me, but I've been using GLFW coupled with GLEW for OpenGL and I couldn't be any more happier. It does everything I want and nothing more. If you can't decide between the two I really suggest giving GLFW a shot

I don't understand how you can completely avoid globals? I completely understand to avoid it as much as absolutely possible, but for instance a logger object. Should you really pass your logger instance to all objects in your game that might need logging? And also say for example you use a framework like GLFW for input, how would you pass on the callback without storing some info globally?

Both are used for the same thing. To group bits of data together to represent 1 thing. Like a pixel, you have red, green, blue, and alpha components.

So a 32 bit pixel would look like this:

Struct Pixel
{
byte R;
byte G;
byte B
byte A;
}

This is just a simple structuring of data, so you can keep track of all the components that come together to represent a pixel. Everything is publicly visible, just like a C style struct. You can access all members like this:

Pixel pxExampleRed;
pxExampleRed.R = 255;
pxExampleRed.B = 0;
pxExampleRed.G = 0;
pxExampleRed.A = 255;

You have to remember to assign a value to all components of your struct, otherwise they will have whatever random value was set in memory where they were allocated.

Sometimes it's nice to fill out a structure to pass to a function, instead of having a giant function call that takes up 20 lines. Windows API programming is a lot like this. You can also use a structure as to return data from a function.

Classes are a bit more complicated. Their data tends to NOT be publicly visible. Instead of accessing their data directly, you call functions that will take your input and do something with it to the object that the class is representing. They also have constructors and destructors so they can handle their own initialization and clean up.

The intent of a struct is a simple grouping of data for convenience. A class is an more complex object that can take care of itself.

Structs have constructors and destructors aswell.. they get 'random' values if you dont define them (i.e the compiler generates them), which is exactly the same for a class.

Hello,

I have interfaces for virtually ( ) all classes I use; for example IThread.h, IMutex.h, IConditionVariable.h, IThreadPool.h, ISynchronizationFactory.h, etc.. and then .h/.cpp "-impl" versions of them. I use factory classes to create/destroy the implementations and then just pass around and work through the interfaces.

Questions:

• I do it because I find it clean/pleasant to work with, but quite some code I see do not use it. My question is why? Is it just a matter of taste? I know virtual methods adds an additional overhead, but besides that?
• In my factory classes I do not generally need dynamic class instantiation; for example I just have one "ThreadImpl" for win32/android, so I really could just have it return the ThreadImpl", but I prefer to work through an interface. Is it just a matter of preference or any practical reasons to chose one over the other?

Thanks