Hello, everyone! I have some questions that I know your dying to answer, but first I'd like to thank everyone for helping out rookie developers like myself.
You advice and knowledge is continuously invaluable.
Now, before I ask my questions, I'd like to talk about my project goals, so that you can get a better idea of what I should do.
+ i'm going to use OpenGL.
+ i'd like to create a scenic environment - pushing visual distances at 60fps is the goal.
+ i'm concerned with artistic appeal and functional speeds, i'm not worried about accurate physics, etc.
+ i am interested in cell shading, and also i am interested in a programmable pipeline.
+ i'd like to be able to support most platforms in the future with minimal future optimization.
Now my first consideration involves what version of OpenGL I should utilize/support.
Correct me if any of this information is incorrect.
OpenGL has a new version 4.2, which uses the harshly modified API since 3.3 (i think).
Software has revealed that my current graphics card only supports OpenGL 2.1.
It seems like newer graphics cards supporting higher versions are still somewhat rare and expensive.
I can buy one, but I'd like to maximize my audience. I'm thinking most people have older graphics cards.
So then I could use the older API, but I'd hate to learn something that is completely out of date.
Then again, good tutorials for 4.2 are scarce, but plentiful for older versions.
Or I could take the middle ground and shoot for a graphics card supporting 3.3.
What version should I focus on?
Also, is OpenGL standard on all computers? Are updated versions backwards compatible?
My second consideration is which programming language I should use.
My choices are C++ or C#.
People have recommended C#, which means I would have to use OpenTK.
There are only a few good tutorials for OpenTK, and no books.
I prefer programming in C#.
C++ has a huge collection of help and helpful people.
C++ has tons of tutorials and tons of books, a lot of which are out of date, however.
If I chose C#, C++ tutorials will confuse me much more. I'm kind of a one-trick-at-a-time pony, so if I pick a language for a project I like to think in that language only.
OpenGL considerations
I'd shoot for OpenGL 2.1 here given your requirement of wider ranging hardware support, but - and I accept that this is going against your first decision - if hardware support was a higher concern than platform portability, I would have a strong preference for D3D9. The primary reason why is that driver support and quality (in particular on Intel and AMD) is going to be much better than you'll get for OpenGL (many business class PCs and laptops don't even come with an OpenGL driver installed). This of course depends heavily on your target audience, so I'd let that make the decision rather than personal preferences.
I'll let others handle the language part of your question.
I'll let others handle the language part of your question.
Where shaders are concerned, I think it's pretty common to have OpenGL 2.x be the minimum (with 2.0, shaders were formally included in OpenGL and was not an extension). If you're targeting PC's, most hardware today should be able to run that. Now that may be a different story for other devices...
I would guess the reason why there are not a whole lot of tutorials on OpenTK (there are some on their site, and of course their API documentation) is because the actual GL calls are practically identical to the GL calls you'd be making in C++. I do not believe OpenTK diverges much from the OpenGL API at all, except for parts of OpenTK such as their math library or window creation (e.g. GLControl). There wouldn't be any books on using OpenTK, because it's more of a wrapper than anything (and a thin one at that too).
So, most C++ tutorials in learning how to program using OpenGL should apply relatively effortlessly to OpenTK, at least the ideas in what GL calls to make and program organization. And of course GLSL tutorials won't have that problem
. If you're comfortable with C# and that's your language of choice, go for it.
I'm not entirely sure on the bit about OpenGL being standard on most computers. I know on Windows there is a microsoft implemented version of openGL that should exist, what version of OGL it is I don't know.
I would guess the reason why there are not a whole lot of tutorials on OpenTK (there are some on their site, and of course their API documentation) is because the actual GL calls are practically identical to the GL calls you'd be making in C++. I do not believe OpenTK diverges much from the OpenGL API at all, except for parts of OpenTK such as their math library or window creation (e.g. GLControl). There wouldn't be any books on using OpenTK, because it's more of a wrapper than anything (and a thin one at that too).
So, most C++ tutorials in learning how to program using OpenGL should apply relatively effortlessly to OpenTK, at least the ideas in what GL calls to make and program organization. And of course GLSL tutorials won't have that problem
. If you're comfortable with C# and that's your language of choice, go for it.I'm not entirely sure on the bit about OpenGL being standard on most computers. I know on Windows there is a microsoft implemented version of openGL that should exist, what version of OGL it is I don't know.
Author
I'd shoot for OpenGL 2.1 here given your requirement of wider ranging hardware support, but - and I accept that this is going against your first decision - if hardware support was a higher concern than platform portability, I would have a strong preference for D3D9. The primary reason why is that driver support and quality (in particular on Intel and AMD) is going to be much better than you'll get for OpenGL (many business class PCs and laptops don't even come with an OpenGL driver installed).
I'm using OpenGL and not using DirectX for this very reason - Microsoft uses their majority to further monopolize every possible software market. When they have the best audience, we tend to want to aim in that direction, but we have to cut out on the smaller half of our audience just because Microsoft demands to one up the competition. It's really frustrating because if they would just support OpenGL, I, as a developer, wouldn't have to jump through a hundred and fifty different hoops just to support anyone besides windows. And that's the point - Microsoft is making it difficult for me to justify development for Macs/Linux. Lots of people only own a Mac/Linux. It's not good for me when they act so selfishly, so I cannot break my moral code and go there.
I do like Microsoft, I just don't like how they handle competition.
Where shaders are concerned, I think it's pretty common to have OpenGL 2.x be the minimum (with 2.0, shaders were formally included in OpenGL and was not an extension). If you're targeting PC's, most hardware today should be able to run that. Now that may be a different story for other devices...
So are you implying that I should focus on the old OpenGL 2.x?
I would guess the reason why there are not a whole lot of tutorials on OpenTK (there are some on their site, and of course their API documentation) is because the actual GL calls are practically identical to the GL calls you'd be making in C++. I do not believe OpenTK diverges much from the OpenGL API at all, except for parts of OpenTK such as their math library or window creation (e.g. GLControl). There wouldn't be any books on using OpenTK, because it's more of a wrapper than anything (and a thin one at that too).
So, most C++ tutorials in learning how to program using OpenGL should apply relatively effortlessly to OpenTK, at least the ideas in what GL calls to make and program organization. And of course GLSL tutorials won't have that problem
I thought this might be the case with OpenTK, but I'm still rather new to 3d programming and so I wasn't sure. This is great news.
My second consideration is which programming language I should use.
My choices are C++ or C#.
Both of these languages will perform just fine. C++ does beat C# in speed, but the difference is not that significant. C++ is more widely used in professional game programming. So if you plan on going into game programming you will eventually need to learn C++ but don't feel you need to learn it right away.
What I say is if you are comfortable with C# use C#. You will get good experience learning how to structure games and solve many problems that occur in game development regardless of the language. You can learn how to manage memory and pointers in C++ later in another project or on the side.
Those are my two bits.
Of course, game programming is one of the many topics that is a part of computer graphics . While C++ may be a must for most mainstream game development (and there certainly are examples of Indie games being successful in C# and Java, but they are rare and far between), it's not necessarily a set in stone requirement. Not to mention, you can offload a lot of work to the GPU making the choice of language not all that important where rendering is concerned. Now it can be a concern for CPU intensive computations, like physics. Also, tools programming such as design & simulation software (not just games, but for for engineering applications and etc) can benefit from being written in a managed language - and still allow developers to do some cool graphics work. Personally, that's where my interest lies in (as well as my day job), and not game development.
Well, this is what I was thinking of:
-Shaders are a must (programmable pipeline you said)
-Support as much hardware as possible
Then your minimum would be OGL 2.0. The next question to ask is:
What are your technical requirements?
You mention cel shading and a scenic environment. A beautifully rendered scene does not necessarily call for very advanced shaders, nor does a cel-shading shader (there are many examples of such shaders on the web). Such a scene may have dynamic lighting + shadows, or just use shadow maps. The scene may make great use of beautiful artwork in conveying a stylish theme (opposed to trying to be realistic). Maybe use some bump mapping to add detail to geometry - all of these things are doable in OGL 2.0 w/ shaders.
Then what graphics features might you require to accomplish this? Do you need multiple render targets (e.g. for defered rendering?) (OGL 2.0) Do you need instancing? (3.0) Geometry shaders? (3.2) Tessellation? (4.0?) So it depends on what you're trying to do. If you're just going to put together a nice looking scene, you don't necessarily need to start out with the absolute latest version of OpenGL.
. While C++ may be a must for most mainstream game development (and there certainly are examples of Indie games being successful in C# and Java, but they are rare and far between), it's not necessarily a set in stone requirement. Not to mention, you can offload a lot of work to the GPU making the choice of language not all that important where rendering is concerned. Now it can be a concern for CPU intensive computations, like physics. Also, tools programming such as design & simulation software (not just games, but for for engineering applications and etc) can benefit from being written in a managed language - and still allow developers to do some cool graphics work. Personally, that's where my interest lies in (as well as my day job), and not game development.
Where shaders are concerned, I think it's pretty common to have OpenGL 2.x be the minimum (with 2.0, shaders were formally included in OpenGL and was not an extension). If you're targeting PC's, most hardware today should be able to run that. Now that may be a different story for other devices...
So are you implying that I should focus on the old OpenGL 2.x?
Well, this is what I was thinking of:
-Shaders are a must (programmable pipeline you said)
-Support as much hardware as possible
Then your minimum would be OGL 2.0. The next question to ask is:
What are your technical requirements?
You mention cel shading and a scenic environment. A beautifully rendered scene does not necessarily call for very advanced shaders, nor does a cel-shading shader (there are many examples of such shaders on the web). Such a scene may have dynamic lighting + shadows, or just use shadow maps. The scene may make great use of beautiful artwork in conveying a stylish theme (opposed to trying to be realistic). Maybe use some bump mapping to add detail to geometry - all of these things are doable in OGL 2.0 w/ shaders.
Then what graphics features might you require to accomplish this? Do you need multiple render targets (e.g. for defered rendering?) (OGL 2.0) Do you need instancing? (3.0) Geometry shaders? (3.2) Tessellation? (4.0?) So it depends on what you're trying to do. If you're just going to put together a nice looking scene, you don't necessarily need to start out with the absolute latest version of OpenGL.
Author
Both of these languages will perform just fine. C++ does beat C# in speed, but the difference is not that significant.
Thank you HappyCoder. You've put my mind at ease on the speed worries. But say, do you think the speed will hold up cross platform? I hear that Mono has (or possibly had*) inefficiencies.
Of course, game programming is one of the many topics that is a part of computer graphics
That's just great to hear! I'm not worried about physics, or other things like that. Anything I do make complicated i probably won't be needing real time for.
Do you need multiple render targets (e.g. for defered rendering?) (OGL 2.0) Do you need instancing? (3.0) Geometry shaders? (3.2) Tessellation? (4.0?)
I'll take this short but insightful list into consideration. (update: I have added my research questions to the bottom.)
But my primary concern was learning outdated structure and things. I'm thinking about going with the earliest form that will actually teach me modern OpenGL and not oldschool OpenGL that will only throw me off in the long run.
Sheesh thanks for the help, Starnick!
So multiple render targets prevents me from drawing everything multiple times? That would only help if I was using a lot of lights or a lot of shaders, right?
Geometry Instancing might be good for my project. I'm using my own terrain engine with integer based coordinates, kind of like a terrain map but more locked in. I guess it works a bit like marching cubes. Do you think that it would help with that?
Man all of this advancement is so interesting! I really want to use the most up to date version just to take advantage of it all! But leaving out the average computer is just not okay... Tragedy of my life!
GL 2.0 / 2.1 is a good choice, it's when shaders became standard (so you've got a lot of flexibility/power), but is compatible with hardware going back about 5/6 years.
As a rough guide to different versions of hardware/APIs:
Shader Model 1 -- D3D8 -- OpenGL1.4? -- Xbox
Shader Model 3 -- D3D9c -- OpenGL 2 -- Xbox360 -- PS3
Shader Model 4 -- D3D10 -- OpenGL 3
Shader Model 5 -- D3D11 -- OpenGL 4
You can use Wikipedia's lists to see which vendors were supporting which API versions at different years:
http://en.wikipedia....rocessing_units
http://en.wikipedia....rocessing_units
http://en.wikipedia.org/wiki/Intel_GMA
Firstly, Microsoft does support OpenGL. OpenGL is a first class citizen on Windows, even on Windows 7, having the same level of driver integration as D3D has. They even provide a default fall-back implementation of the GL runtime for when drivers are non-GL-compliant so that you can always assume a PC has GL1.2 support.
Secondly, Microsoft has achieved far more for the real-time graphics community than the GL committees ever have. Microsoft keeps on top of the ball with developments in graphics hardware, working hand-in-hand with the manufacturers to ensure that the latest D3D API closely matches the hardware architectures. They specify an extremely strict interface for the API, which nVidia/ATI have to stick to exactly, and provide a software reference implementation to exactly test application/driver conformity. As for developers, they give me documentation on both GL and D3D and have developed a free graphics-API debugger that rivals the expensive Xbox/PS3-specific tools used by console developers.
On the other hand, OpenGL's design-by-committee nature means that for the past 5-10 years it has been lagging behind modern hardware architectures constantly. The API has become so cluttered with different ways to achieve the same task, that you're left to evaluate the 5 different options and try to guess which one actually matches the current hardware (i.e. the fast path), which ones are going to be emulated in hardware (the slow path) and which ones are going to be emulated in software (the 1FPS path). The API redesign so desperately required to solve this issue, will simply never happen, as there will always be some selfish committee member opposed to losing old emulated functionality (whereas Microsoft has had the balls to dictate an up-to-date specification). Conformance with the GL API isn't regulated or enforced by the committee, with different drivers offering widely different capabilities, bugs and performance issues (the previously mentioned software emulation modes can kick in without any way for you to tell programmatically).
This lack of standards-enforcement is so bad that the hardware vendors abuse the situation in unethical ways to gain market advantages and sabotage their competitors, e.g. by supplying OpenGL drivers that allow developers to unintentionally use undocumented vendor-specific features (which will fail on the competition's hardware). This practice only hurts developers, by encouraging them to ship products with incompatibilities and hardware-specific bugs.
In actuality, the ease-of-development and debuggability of D3D means that I can use my D3D renderer to diagnose bugs in my GL renderer (but never vice versa).
Microsoft have not made it any harder on me to use OpenGL, all they've done is turn D3D into a brilliant product (in this instance, they're using honey, not vinegar).
Meanwhile, Apple chose to license OpenGL for their OS, instead of licensing D3D, and they also have put no effort into making their OpenGL implementation into as good of a product as D3D (to their credit, they do however implement most of OpenGL themselves, stopping the hardware vendors from exploiting developers as mentioned above).
Linux is another kettle of fish -- there's no one with money behind it to license either OpenGL or D3D, so you've got to put up with the unauthorised Mesa drivers, hacky open-source hardware drivers, closed-source proprietary drivers with bad support, or the reverse-engineered D3D contained in Wine. None of those are attractive avenues, and none of them provide the level of support that you get from an evil corporation.
As a rough guide to different versions of hardware/APIs:
Shader Model 1 -- D3D8 -- OpenGL1.4? -- Xbox
Shader Model 3 -- D3D9c -- OpenGL 2 -- Xbox360 -- PS3
Shader Model 4 -- D3D10 -- OpenGL 3
Shader Model 5 -- D3D11 -- OpenGL 4
You can use Wikipedia's lists to see which vendors were supporting which API versions at different years:
http://en.wikipedia....rocessing_units
http://en.wikipedia....rocessing_units
http://en.wikipedia.org/wiki/Intel_GMA
... It's really frustrating because if they would just support OpenGL, I, as a developer, wouldn't have to jump through a hundred and fifty different hoops just to support anyone besides windows ...Yes microsoft is a big evil corporate that abuses things for profit (it's pretty hard to deny this fact), however, this particular rant is very misguided, so here's a counter rant:
Firstly, Microsoft does support OpenGL. OpenGL is a first class citizen on Windows, even on Windows 7, having the same level of driver integration as D3D has. They even provide a default fall-back implementation of the GL runtime for when drivers are non-GL-compliant so that you can always assume a PC has GL1.2 support.
Secondly, Microsoft has achieved far more for the real-time graphics community than the GL committees ever have. Microsoft keeps on top of the ball with developments in graphics hardware, working hand-in-hand with the manufacturers to ensure that the latest D3D API closely matches the hardware architectures. They specify an extremely strict interface for the API, which nVidia/ATI have to stick to exactly, and provide a software reference implementation to exactly test application/driver conformity. As for developers, they give me documentation on both GL and D3D and have developed a free graphics-API debugger that rivals the expensive Xbox/PS3-specific tools used by console developers.
On the other hand, OpenGL's design-by-committee nature means that for the past 5-10 years it has been lagging behind modern hardware architectures constantly. The API has become so cluttered with different ways to achieve the same task, that you're left to evaluate the 5 different options and try to guess which one actually matches the current hardware (i.e. the fast path), which ones are going to be emulated in hardware (the slow path) and which ones are going to be emulated in software (the 1FPS path). The API redesign so desperately required to solve this issue, will simply never happen, as there will always be some selfish committee member opposed to losing old emulated functionality (whereas Microsoft has had the balls to dictate an up-to-date specification). Conformance with the GL API isn't regulated or enforced by the committee, with different drivers offering widely different capabilities, bugs and performance issues (the previously mentioned software emulation modes can kick in without any way for you to tell programmatically).
This lack of standards-enforcement is so bad that the hardware vendors abuse the situation in unethical ways to gain market advantages and sabotage their competitors, e.g. by supplying OpenGL drivers that allow developers to unintentionally use undocumented vendor-specific features (which will fail on the competition's hardware). This practice only hurts developers, by encouraging them to ship products with incompatibilities and hardware-specific bugs.
In actuality, the ease-of-development and debuggability of D3D means that I can use my D3D renderer to diagnose bugs in my GL renderer (but never vice versa).
Microsoft have not made it any harder on me to use OpenGL, all they've done is turn D3D into a brilliant product (in this instance, they're using honey, not vinegar).
Meanwhile, Apple chose to license OpenGL for their OS, instead of licensing D3D, and they also have put no effort into making their OpenGL implementation into as good of a product as D3D (to their credit, they do however implement most of OpenGL themselves, stopping the hardware vendors from exploiting developers as mentioned above).
Linux is another kettle of fish -- there's no one with money behind it to license either OpenGL or D3D, so you've got to put up with the unauthorised Mesa drivers, hacky open-source hardware drivers, closed-source proprietary drivers with bad support, or the reverse-engineered D3D contained in Wine. None of those are attractive avenues, and none of them provide the level of support that you get from an evil corporation.
Author
On the other hand, OpenGL's design-by-committee nature means that for the past 5-10 years it has been lagging behind modern hardware architectures constantly. The API has become so cluttered with different ways to achieve the same task, that you're left to evaluate the 5 different options and try to guess which one actually matches the current hardware (i.e. the fast path), which ones are going to be emulated in hardware (the slow path) and which ones are going to be emulated in software (the 1FPS path). The API redesign so desperately required to solve this issue, will simply never happen, as there will always be some selfish committee member opposed to losing old emulated functionality (whereas Microsoft has had the balls to dictate an up-to-date specification). Conformance with the GL API isn't regulated or enforced by the committee, with different drivers offering widely different capabilities, bugs and performance issues (the previously mentioned software emulation modes can kick in without any way for you to tell programmatically).
This lack of standards-enforcement is so bad that the hardware vendors abuse the situation in unethical ways to gain market advantages and sabotage their competitors, e.g. by supplying OpenGL drivers that allow developers to unintentionally use undocumented vendor-specific features (which will fail on the competition's hardware). This practice only hurts developers, by encouraging them to ship products with incompatibilities and hardware-specific bugs.
So glad that everyone involved is either corrupt or impoverished. Love how that trend works itself out in society.
These kinds of shinanagins are why I'm a cynic. Under every every cynic is a bitter idealist. Ha.
GL 2.0 / 2.1 is a good choice, it's when shaders became standard (so you've got a lot of flexibility/power), but is compatible with hardware going back about 5/6 years.
As a rough guide to different versions of hardware/APIs:
Shader Model 1 -- D3D8 -- OpenGL1.4? -- Xbox
Shader Model 3 -- D3D9c -- OpenGL 2 -- Xbox360 -- PS3
Shader Model 4 -- D3D10 -- OpenGL 3
Shader Model 5 -- D3D11 -- OpenGL 4
You can use Wikipedia's lists to see which vendors were supporting which API versions at different years:
http://en.wikipedia....rocessing_units
http://en.wikipedia....rocessing_units
http://en.wikipedia.org/wiki/Intel_GMA
excellent information, thank you.
Firstly, Microsoft does support OpenGL. OpenGL is a first class citizen on Windows, even on Windows 7, having the same level of driver integration as D3D has. They even provide a default fall-back implementation of the GL runtime for when drivers are non-GL-compliant so that you can always assume a PC has GL1.2 support.
Sure, they'll support really old versions of OpenGL. But they've stepped off of the comity. Only plans to run them out, no plans to make anything multi-platform unless it helps them. I really would rather it if Microsoft didn't have a monopoly on computer games. It's because they're in competition that half of the free software and support is available. If they can't make a dime off of it, they don't put effort into it. Once they control the market, which they eventually might, we'll stop seeing most of the drive for progress. It's only there to outrun the competition.
Now, they are making quite a bit of progress in the technology, so there's that. But why is what bothers me so very much.
Secondly, Microsoft has achieved far more for the real-time graphics community than the GL committees ever have. Microsoft keeps on top of the ball with developments in graphics hardware, working hand-in-hand with the manufacturers to ensure that the latest D3D API closely matches the hardware architectures. They specify an extremely strict interface for the API, which nVidia/ATI have to stick to exactly, and provide a software reference implementation to exactly test application/driver conformity. As for developers, they give me documentation on both GL and D3D and have developed a free graphics-API debugger that rivals the expensive Xbox/PS3-specific tools used by console developers.
That sounds very promising.
In actuality, the ease-of-development and debuggability of D3D means that I can use my D3D renderer to diagnose bugs in my GL renderer (but never vice versa).
Microsoft have not made it any harder on me to use OpenGL, all they've done is turn D3D into a brilliant product (in this instance, they're using honey, not vinegar).
Meanwhile, Apple chose to license OpenGL for their OS, instead of licensing D3D, and they also have put no effort into making their OpenGL implementation into as good of a product as D3D (to their credit, they do however implement most of OpenGL themselves, stopping the hardware vendors from exploiting developers as mentioned above).Linux is another kettle of fish -- there's no one with money behind it to license either OpenGL or D3D, so you've got to put up with the unauthorised Mesa drivers, hacky open-source hardware drivers, closed-source proprietary drivers with bad support, or the reverse-engineered D3D contained in Wine. None of those are attractive avenues, and none of them provide the level of support that you get from an evil corporation.
Yeah, I'm not really a fan of any of the three of them. They all have their faults, of course. I'd be able to be a fan of all of them, but apparently that's impossible. Guess I have to choose the least of the three evils. Whoever that is.
Other than that, thanks for the input. Might even switch over to DirectX. *shudders*
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
