Advertisement Jump to content
Sign in to follow this  
Alian Vesuf

C++ OpenGL - Deprecated or not !

This topic is 1783 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

First of all i dont really understand all these updates and modern OpenGL. I was studying OpenGL in college and we used old deprecated stuff. After some time i come back to it and i see lot of changes. I've seen glfw glew but not used them and im really confused what is what and what to start learning.  Also, since i dont plan on using fancy shaders on my programs can i continue with plain old OpenGL ?

Share this post


Link to post
Share on other sites
Advertisement

AlS4tSp.jpg

 

More seriously, if you are interested in 3D, learn "modern" OpenGL. There is no point in fixed function pipeline if you want to delve further into computer graphics. That arcsynthesis online book that ryutenchi linked is a nice start.

 

Now if you just want to draw things to the screen, you might be better off with a graphics library that can do that for you so you don't have to mess with OpenGL client states and the stupid stack-like interface (which is cumbersome and grants you a grand amount of 0 useful knowledge to you).

Share this post


Link to post
Share on other sites

I've seen glfw glew but not used them and im really confused what is what and what to start learning.

 

Thous are not OpenGL, per-se, they are there just to help you with some of the mundane tasks related to opengl. Most importantly - a crap-ton of boilerplate code to expose all the available/requested functions/enums for you.
 

Just read a bit about them and pick one you like - knowing that it is fairly easy to change your mind later on.

 

Also, there is a bit of truth in saying that the OGL3.3+ way (without backwards compatibility) is easier to work with than the old ways even when you do not need any of the new features - although the entry fee, if i may say so, is a bit higher. The mentioned http://www.arcsynthesis.org/gltut/ is great help there (at least read the "About this Book" part to know what you get yourself into).

Share this post


Link to post
Share on other sites

Although at least one very major person from one very major manufacturer disagrees with my opinon, I suggest not using deprecated functionality. The reason is that as a beginner, it is not immediately obvious for you which deprecated functionality is well-supported in hardware and what isn't. On the other hand, once you have climbed over the -- admittedly high --  entry barrier (like, having to type 100 lines of code to produce the first triangle), core functionality isn't any harder than using deprecated features.

 

Also despite vendors currently promising not to do this any time soon, one day the deprecated functionality will be removed. Nor can you rely that while maybe one or two vendors will keep supporting deprecated functionality, in fact all of them will.

 

Indeed, I would wish for manufacturers to drop deprecated functionality in favor of making core functionality better and faster, and making drivers smaller, less complicated, and bug-free.

 

 

For the record, here is what Mark Kilgard has to say about it:

 

OpenGL 3.1 introduced notion of “core” profile

 

Idea was remove stuff from core to make OpenGL “good-er”

  • Well-intentioned perhaps but...
  • Throws API backward
  • compatibility out the window

Lots of useful functionality got removed that is in fast hardware

  • Examples: Polygon mode, line width

Lots of easy-to-use, effective API got labeled deprecated

  • Immediate mode
  • Display lists

Best advice for real developers

  • Simply use the “compatibility” profile
  • Easiest course of action

Requesting the core profile requires special context creation gymnastics

  • Avoids the frustration of “they decided to remove what??”
  • Allows you to use existing OpenGL libraries and code easily

•No, your program won’t go faster for using the “core” profile

  • It may go slower because of extra “is this allowed to work?” checks

 

Nothing changes with OpenGL 4.3 NVIDIA still committed to compatibility without compromise

 

Source: GTC 2010 session, OpenGL Version 4.3 is here

Share this post


Link to post
Share on other sites

Imo todays opengl is 'overstuffed' for small 'indie' games, 

It is good for big comercial games (like for example "nail'd"

game i play recent whole week) with heavy heavy tons

of geometry and coloring - but much heavy for small fckn*  indie

games

Share this post


Link to post
Share on other sites

Imo todays opengl is 'overstuffed' for small 'indie' games, 

It is good for big comercial games (like for example "nail'd"

game i play recent whole week) with heavy heavy tons

of geometry and coloring - but much heavy for small fckn*  indie

games

I don't know... while OpenGL 3.x or 4.x is a real pain to get working at all, it is actually a lot easier than the old versions... once you're over that initial hurdle.

 

There are no obscure limits, and the limits that do exist are so big that you will likely never run into them (unless you write something like FarCry 3). There is, at least in theory, no struggling about what special feature that you need a particular graphics card supports and doesn't support, and which extension you need to load, and what fallback strategy if that doesn't work. Because, behold, everything that you reasonably need just works.

 

Also, even indie games nowadays have much higher geometry demands (think Minecraft) than immediate mode can reasonably deliver. Sure, it won't make much of a difference if you write a side scroller like Flappy Birds, which is basically a dozen textured quads. But it makes a huge difference for everything else.

Even for quite "simple" 2D games which "only" draw a few hundred tiles or textured quads (think "diamonds" or "frozen bubble" or a graphical roguelike or dwarf-fortress-alike), instancing and array textures may be big win both for performance and ease of implementation.

Edited by samoth

Share this post


Link to post
Share on other sites
My recommendation continues to be to learn Direct3D 11 first. The debugging tools for Direct3D are years ahead of those for OpenGL. The drivers are more stable and less buggy. The API more closely matches how actual hardware works. There's no deprecated features as each version of the API simply removes old stuff. All of this amounts to Direct3D 11 being a significantly better _learning_ platform, independent of your opinions of Microsoft/Windows and alternative OSes or technologies. The Direct3D API is cleaner and has far less odd historic baggage to trip you up.

The knowledge and understanding of graphics development you acquire with Direct3D ports fairly well over to OpenGL.

Starting with OpenGL has many problems. First there's all that deprecated API baggage, and it's all too easy to end up using some old API for something without realizing it (or realizing _why_ it's deprecated, since it still works and the problems are not immediately obvious). The documentation on OpenGL is almost universally out-dated and even newer documentation is often written by people falling into the same deprecated API trap. The drivers tend to be buggier and you (and all your users) have to be updated to the very latest version to avoid major bugs in new API features. The API does not directly or obviously map to hardware and so you don't tend to learn everything you should know as a graphics programmer (you need to know way more than just what function in the API does what). Drivers tend not to support the latest version of GL very quickly; AMD still doesn't support 4.4 and Intel is still stuck on 4.0 I believe, while both support Direct3D 11. There are bits of GL that D3D doesn't support (that tend not to be all that important), but there are major chunks of Direct3D that OpenGL takes years to catch up to and then even longer for the driver vendors to support (as in GL 4.4). The debugging tools for OpenGL are lacking in features compared to their D3D equivalents, often lack support for the latest versions of GL, and tend to be buggy themselves.

Start with Direct3D 11. Learn how to graphics. _Then_ worry about portability and the maze of OpenGL APIs/versions.

Share this post


Link to post
Share on other sites

Also, keep in mind the majority of computers out there do not support the old OpenGL with its fixed pipeline.  Most of them support only OpenGL|ES.  Learning the deprecated parts of OpenGL today is like learning COBOL in the 1980s (substitute creaky old legacy desktop computers with mainframes, too).  Somebody has to support the legacy stuff that's going to be around for a while yet, but if you want a job writing the disposable code that's the way into the future, stick to the subset of GL that's in GL|ES 2 and you won't go wrong.

 

There are still jobs for mainframe COBOL programmers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!