Access Violations and OpenGL

Started by
6 comments, last by TheSalmon 22 years, 7 months ago
I''ve always been having problems with access violations when making OpenGL programs, they seem to occur randomly, sometimes I haven''t even changed anything in the code and I get one. So the other day, I got DetonatorXP from nVidia, hoping that new drivers would fix it, but instead, all my OpenGL programs give violations all the time now. I''m pretty stumped ''cause I can''t do anything OpenGL related anymore, please help. For the record, I''ve got a GeForce256 and I''m programming in Borland C++Builder. --- No game will ever rule more than CBT!
---Mikael Lax
Advertisement
I would say that the odds are it is something wrong with your code. If you pass an invalid pointer, or accidentally lie about its size, or something like that, you cause a crash which just happens to be within the OpenGL code. OpenGL assumes everything you tell it is correct, so if it''s not...

[Resist Windows XP''s Invasive Production Activation Technology!]
Did you know about this page?
http://www.opengl.org/developers/faqs/technical/gettingstarted.htm
section 2.050
It is normal for floating point exceptions to be generated if _control87(MCW_EM, MCW_EM); is not used (it''s defined in float.h)
I have had the exact same problem in the past.
I fixed it by creating display lists in
complile mode rather than compile and execute mode.
It also helps to make sure that you aren''t calling
any OpenGL functions which aren''t allowed between
glBegin and glEnd. For instance, I don''t think you
are allowed to change the active texture inside a
glBegin and glEnd block.

See my project diary where I give some more information about this problem.

Steven Borkman
I''ve been trying to figure this out all day now. I''m already doing the _control87 thing, I don''t have any display lists and I''ve come to the point where I''m not even trying to render anything. I think I''ve narrowed it down to a problem with setting the pixel format, but I don''t know why it won''t work...

Here''s a tiny bit from my windowproc:
  static HDC hdc;//snipcase WM_CREATE:hdc=GetDC(mainhandle);SetPF(hdc);//snip  


and the SetPF function:
  void SetPF(HDC hdc){int pformat;PIXELFORMATDESCRIPTOR pfd={sizeof(PIXELFORMATDESCRIPTOR),1,PFD_DRAW_TO_WINDOW|PFD_SUPPORT_OPENGL|PFD_DOUBLEBUFFER,PFD_TYPE_RGBA,32,0,0,0,0,0,0,0,0,0,0,0,0,0,16,0,0,PFD_MAIN_PLANE,0,0,0,0};pformat=ChoosePixelFormat(hdc,&pfd);SetPixelFormat(hdc,pformat,&pfd);}  


ChoosePixelFormat returns 0, and so SetPixelFormat returns false...

---
No game will ever rule more than CBT!
---Mikael Lax
Through hard work, patience and a debugger, I''ve managed to come up with something completely weird. It seems that ChoosePixelFormat and SetPixelFormat succeeds only when I place a completely irrelevant line of code in a function that never gets called. I''ve no idea what causes this, I mailed both versions to a friend and they both worked fine so the problem is obviously on my end.

I hate to be a nag, but I could really use some help here...

---
No game will ever rule more than CBT!
---Mikael Lax
Ha, it''s amazing what a little searching the internet can do for you. I just found the solution so in case anybody has the same problem, here it is:

quote:
Internally, ChoosePixelFormat (and SetPixelFormat and all those functions) make calls to OPENGL32.DLL. If your program does not make any gl* calls, then your compiler''s smart-linker will probably not link opengl32.lib, so when you run your program then opengl32.dll will not be loaded, and so ChoosePixelFormat will fail.


I''m a much better person now

---
No game will ever rule more than CBT!
---Mikael Lax
Another thought, put a static infront of you PIXELFORMATDESCRIPTOR. EG:

static PIXELFORMATDESCRIPTOR

Direwolf

"Shhweeet, look atem blow" - Anonymous dwarf

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

This topic is closed to new replies.

Advertisement