“The Matrix Stack functionality is deprecated and I want to draw multiple objects with different transformations.”
Before I go on wild goose chase fixing my “erase bitmap” problem by manipulating modelview matrices- if the above is true what is the replacement ?
The matrix stack is part of the fixed-function pipeline, which is deprecated in its entirety. The alternative is to use a shader program containing at least vertex and fragment shaders.
Note that bitmaps are also deprecated. The alternative is to render textured triangles aligned to screen space. Either that, or glBlitFramebuffer, with the window-space coordinates computed by the client.
If you look at the OpenGL 4 reference pages, any function not listed there is deprecated.
I checked my version and it is 3.0.
As far as my current deletion issue I am happy with very old approach - erase everything and rebuild it with new “bitmap”.
At this point I have to conclude that I picked wrong tool for my application.
Being opinionated / inquisitive I cannot help to wonder " what they, the developers, were thinking about REMOVING stuff".
To me the answer is obvious - it is much easier to start from scratch then to keep adding to WORKING tool. That requires intimate knowledge of current code , which is “not cool” to research.
See
A.Cooper “The inmates are running the asylum”.
Basically I still have choices - keep rebuilding after minor changes or learn all about fancy toys AKA “games graphics” which is overkill for my app - or just ditch OpenGL…
It would be most accurate to say that the entirety of the fixed function pipeline (including, but not limited to, glVertex and equivalent functions; all matrix functionality; glTexEnv and all associated functionality) has been removed from the core profile of OpenGL versions 3.2 and above.
You can still access them in OpenGL 3.1 and below, or if your implementation offers you access to the compatibility profile of OpenGL 3.2+.
The replacement is to do it all yourself. It’s just matrix math, after all. You can compute those matrices just as well as the OpenGL implementation could. And you can pass those matrices to vertex shaders, where they can transform vertex attributes in whatever way you like.
They removed stuff because:
-
OpenGL is supposed to be a high-performance, low-level rendering API. Once upon a time, the fixed-function stuff did represent a low-level interface to hardware from that time. But since the GeForce 256 ushered in the era of on-GPU transformations, fixed-function OpenGL ceased to closely mirror what the GPU was actually doing. Shaders made the fixed-function pipeline even less like what the GPU was doing. Fixed-function OpenGL was really far from “low-level”.
Also, fixed-function OpenGL ceased to be fast anymore; there were (much) faster ways to render.
-
It takes time and effort to write code that emulates the fixed-function pipeline on shader-based graphics chips. Time and effort that driver developers could spend doing far more useful things.
-
As new hardware-based features become available, some consideration would have to be taken to decide how to expose it to fixed-function GL. How do you make integer textures work with the texture environment/crossbar mechanism, for example? Those questions would grow ever more complex with time.
In addition, there are some hardware features that are based on stuff that is antithetical to fixed functionality. Tessellation is based on you writing your own tessellation algorithm in the shader. That can’t work with fixed-function GL, not without creating fixed-function tessellators or something. How would you even think about making image load/store something that fixed-function GL can work with?
By ditching the garbage fixed-function stuff, all of those problems go away (well, most of them). And since most of the industry moved on from the fixed-function pipeline decades ago, better for the API to move on from that.
Yes, the inmates that made OpenGL ES 2.0 a massive success. They’re totally crazy 
It should also be noted that we’re discussing a decision that was made over a decade ago. It’s unfortunate that there are a lot of garbage, outdated learning materials on OpenGL, but you’re criticizing a decision that was made a long time ago.
Nobody should feel like they’re being forced to use a tool. You use the tool that is most appropriate to your needs. If OpenGL is too low-level of a graphics API for you, I can understand that. There are plenty of other graphics systems that live at higher levels than GL which you could use for your needs.
That doesn’t make OpenGL bad; it simply means that your needs and what OpenGL provides may be mismatched. OpenGL shouldn’t try to be all things to all people.
Appreciate all the comments.
So it took less then a month for me to realize why people were telling me OpenGL “is not” it is GL , GLUT etc. etc.
As I have said before , the main reason for choosing OpenGL was the "main event loop ", and I expected that my "red book " of version 1,1 would help me do the simple graph. So far the “main event loop” is working for me just peachy.
The “good news” is that version 3.0 WILL do fine after I get all my code organized, hacking away any "deprecated features " as I go.
Use the matrix stack then. If it works well in the graphics drivers you’re targeting, who cares if it’s deprecated? The question is: does it enable you to achieve your goals? If so, use it!
If you’re going to deploy your app on a wide variety of graphics drivers and GPUs, it’s of course worth checking whether those drivers have solid support for the compatibility profile. NVidia drivers do. For some others, …you want to double-check.
Also @JulyJim, it’s worth noting that you can mix-and-match older OpenGL techniques (like the built-in matrix math APIs) with “newer” ** techniques (like shaders) using the compatibility profile. Just continue to use the the built-in matrix APIs as usual on the C++ side, and then in your shaders, use the GLSL matrix built-ins to pull in the then-current matrix values for the GL_MODELVIEW, GL_PROJECTION, and GL_TEXTURE matrix stacks, and variants built from them (e.g. gl_ModelViewMatrix, glProjectionMatrix, gl_NormalMatrix, etc.). Or just continue to use the built-in fixed function shaders if they allow you to accomplish your goals with the minimal fuss.
Unless you’re a purest or a serious graphics guru, there’s really no point in limiting yourself to the core profile, particularly when you’re learning. Most folks are just trying to “get something else done”, and re-inventing the wheel in a modern graphics language may not have much pay off for them. You have to make that call based on your knowledge level now and where you want to end up.
** I say “newer” here loosely, because GLSL shaders were “new” over 15 years ago, with assembly GPU shaders making their debut a full 20 years ago.
Thank you for encouraging words.
I finally got the base graph to display, I can move the mouse around to select the “zoom” circle. Now I need to assemble the parts of the graph using stencils.
That is where I will need the matrix stack - it woudl be a nightmare doing it all on “single plane”.
And not to worry - this is not a commercial project , just a form of self-punishment - a hobby to keep me off the streets.
Unfortunately during these times - literary - off the streets!
Keep safe.