Where to start ... (C++) ?

[k1net1k]

Hint: Try the ones that have 'Beginning' at the start

[szdarkhack]

OpenGL itself does not change regardless of the platform. You write the same code for Linux as you would do for Windows. However, there is a catch: creating a window and getting it to show what you're drawing. That depends on the platform, and on Windows you use the Win32 API for it. If you don't have any experience with it, you can use an open multiplatform library called SDL, which makes initializing an OpenGL window a piece of cake. The code from that point on will be exactly the same. By the way, Doom, Quake and now Rage are all OpenGL based games, so you can easily see that the API does not lack anything with respect to Direct3D

After using OpenGL for a while, Direct3D seems a bit weird, but it's very easy to transition to. That's because they both use the same concepts, just named differently. Also, D3D is object oriented, so it's constructs are structured a bit differently. I don't have that much experience with it, but i can still implement various techniques in the same way that i do in OpenGL. All in all, it's a bit uglier in my opinion (microsoft sucks at naming structs...), but easy nonetheless.

[L3V147H4N]

:3 Ty szdarkhack, that really takes off a the presure. :p i'll start then with OpenGl when im ready and then learn D3D if i need too.

there is, however, something i wonder, that i posted earlier but no one anwsered :P

About Windows not supporting OpenGL fully, i red that since Xp, OpenGl doesnt have full support and i need to install special drivers for it...

Is That True??? or just BS ??? (BullShit) ... :P

I tryed to play HoN the other day using OpenGL and the result was not so "Smooth"... :P so i wonder....


Do you know something bout this???

[BugInTheSYS]

:3 Ty szdarkhack, that really takes off a the presure. :p i'll start then with OpenGl when im ready and then learn D3D if i need too.

there is, however, something i wonder, that i posted earlier but no one anwsered :P

About Windows not supporting OpenGL fully, i red that since Xp, OpenGl doesnt have full support and i need to install special drivers for it...

Is That True??? or just BS ??? (BullShit) ... :P

I tryed to play HoN the other day using OpenGL and the result was not so "Smooth"... :P so i wonder....


Do you know something bout this???

BS
Windows doesn't need to support GL, your graphics adapter and driver need to

[szdarkhack]

BS
Windows doesn't need to support GL, your graphics adapter and driver need to

Pretty much that. In more detail, Microsoft has a "thing" against everything that doesn't belong to them, so they stopped supporting OpenGL after version 1.2 (that's the header version they provide). Seems bad, right? Well, fear not! At least they included a function that returns function pointers for any OpenGL call supported by the graphics driver. So you need to load them. All of them. In code. Yeah...

But again, fear not! Some good people have released a MUST HAVE library called GLEW (GL Extension Wrangler). Here's a convenient link: http://glew.sourceforge.net/
So what does this do? It grabs all the function pointers for you with one call. That's right, you just initialize the library (inside a working OpenGL context, mind you) and it automagically loads all the functions above the version Microsoft "graciously" provides. So there you go.

By the way, GLEW also allows you to load any extensions that your driver supports. The first example that comes to mind (since practically all drivers support it) is anisotropic filtering for textures. The library's homepage has examples on how to do this.

In short, your initialization (on Windows at least) should be like this:
-Create window
-Create device and rendering context (i strongly suggest SDL for this, it is much, MUCH more complicated to do in pure Win32)
-Initialize GLEW
-OpenGL should work fine now

EDIT: I forgot to mention that you won't need to include "GL.h" anymore, just "glew.h". It contains the prototypes for all OpenGL calls so you'll be covered by just that (it also includes "GL.h" itself if i remember correctly).

[L3V147H4N]

Heloow,,, ty again szdarkhack, ill look into it when i start looking into OpenGl. ( Do I need the wrangler for Playing games that use OpenGL ???? or should I find a supporting Driver???)

i just red lots and lots of articles related to Graphics APIs and else.

Aparently Microsoft's stubborn inner child made its way up with Directx despite all the critisims,,, (even from Carmack), i guess money makes us all do almost anything :3, no matter the cost.

Anyway, conclusion of everything is: D3D is for Games ..... OpenGL is for everything ! :3 ... im inclined to believe D3D would be the way to go in the future, mainly because Windows is the game plataform, and D3D is native graphic API for win (basically) and despite my thoughts on Microsoft intentions to FORCE the use of their ideas to everyone ... :P (as i said: my intention is to develop games) i think imma learn a bit a OpenGl to get started and then go full into D3D ... :3 i dont have any wish to become of this "API war" as it was called a few year back. And even probably OpenGL is the way to go (in terms of complexity and performance) :p but we will see in the next few years who takes the cake concerning Gaming Development.

.... ( I though the Fareheit API project was i good idea :3, but investors did not agreed :3 ) .... http://en.wikipedia.org/wiki/Fahrenheit_graphics_API

On a different, but Not Unrelated topic: AMD Radeon or NVIDIA?????

Thx again for all the support, good to be part of this forum :D

[szdarkhack]

