Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

deathtrap

OpenGL SDL/OpenGL extensions errors

This topic is 5467 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

Looking for some info regarding some errors i get when i try to use glActiveTextureARB ( i think thats the function). when trying to run in an SDL window on windows xp i get an "SDL segmentation fault" . anyone know the cause? could it be because of an older version of the openg32.dll file?

Share this post


Link to post
Share on other sites
Advertisement
A segmentation fault normally indicates an invalid pointer. I''m not completely sure what the glActiveTextureARB function does but I guess you have to pass a pointer to it and that is the pointer that is invalid.

Share this post


Link to post
Share on other sites
it''s used to select a texture when multitexturing a polygon. and the only thing you pass to it is a type GLenum , i.e. GL_TEXTURE0_ARB , GL_TEXTURE1_ARB ...etc

it doesn''t deal with a pointer. unless the data in my own bitmap structure is invalid yet i doubt that since the loading of the bitmap data is unchanged.

Share this post


Link to post
Share on other sites
I bet your glActiveTextureARB is a function pointer, and wglGetProcAddress failed to load it properly. Check the value of it. If that is correct, I bet it fails because you don't have a rendering context when trying to load the function pointer. With the use of a debugger and/or error checking, such a problem is easily found.

EDIT: You said you used SDL, so I assume you're using SDL's wrapper for wglGetProcAddress instead. However, my point is still valid.

[edited by - Brother Bob on July 27, 2003 6:18:11 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Brother Bob
EDIT: You said you used SDL, so I assume you''re using SDL''s wrapper for wglGetProcAddress instead. However, my point is still valid.



damn it, i never thought to think you would need to have a rendering context up and running before calling wglGetProcAddress.
and SDL''s what wrapper for wglGetProcAddress, i''ve never seen it mentioned anywhere.

Share this post


Link to post
Share on other sites
extern DECLSPEC void * SDLCALL SDL_GL_GetProcAddress(const char* proc);

i think he means that one..

"take a look around" - limp bizkit
www.google.com

Share this post


Link to post
Share on other sites
Yeah, that looks like the right one. Never used SDL, but the name of the function, the parameter and return type is more or less identical to wglGetProcAddress.

And of course you need a rendering context before loading function pointers, how else would it know from where to get them?

Share this post


Link to post
Share on other sites
Hi
I have same problem on sdl -see my post on Cone3D section.
No one not replies yet on my post but I think the problem on declaration of pointer to arb function

__cdecl instead of __stdcall
debuger says that 4bit segment fault because some conversion
i have no idea were is it?

When I am using wglgetproc as I did before then i havn''t problems at all.
I think sdl wrapper have some bug or mabe we missing something
in sdlgetprocaddress.


Can''''t be root?Reboot!
mount -r /home/hell

Share this post


Link to post
Share on other sites
I''m not sure really, but I think __cdecl is microsoft specific for their visual c++ compilers. maybe you should get a different SDL-dev binaries?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!