Skip to main content
GameDev.net gamedev.net
🔒 Locked

Is gluPerspective deprecated?

Started by proanim Dec 2, 2012 at 12:08 AM 10 replies 7.1k views
Original Post
proanim
proanim
I am currently using gluPerspective to setup my perspective projection. Since I want to use OpenGL 4.0 I have substitute code to setup perspective. Should I avoid using gluPerspective? What can happen in the long run if I use deprecated functions?
Hodgman
Hodgman
glu* can't be deprecated, because glu* functions aren't part of OpenGL to begin with, they're part of a GL utility library that has many alternatives.

[edit]n.b. this doesn't mean you should be using it -- it's just a wrapper around other GL functions, which may themselves be deprecated[/edit]
proanim
proanim
ok thanks
21st Century Moose
21st Century Moose
It's true that gluPerspective is just a software helper function, but -- it will most likely call either glFrustum or glLoad/MultMatrix internally (haven't checked and would be implementation-dependent anyway - although glLoadMatrix would violate spec) and those calls ARE deprecated.
Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls. 
proanim
proanim
i looked around the web on this there is some conflicting information stating 'opengl 3+ doesn't support gluPerspective' and there are the once that state like Hodgman said 'glu is not part of opengl so it is still valid'. I checked opengl spec file i found on opengl.org it seems that it is not deprecated after all.
Aks9
Aks9
Lets solve it in the simplest way. Create a core GL context and call the function you want. If it works, it is not deprecated. glu is not the part of the core functionality, so it cannot be deprecated directly, but it uses deprecated (legacy) commands, so it cannot be executed in the core profile. In short, it is not deprecated since it has never been the part of the core, but it cannot execute in core context now.
Aks9
Aks9
Sorry for this post. Combination of Android, Opera Mobile and scripts on this page generated two identical posts. Since there is no way to delete a post (reqest for the administrator/web master), I had to modify it.
proanim
proanim
i just tried this with GLFW and gluPerspective works in core profile
Brother Bob
Brother Bob
And what do you expect to happen when you call it, even if there is no error reported? The function operates on the current matrix stack, but there is no such thing in a core context.
21st Century Moose
21st Century Moose

And what do you expect to happen when you call it, even if there is no error reported? The function operates on the current matrix stack, but there is no such thing in a core context.


Yup, this basically.

If gluPerspective works in your tests, all that means is that your GL implementation is not fully conformant in that it's allowing you to do things in a core profile that you should not be allowed to do. So the fact that it works is something you should most definitely not be relying on, because a future driver revision, or other hardware, could quite easily break it.

If you want to construct a perspective matrix there is a much easier way that will work in all cases. Just grab a sample implementation of gluPerspective from something like Mesa and re-implement it in a conformant manner. Or better yet, use a tried and trusted matrix library that will already contain a routine for constructing a perspective matrix.
Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls. 
L. Spiro
L. Spiro
In OpenGL 4.0, the entire fixed-function pipeline (used by glu*) is deprecated. This is exactly why I never use helper libraries—the core moves on but the helper libraries don’t.
If you are using shaders as you should be (in OpenGL 4.0, not using shaders is deprecated) then there is no way glu* can help you. The matrices you want to create will be used by you manually in your shaders.

This is actually a good thing honestly because OpenGL was originally not created for games and had some quirks in it that made it more of a nuisance than anything else (for example, lights were originally multiplied by the current model-view matrix, so you had to constantly update their positions every frame and in a very inefficient manner).
With shaders nothing is done for you. You have to write your own shaders and thus, by definition, you have to handle the primitive pipeline manually.

glu* and friends no longer have meaning because they set a bunch of states that you aren’t (shouldn’t be) using.
In OpenGL 4.0, you need to have your own matrix math library, calculate your own model, view, and projection matrices, and send them to your shaders manually.


L. Spiro
I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid
TheChubu
TheChubu
... like a real programmer

[spoiler]Its a joke! Don't cast my post into oblivion [/spoiler]
"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"   My journals: dustArtemis ECS framework and 

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.