Heloow,,, ty again szdarkhack, ill look into it when i start looking into OpenGl. ( Do I need the wrangler for Playing games that use OpenGL ???? or should I find a supporting Driver???)

Always glad to help. And no, you do not need any libraries for playing games, only up to date drivers. These libraries are for development.

Anyway, conclusion of everything is: D3D is for Games ..... OpenGL is for everything ! :3 ... im inclined to believe D3D would be the way to go in the future, mainly because Windows is the game plataform, and D3D is native graphic API for win (basically) and despite my thoughts on Microsoft intentions to FORCE the use of their ideas to everyone ... :P (as i said: my intention is to develop games) i think imma learn a bit a OpenGl to get started and then go full into D3D ... :3 i dont have any wish to become of this "API war" as it was called a few year back. And even probably OpenGL is the way to go (in terms of complexity and performance) :p but we will see in the next few years who takes the cake concerning Gaming Development.

Do not be confused here. Both APIs are implemented in the driver, NOT the operating system. A well written driver will have similar performance with both. The only problem with Windows is that it makes it more complicated to talk to the driver using OpenGL. There is no other difference. Once you have your window up and you have created your context, you do NOT talk to the operating system to draw, you talk straight to the driver. My point is that the fact that D3D is "native" makes absolutely no difference other than the fact that it's easier to get started.

On a different, but Not Unrelated topic: AMD Radeon or NVIDIA?????

