Thanks this is really helpful, I have been watching some c++ tutorials lately, is this a bad idea? So far I understand everything.
Lot's of people will tell you C++ is not for beginners but it's in fact just fine. Since you already know JAVA you should breeze right through it anyway.
I recommend if the game is 3d that you use C++ & OpenGL & Bullet Physics If the game is 2d then C++ & SDL
SDL is a library that does pretty much everything, control input, image loading, audio output, 2d graphics and more. It makes your code really portable because you need to make absolutely no OS specific calls.
I recommend you start with a platformer, that will teach you how a game works then you can move on to 3d if you so choose.
Look guys (or girls) I don't know much of anything regarding programming (as I stated before) however what I do know is....
*C++ is the standard however it has a very steep learning curb (even worse for me since I'm a beginner) *I had Java in the back of my mind for a while but I read (from other forums so don't take this as a solid point) that Java is rather dated
Since I was not so specific in my OP apparently let me ask a few other questions...
*What exactly is a library and how do I apply it into my programming? *What is an engine? (I see on various games that it is powered by so and so's engine example - from what I understand it basically runs the code??)
Please stop arguing... because a lot of what I've read has gone over my head (obviously you know more than I on the matter)
A library is essentially a piece of code that someone else has written to perform various tasks for you, for example Bullet physics is a library that will do physics calculations so you don't have to. A library is usually a dll (on windows at least) that will be linked to your code.
An engine is similar to a library and some engines are libraries but mainly they perform the various functions of a game such as rendering and such so all you have to do is write game logic.
As for language choices, just continue with what you set out to do and don't let anyone tell you otherwise. The great part about c++ is that it can be as simple or as complex as you want it to be, c++ can even be c if you want it to. The learning curve of c++ is by no means steep. C++ also happens to be compatible with more third party libraries than most other languages. Its just a pleasure to use and definetly not a noose.
If you're smart and use libraries like SDL you could easily finish a pong game in two weeks.
If you wanna use C++ (and I think you should) use VC++ 2010, I use it all the time and its great and functional and easy to use. I think the main thing new in visual studio 2012 is windows 8 integration and stuff, once windows 8 gets off the ground you should be able to move to the new IDE pretty simply by just importing your old solution files. Just letting you know that C++ was the first language I learned and it's not that hard, it's not an evil ogre like some people make it out to be, its a clean and elegant language and all kinds of third party libraries can extend its functionality. Just try C++ and if you think its too hard then switch to something else.
So I had this beautiful renderer that I wrote and then I decided to implement a particle system. The particles themselves work great but they conflict with my ssao shader because they write to the depth buffer during depth testing and end up causing an ugly shadow when ssao is reading from the depth buffer. I can solve this by disabling writing to the depth buffer but then my particles are not tested. Is there a way to depth test my particles without them being written into the depth buffer?
In order to accomplish a bilateral blur you will need to use FBOs (Frame Buffer Objects). You essentially render your scene to an FBO and then blur that in one direction. You then render the first FBO to either another FBO or to the screen then you blur that in the other direction.
Your Shaders are going to look something like this, you will have two of them, each in a different direction.
Oh, really? Please, do enlighten us on how you write GPU shaders. Do you cobble them together from C++ macros? Or perhaps you write them directly in IL assembly, hardcore-style? Also, how long does it take you to write a tool that replaces sequences of bytes in a binary buffer? Still waiting, cause in Python I'm done: buf.replace(). Oh, yours is... what? Faster? Oh, but I was only going to use it for a 10kb file anyway.
More specifically c++ is in my opinion the best general purpose language for writing games.
Once you've programmed in a sane language, C++ feels SOOOOOOO much *more* painful. I need to make my own ??what??, to do what?? Really..... sheeesh.
C++ is the only sane language.
Once you know c++ there is no reason to use anything else. Unless of course you want the best speed possible in that case you would use assembly (sometimes I use it inline with c++ just for speed). As for making your own code for complicated things you can either have fun and do it yourself or use a third party library.
I tried learning JAVA, I decided it was just like c++ but slower and with too many rules.
Thanks. I'm a little reluctant to switch to VBOs at this point, especially if the gain won't be much.
VBO's look really complicated at first but start to make sense if you just take a half hour and really just study some example code you will get them. The performance gain will be massive if you are currently using glbegin/glend but if you are already using vertex arrays then it won't be huge but still measurable.
All in all glbegin/glend sucks for speed on anything.
I'm developing an opengl application and I have cast a ray from the camera to a point in 3D space. I would like to define a plane where such point lays, with the cast ray vector perpendicular to such plane. Is it possible? If it's not clear I can make an image.
You should be able to define this plane if you know the tangent and the binormal, which can be derived from the normal.
We know that these vectors are both perpendicular to the normal. To find the tangent you will find two vectors perpendicular to the normal and pick one depending on whether the normal is positive or negative, the binormal will be the cross product of the tangent and the normal and at that point you should have enough information to define a plane, this will however be a massive burden on your CPU if you want to do this in real time so see if you can offload some calculations to the GPU using shaders or OpenCL.