Okay, so I'm new to C++ but not new to programming. I have looked at C++ in the past out of brief interest but only recently started to take an interest to it after having messed around with Java and Processing for about two years (java) and one year (processing).
I developed this in Processing which used a ported version of box2d Physics which was originally in C++ afaik
[url]http://vimeo.com/18608167[/url]
Anyway, I'm interested in C++ more so as I wish to go down the route of one day hopefully being a developer, currently studying C++ in my second year but seeing as i've already familiarized myself with the basics and general stuff (pointers,prototypes,virutals, etc) about C++ I want to move onto things a little more complicated.
Out of interest would something like OpenFrameworks, Ogre3D, things like this be suitable?
Regards,
Graymic
[QUOTE=graymic;32224600]Okay, so I'm new to C++ but not new to programming. I have looked at C++ in the past out of brief interest but only recently started to take an interest to it after having messed around with Java and Processing for about two years (java) and one year (processing).
I developed this in Processing which used a ported version of box2d Physics which was originally in C++ afaik
[url]http://vimeo.com/18608167[/url]
Anyway, I'm interested in C++ more so as I wish to go down the route of one day hopefully being a developer, currently studying C++ in my second year but seeing as i've already familiarized myself with the basics and general stuff (pointers,prototypes,virutals, etc) about C++ I want to move onto things a little more complicated.
Out of interest would something like OpenFrameworks, Ogre3D, things like this be suitable?
Regards,
Graymic[/QUOTE]
Both has their uses, that depends on what you want to do.
[QUOTE=T3hGamerDK;32225966]Both has their uses, that depends on what you want to do.[/QUOTE]
I ultimately want to go down the route of rather simple game development so I can get to grips with how games work in C++ in comparison to other engines. But I guess I'm a tad scared of all there is to learn with C++ and general game development methodologies.
What would you say is the "Easier" of the two to grasp. I get the impression that openFrameworks is less C++ like in comparison to ogre, in the sense that it mirrors a lot of what processing does with the whole
exampleName::update();
exampleName::draw();
methods. But then having never developed anything game related as such in C++ I could be severely mistaken.
You should never be afraid to learn. I would personally recommend working directly with OpenGL bindings, even if you start with immediate mode (very simple, very slow, almost 20 years old) and work your way up to modern OpenGL with the programmable pipeline and all the other fancy stuff.
The reason I suggest this is because it'll take a lot of the mystery away from how graphics are rendered, and immediate mode is extremely simple and easy to learn. I can even start you off with a little primer on how things are rendered with immediate mode...
So I'll start with exactly how you plot a 3d vertex on a 2d screen. With immediate mode OpenGL, you are provided 2 methods to project 3d vertices on your screen, glOrtho and gluPerspective. You can imagine both of these as 3d shapes, Ortho being a cube and Perspective being a cube that tapers down on one side. There are two planes worth noting, the near clipping plane and the far clipping plane. Looking at the projection from one side (for perspective the side you're looking through is the one that's tapered down), the near clipping plane is the plane closest to you and the far clipping plane is the plane farthest from you. Anything closer to you than the near clipping plane gets clipped off, as does anything further back than the far clipping plane.
The projections are represented by 4x4 matrices. There are a few matrices you should take note of, and this one (the projection matrix) is one of them. The other one is the "ModelView" matrix. Generally when you have objects in 3d space, you don't calculate it's position or rotation into the actual vertices. You will generally define it as vertices centered around (or starting at) (0,0,0). Immediate mode OpenGL can do the movement, rotation, and scaling for you (glTranslate, glRotate, glScale). Calling those methods multiplies a matrix representing the transformation with the current model matrix. That is, it accumulates all transformations. You can save a matrix at any state by pushing it onto the matrix stack (glPushMatrix) and after transforming an object you can replace the current matrix with the old one (glPopMatrix). This is very commonly done so that each rendered object can have separate transformations without affecting any other object. You can also replace the modelview matrix with a fresh one that doesn't have any transformations by calling glLoadIdentity. The modelview matrix also stores camera transformation, which is why people generally use glPushMatrix and glPopMatrix instead of just calling glLoadIdentity after each object renders.
Matrices are going to be the hardest part to understand of OpenGL. If you were to follow an actual tutorial, they would cover everything I stated above with 10 lines of code, and that's all you'll need to know about it for learning just the basics. The really important part of OpenGL is the actual drawing of objects on the screen. you start rendering with a call to glBegin and end rendering with a call to glEnd. glBegin accepts many different rendering modes as parameters - you can draw points, lines, triangles, quads, etc.
Between glBegin and glEnd you can make specific method calls. You can define a vertex in your own projected and transformed space with glVertex(2/3/4)(i/f/d). If you're wondering why there are 4 values that can be defined for 3d objects, the 4th coordinate is used for perspective correction, and will almost always stay at 1. Modifying that value will make your objects look really strange. You shouldn't really worry about perspective correction at this point, but if it interests you go and read more about it.
Within glBegin and glEnd you can make a few other calls to modify how things work - glColor(2/3)(b/s/i/f/d/ub/us/ui) to change the color of the vertex. OpenGL will interpolate colors for you to make gradients. You can map a texture to an object using texture coordinates, and pass them in with glTexCoord(1/2/3/4)(s/i/f/d) to map a position on the texture to the vertex. If you're doing 3d you can also pass in vertex normals for lighting, and a few other things.
This wasn't really designed to be comprehensive or by any means complete. There's some extra work you'll have to do to set up a window and create the OpenGL context, and a few small bits here or there that aren't really important that I didn't mention. If this interested you, I would recommend looking up some tutorials for OpenGL 1.1 or 1.2 or something really old like that.
If you're wondering how OpenGL evolved after that, vertices were sent in arrays instead of sent one by one with glVertex calls. After that, you would define the vertices once at the beginning of the program and send them to VRAM (graphics card RAM), then just tell OpenGL to render the vertices from it's own RAM. After that, you tell OpenGL to send the vertices over to a small "shader program" you wrote that does the rendering instead of the fixed functions that OpenGL supports.
Even if that was aimed at him, that was very helpful for me too. Thanks!
I also have most of modern OpenGL down, save for some things dealing with framebuffers, and I haven't yet used the stencil buffer or scissor testing. I could probably help Overv with open.gl or at least review/edit/proofread the stuff he writes. Or like maybe write a version of it for OpenTK, which I know inside out at this point. Of course he's got to finish the main versions so that I can write directly against the C++ versions.
[QUOTE=robmaister12;32228930]I also have most of modern OpenGL down, save for some things dealing with framebuffers, and I haven't yet used the stencil buffer or scissor testing. I could probably help Overv with open.gl or at least review/edit/proofread the stuff he writes. Or like maybe write a version of it for OpenTK, which I know inside out at this point. Of course he's got to finish the main versions so that I can write directly against the C++ versions.[/QUOTE]
I wonder if he will add a language thing so we can help him add different language examples
[QUOTE=graymic;32224600]
I developed this in Processing which used a ported version of box2d Physics which was originally in C++ afaik
[url]http://vimeo.com/18608167[/url]
[/QUOTE]
I can't help you with what you asked for. Since I haven't done any C++.
But I want to check out that Physics Box you made :D.
What do I need to start it and where can I download it?
[QUOTE=Map in a box;32228977]I wonder if he will add a language thing so we can help him add different language examples[/QUOTE]
would be nice to have some of the cross platform stuff in there, OpenTK, LWJGL/JOGL, possibly even the iOS bindings and the Android bindings?
Rob that was indeed, incredibly helpful. I think I will take a look at this in-depth now. If I can get to grips with this first then i'll go back to the other aspects later on. Thank you for this, I'll have to re-read over some parts as the openGL aspects are still fairly new to me (understanding how they work). I totally see the relation with the push, pop matrix now though which explains a few questions I had regarding my earlier development in Processing.
[editline]11th September 2011[/editline]
[QUOTE=Danny Phantom;32229032]I can't help you with what you asked for. Since I haven't done any C++.
But I want to check out that Physics Box you made :D.
What do I need to start it and where can I download it?[/QUOTE]
Processing was pretty easy, and considering the library was just ported by Shiffman to Java it meant all I had to do was learn his library.
But that really got the snowball effect on me and I wanted to really understand how rendering and things like that work in games really,
But you can get the library here: [url]http://www.shiffman.net/teaching/nature/box2d-processing/[/url]
It's all in Processing (Java - somewhat) but it's not "true" OO in comparison to C++ or Java on its own as processing seems to be very simplified. Alas on to more complicated things I guess as it's getting my brain working again hah!
[QUOTE=graymic;32231765]
But you can get the library here: [url]http://www.shiffman.net/teaching/nature/box2d-processing/[/url]
It's all in Processing (Java - somewhat) but it's not "true" OO in comparison to C++ or Java on its own as processing seems to be very simplified. Alas on to more complicated things I guess as it's getting my brain working again hah![/QUOTE]
Thanks :).
[url]http://old.cokeandcode.com/node/1438[/url]
Check out fizzy
Sorry, you need to Log In to post a reply to this thread.