That is a very controversial question. I have a PC with an nVidia card and a laptop with an ATI card (both same generation, similar performance). If you look at the specs, you will see that ATI's cards are cheaper than nVidia's (i'm talking about equivalent cards). So that's a point for ATI. However, alliances in the industry are very real, and you will often see games that *intentionally* work better with one vendor rather than the other (EA comes to mind, forcing PhysX and destroying performance on ATI setups). So there you go. You get similar performance from both, but you need to consider if getting an nVidia card is worth the extra cash. Oh, and a minor point, *usually* nVidia makes better drivers, but unless you're developing (or playing) on the absolute cutting edge, you won't see any difference on that front (A striking example is the release version of Rage. It had some very serious issues on ATI cards because of driver problems.)

[Rebornxeno]

Whadup! Programming is the shit dawg, until you run into loads of bugs. Once you squash them though, it'll be like you just had sex. I would say opengl is probably what you will end up sticking with, but who knows. I also recommend going with an Nvidia card, because the latest cards provide great support for things that ATI doesn't care about. Things like CUDA. I have an ATI card and I kinda wish I woulda went with Nvidia :P Opengl works fine for me on windows 7.

[dandymcgee]

Whadup! Programming is the shit dawg, until you run into loads of bugs. Once you squash them though, it'll be like you just had sex.

Lmfao, sig'd.

[szdarkhack]

Whadup! Programming is the shit dawg, until you run into loads of bugs. Once you squash them though, it'll be like you just had sex. I would say opengl is probably what you will end up sticking with, but who knows. I also recommend going with an Nvidia card, because the latest cards provide great support for things that ATI doesn't care about. Things like CUDA. I have an ATI card and I kinda wish I woulda went with Nvidia :P Opengl works fine for me on windows 7.

You do realize that ATI fully supports OpenCL, right? It's just like CUDA, except that it's open and it also integrates somewhat with OpenGL (although there's a lot of room to improve on that). It's also supported by nVidia by the way. Now, there are APIs like PhysX that are coded intentionally for CUDA and not for OpenCL for obvious reasons (hint: nVidia made both). There are also companies that believe that having "friends on one side" and using such APIs is worth ruining the performance of their games for half their clients. Sad but true. THIS is why you're better of with nVidia cards, because they have many "friends". NOT because of technology differences.

I'm sorry for being aggressive here, but i happen to hate marketing techniques that involve misinforming the public and making contracts "under the table". At least there are a few people in the industry who see behind the BS, and choose to use standardized and open APIs.

[qpHalcy0n]

nVidia *OPTIMIZES* PhysX via CUDA because CUDA predates OpenCL. CUDA was the first foray into GPGPU if you don't count CTM/Stream which also predate OpenCL. OpenCL is an apple concoction w/ collab from nVidia, AMD, IBM, and a few other vendors. The software implementation of PhysX is extremely efficient. Secondly, it's not accurate to put CUDA against OpenCL. CUDA is the facility via which OpenCL is presented. OpenCL is only able to be run via CUDA. Similarly, OpenCL would run via Stream.

nVidia and AMD architectures are significantly more divergent than you might think. OpenGL is also a quagmire of failed attempts at reunification of a failed API. I've gone on very very long tirades about why this is the case, so I won't go into that here. There is an element of competition there, but neither graphics API coded on either card on any platform should have no advantage over the other. They're all extremely competitive. Most of what will bite you in the ass is exploiting inefficient or old technology. In OpenGL its VERY VERY easy to do this. In DirectX its impossible to do this. In either, its ALWAYS possible to write horrible code.

This is where the disparity lies....a lack of unification. OpenGL does NOT have (despite their versioning...which again I've gone on at length about) a solidified standard. Nor will they ever. So I liken it to how Stroustroup analogizes C and C++. "C makes it easy for you to shoot yourself in the foot, C++ makes it harder, but when you do, you blow your whole leg off". Perfect analogy to the DX/OpenGL argument.

[szdarkhack]

nVidia *OPTIMIZES* PhysX via CUDA because CUDA predates OpenCL. CUDA was the first foray into GPGPU if you don't count CTM/Stream which also predate OpenCL. OpenCL is an apple concoction w/ collab from nVidia, AMD, IBM, and a few other vendors. The software implementation of PhysX is extremely efficient. Secondly, it's not accurate to put CUDA against OpenCL. CUDA is the facility via which OpenCL is presented. OpenCL is only able to be run via CUDA. Similarly, OpenCL would run via Stream.

You are absolutely correct on calling me out on this, i did not express myself correctly. What i meant to say was that there are higher level, open alternatives like OpenCL that work on both vendors' products (via CUDA or Stream) that should be preferred since they work pretty much the same on any similar card. Using APIs such as PhysX that only work well on one vendor's cards is stupid, in my opinion, since half your customers will get the "crippled version" of your game. I'm not saying that nVidia is the only "bad guy", ATI has done many idiotic things as well, such as blatantly blocking PhysX coprocessors in their drivers.

nVidia and AMD architectures are significantly more divergent than you might think. OpenGL is also a quagmire of failed attempts at reunification of a failed API. I've gone on very very long tirades about why this is the case, so I won't go into that here. There is an element of competition there, but neither graphics API coded on either card on any platform should have no advantage over the other. They're all extremely competitive. Most of what will bite you in the ass is exploiting inefficient or old technology. In OpenGL its VERY VERY easy to do this. In DirectX its impossible to do this. In either, its ALWAYS possible to write horrible code.

I get your point, although using the core specifications you're somewhat safer. It is true that OpenGL has a LOT of issues that Direct3D does not (main examples: the default framebuffer should not exist, texture sampling state should not be bound to texture units, just "attached", OpenCL integration has issues that compute shaders do not, like flushing the pipeline when switching between the APIs), however i will always choose a multiplatform API over an OS specific one, unless there is absolutely no way that i can implement what i want using it.

Anyway, i apologize once again for the aggression in my previous post, apparently 4am is not a good time for me to be posting...

[The Awesome Twin]

My personal recommendation for starting C++, would be to learn how binary works. What a bit is, what a byte is, all that awesome low level stuff that you probably think you'll never learn. Quite a long time ago I tried to learn C++ through online tutorials, but I couldn't manage it on my own. When I bit the bullet an paid tution to learn, this was the first thing they taught us. And I swear in C++ you need to understand low level concepts, mainly how the memory is stored. It simplifies everything, makes it clear why you have different variable types. The difference between a signed int and an unsigned int, a float and a double, etc, etc.

Also on your list of books, I can say Beginning C++ through game programming, Beginning Direct X 9 and 3D math primer for graphics and game development, are all above average. Especially that math book, there are certain sections of the books that will show you a bad practice or two, such as the directx book showing in the sprite section to use lock rect, which is performance heavy, you'd actually be better off drawing quads with textures on them. As for the math book, the main concern with it is the format of equations and such, It's written the same way stage two stuff at university supposedly is, have never graduated high school decrypting some of it was a challenge, but it does have all of the content you need to build up the knowledge to right a full on 3D renderer, which is also a great base knowledge to learn how to use and existing renderer like OpenGL, or DirectX.

The only other thing I can say is, if you learn DirectX first, remember that it is designed like a state machine. That makes wrapping your head around it easier. And while I've only just started some self directed study into OpenGL in my spare time, I can say that I've had a veteran game programmer, and a veteran visualization programmer, both say that OpenGL is easier to learn and more pleasant to work with.

[Van-B]

Personally I think your a victim of procrastination.

If you know the basics of C++, then C++ is waiting on you to start using it - you shouldn't be worried about the specifics, because you need to know what the specifics are first. Too many people avoid starting game creation in C++ because it's some monster language, they look at library code and don't understand it, and they let that crap stop them.

The bottom line is that most game code that you'd deal with is pure logic, straightforward stuff... as far as syntax goes at least. I would strongly advise you to just pick a game example, or a game engine, and strip it down to the bare bones, like being able to render a polygon with a texture in OpenGL. Take that, then go and make a game with it, work at your own pace making tech demos, look at ways to have several polygons drawn at a time, point sprites, all the things that are useful for making games. The main thing is to just start. Hell, I just started using C++ after reading 'Beginners Guide to C++', that's the summation of all my C++ knowledge, and with a little determination that is enough to start writing games... especially if you have experience already.

I firmly believe that true learning is fueled by necessity - we didn't learn how to make fire so that our caves would have a nice homey feel to them, we were hungry and cold. If you really want to write a game, then you will, you just need that mindset that failure is not an option and C++ will just have to roll with the punches goddamit!

[Obscurity]

I agree with Van-B.

With a light at the end of the tunnel, there is no need to construct a light, to enter the tunnel!