Trying to use openGL extensions and failing.

Hi guys, this is my first post in these forums so i hope this is the right place.
I’m trying to include some of the functions from glext.h and I’m having a little difficulty.

What could the reason be that this isn’t working?

PFNGLTEXIMAGE3DPROC glTexImage3D;
glTexImage3D = (PFNGLTEXIMAGE3DPROC)wglGetProcAddress(“glTexImage3D”);

The error message i’m getting is the standard:

expected constructor, destructor, or type conversion before ‘=’ token|

so might be a c++ problem

Thanks, Chris

Please use an extension loading library.

What you have written is a completely legal way to grab the pointer to a glTexImage3D function. I’ve copy-pasted it in my InitAPI function and it works. Are there any other errors reported by the environment? By the way, what environment are you using?

I disagree that using some extension handling library is better way than doing it on your own. It is easier, but not better if you want to have control over what is happening in your code.

It is easier, but not better if you want to have control over what is happening in your code.

And why do you need that control? What are you going to do with it? And does that control matter?

The problem with that kind of thinking is that it focuses on something that really doesn’t matter. Your customers don’t care if your executable has 200K more data in it. Your users won’t care about the 0.020 seconds of increased startup time. By spending time on inconsequential things, you’re wasting time that could be used on things that actually matter.

If you have an honest reason for needing that control, then by all means take it. But if you simply like playing around there, if that 200K of executable space bothers you personally, then what you are talking about is a personal quirk, not a practical rule that one should code by.

Well, for example, I’m just developing a tiny profiler-library. A manual extension handling enables:

  • more compact library,
  • removes need to worry what kind of extension handling library is used in the main project and whether it is initialized or not,
  • removes need to worry if used extension library is well implemented (e.g. well known problem with GLEW core profile) and is up-to-date,
  • a naming convention can be freely imposed,
  • using functionality that is not even documented in the OpenGL Registry, etc.

It can be tedious to add new function pointers, but it is not so frequent activity to make life unpleasant.

  • more compact library,

Why does that matter? Is that affecting the ability of your “profiler-library” to do its job?

  • removes need to worry what kind of extension handling library is used in the main project and whether it is initialized or not,

… is that an actual worry you have? That in your one main() function, you will forget to write glewInit once, or whether you included the library at all? That’s a one-time mistake you make. You make it, realize you didn’t initialize it, and fix it. Fixing that mistake takes far, far less time than writing your own loading code.

  • removes need to worry if used extension library is well implemented (e.g. well known problem with GLEW core profile) and is up-to-date,

GL3W is designed for core and auto-updates itself; it is always up-to-date. So this is more of a question of selecting the right extension loader for your needs than anything being actually wrong with extension loaders in general.

Also, most loading libraries were updated the very day GL 4.2 came out. So it’s not like they’re particularly behind the times or something.

  • a naming convention can be freely imposed,

Thus making your code harder to read for every OpenGL user. OpenGL already has a naming convention.

Of course, using a library means that you:

  • have reasonable assurance that it works. Your manual loader is written, maintained, and used only by you. If you encounter a bug, you have to track it down. Whereas if someone else encounters a bug in a loading library, then the maintainer tracks it down.

  • often get convenience functions. Being able to check which extensions are available, etc.

  • save massive quantities of time.

  • being able to quickly test new extensions. If I wanted to use NV_path_rendering right now, I could do so (given an appropriate card and drivers, of course) with an extension loader. Your method would require hours of work copying function declarations, writing loading code, etc. Just because you’re not using an extension right now does not mean you might not want to use one in the future.

I understand that you personally would rather do it yourself. And that’s fine, for you. Time obviously isn’t as important to you as doing thing exactly the way you want. But you’re giving advise to other people. And their priorities are going to be different from yours. Especially for beginners.

Hi guys thanks for all this information. I’m working in codeblocks with mingw.
It seemed like a simple operation so i thought I could do it but apparently not. I will look into using extension library loader I guess and maybe come back if that doesn’t work.

I did think I should learn how to do it manually but as you say it’s time consuming Alfonse, I’ll glance over it for now.

Thanks again.

This thread isn’t about you. it is about the OP. The best thing to do is to start by suggesting the common thing to do. Then he can respond by saying “I am already aware of that and I can’t use it because of xyz reason”.

Excuse me, Mr.Moderator! I really don’t understand what is wrong in giving an example. Do you have also to moderate how we communicate or to impose dialog forms?

Did I offend someone? Did I make a wrong advice? Did I write anything that is not linked to the OPs post? I really need to know for what I am accused.