Problems with SDL's GL support?

I’m getting a weird error, and, oddly, even without the SDL Parachute
enabled, VC7’s debugger says the error occurs in my own SDL_main(), but it
happens in a spot (I looked at the assembly – it’s about 8 instructions
past the call to the actual culprit) where the specific error couldn’t
happen (the static JMP at the end of a loop). Long story short, with alot
of printf()ing I’ve narrowed it down straight to SDL_GL_SwapBuffers(). The
error goes something like this: "Unhandled exception at 0x10029011 in
QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all the right
stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and SDL_INIT_NOPARACHUTE into
SDL_Init. Everything seems to be in order – especially since it’s all
exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If so,
what’s causing it and/or how is it fixed? If not, can anyone help me build
a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon—
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003

If you have a voodoo card its a known problem that the driver is buggy and
there is no solution since the company is gone ):

I had a similar problem in something i was making when i had a voodoo3.

If you have another card, what kinda card do you have?> ----- Original Message -----

From: jsilicon@earthlink.net (John Silicon)
To:
Sent: Sunday, October 26, 2003 12:25 AM
Subject: [SDL] Problems with SDL’s GL support?

I’m getting a weird error, and, oddly, even without the SDL Parachute
enabled, VC7’s debugger says the error occurs in my own SDL_main(), but it
happens in a spot (I looked at the assembly – it’s about 8 instructions
past the call to the actual culprit) where the specific error couldn’t
happen (the static JMP at the end of a loop). Long story short, with alot
of printf()ing I’ve narrowed it down straight to SDL_GL_SwapBuffers().
The
error goes something like this: "Unhandled exception at 0x10029011 in
QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all the
right
stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and SDL_INIT_NOPARACHUTE
into
SDL_Init. Everything seems to be in order – especially since it’s all
exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If so,
what’s causing it and/or how is it fixed? If not, can anyone help me
build
a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Nvidia Geforce2 MX> ----- Original Message -----

From: atrix2@cox.net (atrix2)
To:
Sent: Sunday, October 26, 2003 1:18 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

If you have a voodoo card its a known problem that the driver is buggy and
there is no solution since the company is gone ):

I had a similar problem in something i was making when i had a voodoo3.

If you have another card, what kinda card do you have?

----- Original Message -----
From: “John Silicon” <@John_Silicon>
To:
Sent: Sunday, October 26, 2003 12:25 AM
Subject: [SDL] Problems with SDL’s GL support?

I’m getting a weird error, and, oddly, even without the SDL Parachute
enabled, VC7’s debugger says the error occurs in my own SDL_main(), but
it

happens in a spot (I looked at the assembly – it’s about 8 instructions
past the call to the actual culprit) where the specific error couldn’t
happen (the static JMP at the end of a loop). Long story short, with
alot

of printf()ing I’ve narrowed it down straight to SDL_GL_SwapBuffers().
The
error goes something like this: "Unhandled exception at 0x10029011 in
QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all the
right
stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and SDL_INIT_NOPARACHUTE
into
SDL_Init. Everything seems to be in order – especially since it’s all
exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If so,
what’s causing it and/or how is it fixed? If not, can anyone help me
build
a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003

Hi!

That is almost EXACTLY the same error I am experiencing in in the
testrendertarget.exe supplied with the CVS ver 1.3.*! I traacked it down
to the function wglGetProcAddress that gets function pointers out of the
DLL. It is returning the WRONG addresses. So far, the people who have
replied to the thread I started on pbuffer support were GAGA over the
possible existence of pbuffer support and didn’t try to help with the
actual problem I am having and that’s with the function call to

wglGetProcAddress

returning duplicate addresses for different functions. I run an nVidia
GeForce 3 in my machine, but I don’t think it has anything to do with
the drivers. I think there’s something else going on.

For the record, here is the exact error I get:

Unhandled exception at 0x69612400 in testrendertarget.exe: 0xC0000005:
Access violation reading location 0x0000008c.

If anyone has any suggestions on what might be going wrong, please,
please please help :slight_smile:

Jay

jsilicon at earthlink.net 10/26/03 7:40 AM >>>
Nvidia Geforce2 MX> ----- Original Message -----
From: atrix2@cox.net (atrix2)
To:
Sent: Sunday, October 26, 2003 1:18 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

If you have a voodoo card its a known problem that the driver is buggy
and
there is no solution since the company is gone ):

I had a similar problem in something i was making when i had a
voodoo3.

If you have another card, what kinda card do you have?

----- Original Message -----
From: “John Silicon”
To:
Sent: Sunday, October 26, 2003 12:25 AM
Subject: [SDL] Problems with SDL’s GL support?

I’m getting a weird error, and, oddly, even without the SDL
Parachute

enabled, VC7’s debugger says the error occurs in my own SDL_main(),
but
it

happens in a spot (I looked at the assembly – it’s about 8
instructions

past the call to the actual culprit) where the specific error
couldn’t

happen (the static JMP at the end of a loop). Long story short,
with
alot

of printf()ing I’ve narrowed it down straight to
SDL_GL_SwapBuffers().
The

error goes something like this: "Unhandled exception at 0x10029011
in

QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all
the
right

stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and
SDL_INIT_NOPARACHUTE
into

SDL_Init. Everything seems to be in order – especially since it’s
all

exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If
so,

what’s causing it and/or how is it fixed? If not, can anyone help
me
build

a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Glad to know somebody else is experienceing the same problems – it means
chance are somebody else has experienced them in the past and knows how to
fix it. Any chance you too have been able to compile/run other SDL/GL apps
before this, Thomas? I’ll keep digging (and comparing the changes I’ve made
recently to old versions of my basecode, to see if I can find anything that
might be causing the new error)

  • John Silicon> ----- Original Message -----

From: cralltj@auburn.edu (Thomas Cralley)
To:
Sent: Sunday, October 26, 2003 8:27 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

Hi!

That is almost EXACTLY the same error I am experiencing in in the
testrendertarget.exe supplied with the CVS ver 1.3.*! I traacked it down
to the function wglGetProcAddress that gets function pointers out of the
DLL. It is returning the WRONG addresses. So far, the people who have
replied to the thread I started on pbuffer support were GAGA over the
possible existence of pbuffer support and didn’t try to help with the
actual problem I am having and that’s with the function call to

wglGetProcAddress

returning duplicate addresses for different functions. I run an nVidia
GeForce 3 in my machine, but I don’t think it has anything to do with
the drivers. I think there’s something else going on.

For the record, here is the exact error I get:

Unhandled exception at 0x69612400 in testrendertarget.exe: 0xC0000005:
Access violation reading location 0x0000008c.

If anyone has any suggestions on what might be going wrong, please,
please please help :slight_smile:

Jay

@John_Silicon 10/26/03 7:40 AM >>>
Nvidia Geforce2 MX

----- Original Message -----
From: “Alan Wolfe”
To:
Sent: Sunday, October 26, 2003 1:18 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

If you have a voodoo card its a known problem that the driver is buggy
and
there is no solution since the company is gone ):

I had a similar problem in something i was making when i had a
voodoo3.

If you have another card, what kinda card do you have?

----- Original Message -----
From: “John Silicon” <@John_Silicon>
To:
Sent: Sunday, October 26, 2003 12:25 AM
Subject: [SDL] Problems with SDL’s GL support?

I’m getting a weird error, and, oddly, even without the SDL
Parachute

enabled, VC7’s debugger says the error occurs in my own SDL_main(),
but
it

happens in a spot (I looked at the assembly – it’s about 8
instructions

past the call to the actual culprit) where the specific error
couldn’t

happen (the static JMP at the end of a loop). Long story short,
with
alot

of printf()ing I’ve narrowed it down straight to
SDL_GL_SwapBuffers().
The

error goes something like this: "Unhandled exception at 0x10029011
in

QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all
the
right

stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and
SDL_INIT_NOPARACHUTE
into

SDL_Init. Everything seems to be in order – especially since it’s
all

exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If
so,

what’s causing it and/or how is it fixed? If not, can anyone help
me
build

a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003

Maybe I sent that last message off too soon. I just realized that right
before the problem started, I downloaded some stuff for another project –
namely, a “3rd party required libraries” pack. I checked, and, sure enough,
it included both headers and libraries for OpenGL and SDL – nither of which
were even close to up-to-date with what I have on my drive. I went and
changed my search path settings so both my OpenGL and SDL stuff was higher
priority, and everything went well. Might want to check on this, Thomas.> ----- Original Message -----

From: cralltj@auburn.edu (Thomas Cralley)
To:
Sent: Sunday, October 26, 2003 8:27 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

Hi!

That is almost EXACTLY the same error I am experiencing in in the
testrendertarget.exe supplied with the CVS ver 1.3.*! I traacked it down
to the function wglGetProcAddress that gets function pointers out of the
DLL. It is returning the WRONG addresses. So far, the people who have
replied to the thread I started on pbuffer support were GAGA over the
possible existence of pbuffer support and didn’t try to help with the
actual problem I am having and that’s with the function call to

wglGetProcAddress

returning duplicate addresses for different functions. I run an nVidia
GeForce 3 in my machine, but I don’t think it has anything to do with
the drivers. I think there’s something else going on.

For the record, here is the exact error I get:

Unhandled exception at 0x69612400 in testrendertarget.exe: 0xC0000005:
Access violation reading location 0x0000008c.

If anyone has any suggestions on what might be going wrong, please,
please please help :slight_smile:

Jay

@John_Silicon 10/26/03 7:40 AM >>>
Nvidia Geforce2 MX

----- Original Message -----
From: “Alan Wolfe”
To:
Sent: Sunday, October 26, 2003 1:18 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

If you have a voodoo card its a known problem that the driver is buggy
and
there is no solution since the company is gone ):

I had a similar problem in something i was making when i had a
voodoo3.

If you have another card, what kinda card do you have?

----- Original Message -----
From: “John Silicon” <@John_Silicon>
To:
Sent: Sunday, October 26, 2003 12:25 AM
Subject: [SDL] Problems with SDL’s GL support?

I’m getting a weird error, and, oddly, even without the SDL
Parachute

enabled, VC7’s debugger says the error occurs in my own SDL_main(),
but
it

happens in a spot (I looked at the assembly – it’s about 8
instructions

past the call to the actual culprit) where the specific error
couldn’t

happen (the static JMP at the end of a loop). Long story short,
with
alot

of printf()ing I’ve narrowed it down straight to
SDL_GL_SwapBuffers().
The

error goes something like this: "Unhandled exception at 0x10029011
in

QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all
the
right

stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and
SDL_INIT_NOPARACHUTE
into

SDL_Init. Everything seems to be in order – especially since it’s
all

exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If
so,

what’s causing it and/or how is it fixed? If not, can anyone help
me
build

a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003

Thomas Cralley wrote:

So far, the people who have
replied to the thread I started on pbuffer support were GAGA over the
possible existence of pbuffer support

Thanks :stuck_out_tongue:

… and didn’t try to help with the actual problem I am having and
that’s with the function call to

wglGetProcAddress

returning duplicate addresses for different functions.

Why are you loading OpenGL32.dll using loadlibrary??

Anyway, no problem with gl/sdl and extensions here. I don’t use the
"Init_WGL_extensions" you mention, but do the stuff myself using
SDL_GL_GetProcAddress() something like this:

#define INIT_ENTRY_POINT( funcname , type )
funcname = (type) SDL_GL_GetProcAddress(#funcname);
if(!funcname) cerr << “#funcname() not initialized” << endl;

INIT_ENTRY_POINT( wglCreatePbufferARB, PFNWGLCREATEPBUFFERARBPROC );

Regards,
\Mikkel Gjoel

Nope. all libraries I am linking against are current and built off the
SDL1.3 CVS. I actually add these libraries to the project manually,
instead of letting VC7 search for them. I also added the OpenGL32 and
Glu32 libraries manually as well. I am still at a loss. To get the
program to run, all I have to do is run the debugger until I get to the
place where sdl_wingl.c sets up the data structure with the ARB function
pointers and then insert the correct addresses for each of the ARB
functions, and it runs fine.

Jay

jsilicon at earthlink.net 10/26/03 10:16 AM >>>
Maybe I sent that last message off too soon. I just realized that right
before the problem started, I downloaded some stuff for another project–
namely, a “3rd party required libraries” pack. I checked, and, sure
enough,
it included both headers and libraries for OpenGL and SDL – nither of
which
were even close to up-to-date with what I have on my drive. I went and
changed my search path settings so both my OpenGL and SDL stuff was
higher
priority, and everything went well. Might want to check on this,
Thomas.

----- Original Message -----
From: @Thomas_Cralley (Thomas Cralley)
To:
Sent: Sunday, October 26, 2003 8:27 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

Hi!

That is almost EXACTLY the same error I am experiencing in in the
testrendertarget.exe supplied with the CVS ver 1.3.*! I traacked it
down
to the function wglGetProcAddress that gets function pointers out of
the
DLL. It is returning the WRONG addresses. So far, the people who have
replied to the thread I started on pbuffer support were GAGA over the
possible existence of pbuffer support and didn’t try to help with the
actual problem I am having and that’s with the function call to

wglGetProcAddress

returning duplicate addresses for different functions. I run an nVidia
GeForce 3 in my machine, but I don’t think it has anything to do with
the drivers. I think there’s something else going on.

For the record, here is the exact error I get:

Unhandled exception at 0x69612400 in testrendertarget.exe: 0xC0000005:
Access violation reading location 0x0000008c.

If anyone has any suggestions on what might be going wrong, please,
please please help :slight_smile:

Jay

jsilicon at earthlink.net 10/26/03 7:40 AM >>>
Nvidia Geforce2 MX

----- Original Message -----
From: “Alan Wolfe”
To:
Sent: Sunday, October 26, 2003 1:18 AM
Subject: Re: [SDL] Problems with SDL’s GL support?

If you have a voodoo card its a known problem that the driver is
buggy
and

there is no solution since the company is gone ):

I had a similar problem in something i was making when i had a
voodoo3.

If you have another card, what kinda card do you have?

----- Original Message -----
From: “John Silicon”
To:
Sent: Sunday, October 26, 2003 12:25 AM
Subject: [SDL] Problems with SDL’s GL support?

I’m getting a weird error, and, oddly, even without the SDL
Parachute

enabled, VC7’s debugger says the error occurs in my own
SDL_main(),
but
it

happens in a spot (I looked at the assembly – it’s about 8
instructions

past the call to the actual culprit) where the specific error
couldn’t

happen (the static JMP at the end of a loop). Long story short,
with
alot

of printf()ing I’ve narrowed it down straight to
SDL_GL_SwapBuffers().
The

error goes something like this: "Unhandled exception at
0x10029011
in

QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all
the
right

stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT
into

SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and
SDL_INIT_NOPARACHUTE
into

SDL_Init. Everything seems to be in order – especially since
it’s
all

exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before?
If
so,

what’s causing it and/or how is it fixed? If not, can anyone help
me
build

a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

That was in no way meant as an insult :wink: I understand everyone has their
own interests. I am just frustrated trying to get this demo to run. The
current CVS code sets up the ARB extensions using
this->gl_data->wglGetProcAddress, which is set in WIN_GL_LoadLibrary
using a call to a winapi function GetProcAddress(). All I really know
is, that the addresses I get this way are wrong. I just can’t seem to
figure out why. When I load the OpenGL32 library myself and use
wglGetProcAddress myself in a blank program, I get the correct
addresses.

Thanks,
Jay

s971661 at student.dtu.dk 10/26/03 10:22 AM >>>
Thomas Cralley wrote:
So far, the people who have
replied to the thread I started on pbuffer support were GAGA over the
possible existence of pbuffer support

Thanks :stuck_out_tongue:

… and didn’t try to help with the actual problem I am having and
that’s with the function call to

wglGetProcAddress

returning duplicate addresses for different functions.

Why are you loading OpenGL32.dll using loadlibrary??

Anyway, no problem with gl/sdl and extensions here. I don’t use the
"Init_WGL_extensions" you mention, but do the stuff myself using
SDL_GL_GetProcAddress() something like this:

#define INIT_ENTRY_POINT( funcname , type )
funcname = (type) SDL_GL_GetProcAddress(#funcname);
if(!funcname) cerr << “#funcname() not initialized” << endl;

INIT_ENTRY_POINT( wglCreatePbufferARB, PFNWGLCREATEPBUFFERARBPROC );

Regards,
\Mikkel Gjoel_______________________________________________
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

If you post your code, or a stripped down version of it that exhibits the same
problem, we would have a better chance of finding out what’s going wrong.

Also, what version of SDL are you using? Somebody mentioned SDL 1.3, and if
that’s the version you’re using, understand that SDL 1.3.x is the
experimental branch. SDL 1.2.x is the stable branch. Try SDL 1.2.5 and/or
1.2.6 and see if the same problem happens.

-Sean Ridenour> I’m getting a weird error, and, oddly, even without the SDL Parachute

enabled, VC7’s debugger says the error occurs in my own SDL_main(), but it
happens in a spot (I looked at the assembly – it’s about 8 instructions
past the call to the actual culprit) where the specific error couldn’t
happen (the static JMP at the end of a loop). Long story short, with alot
of printf()ing I’ve narrowed it down straight to SDL_GL_SwapBuffers(). The
error goes something like this: "Unhandled exception at 0x10029011 in
QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all the
right stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT into
SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and SDL_INIT_NOPARACHUTE into
SDL_Init. Everything seems to be in order – especially since it’s all
exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If so,
what’s causing it and/or how is it fixed? If not, can anyone help me build
a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

Actually found the problem had nothing really to do with my code. It was
actually linking in the wrong versions of the librarys (of both OpenGL and
SDL) – no idea why it actually caused the error by doing this, though. I
reworked my path order to both SDL and OpenGL libraries, and everything
seems to work fine again.
Anyways, thanks for the help people were trying to provide. I hope Thomas
figures out why his stuff isn’t working the propper way – it’s probably a
problem I’ll run into eventually.

  • Silicon> ----- Original Message -----

From: s_ridenour@kewlpc.org (Sean Ridenour)
To:
Sent: Sunday, October 26, 2003 1:39 PM
Subject: Re: [SDL] Problems with SDL’s GL support?

If you post your code, or a stripped down version of it that exhibits the
same
problem, we would have a better chance of finding out what’s going wrong.

Also, what version of SDL are you using? Somebody mentioned SDL 1.3, and
if
that’s the version you’re using, understand that SDL 1.3.x is the
experimental branch. SDL 1.2.x is the stable branch. Try SDL 1.2.5 and/or
1.2.6 and see if the same problem happens.

-Sean Ridenour

I’m getting a weird error, and, oddly, even without the SDL Parachute
enabled, VC7’s debugger says the error occurs in my own SDL_main(), but
it

happens in a spot (I looked at the assembly – it’s about 8 instructions
past the call to the actual culprit) where the specific error couldn’t
happen (the static JMP at the end of a loop). Long story short, with
alot

of printf()ing I’ve narrowed it down straight to SDL_GL_SwapBuffers().
The

error goes something like this: "Unhandled exception at 0x10029011 in
QF.exe: 0xC0000005: Access violation reading location 0x0000012c."
Now, I went through alot of my standard checks – makeing sure all the
right stuff is being passed to SDL; SDL_HWSURFACE and SDL_OPENGLBLIT
into

SDL_InitVideo; SDL_INIT_VIDEO, SDL_INIT_TIMER and SDL_INIT_NOPARACHUTE
into

SDL_Init. Everything seems to be in order – especially since it’s all
exactly common to programs I’ve written in the past.
My question is, has anyone run into this kind of problem before? If so,
what’s causing it and/or how is it fixed? If not, can anyone help me
build

a debug version of the SDL library, and link with it in VC7?

Any help would be very much appreciated.

  • John Silicon

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003

That was in no way meant as an insult :wink: I understand everyone has their
own interests. I am just frustrated trying to get this demo to run. The
current CVS code sets up the ARB extensions using
this->gl_data->wglGetProcAddress, which is set in WIN_GL_LoadLibrary
using a call to a winapi function GetProcAddress(). All I really know
is, that the addresses I get this way are wrong. I just can’t seem to
figure out why. When I load the OpenGL32 library myself and use
wglGetProcAddress myself in a blank program, I get the correct
addresses.

Can you try using wglGetProcAddress pointer returned from GetProcAddress
and see if that’s what’s causing the problem?

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Hi!

I have used the wglGetProcAddress returned by GetProcAddress (after
using LoadLibrary to get a handle to the dll) in the NeHe Lesson1
program, just to see what addresses I would get. I have pasted the code
from that function below. When I do this, I get different addresses for
each function that I try to retrieve the address for. The address
returned by GetProcAddress for wglGetProcAddress is the same in that
test example as it is in the 1.3 CVS. However the addresses returned by
wglGetProcAddress are different in the two cases. In the case of the
modified Lesson1, I get the following: (I know these addresses may not
be right on every machine, but this is just for illustration)

wglGetExtensionsStringARB = 0x69615050
wglChoosePixelFormatARB = 0x69615340
wglGetPixelFormatAttribivARB = 0x696152a0
wglCreatePbufferARB = 0x69615090
wglGetPbufferDCARB = 0x696150e0
wglReleasePbufferDCARB = 0x69615120
wglDestroyPbufferARB = 0x69615160
wglQueryPbufferARB = 0x696151a0

If I put a break point at the end of the function
Init_WGL_ARB_extensions in the file sdl_wingl.c, i get the following
addresses in this->gl_data

wglGetExtensionsStringARB = 0x69615050
wglChoosePixelFormatARB = 0x69615340
wglGetPixelFormatAttribivARB = 0x696152a0
wglCreatePbufferARB = 0x69615340
wglGetPbufferDCARB = 0x69615340
wglReleasePbufferDCARB = 0x69615340
wglDestroyPbufferARB = 0x69615340
wglQueryPbufferARB = 0x69615340

The function address returned by GetProcAddress for wglGetProcAddress is
the same (0x5ed19777) either way.

Pardon the long email, but I wanted to make sure it was clear what I had
done.

Jay

Here is the code I put into Lesson1. (the code in sdl_wingl.c has not
changed)
void Init_WGL_ARB_Extensions(PIXELFORMATDESCRIPTOR* pfd)
{
HWND hwnd;
HDC hdc;
HGLRC hglrc;
int pformat;
HMODULE handle;
// PIXELFORMATDESCRIPTOR pfd;
void * (WINAPI *wglGetProcAddress)(const char *proc);
const char * (WINAPI *wglGetExtensionsStringARB)(HDC);
BOOL (WINAPI *wglChoosePixelFormatARB)(HDC hdc, const int
*piAttribIList,
const FLOAT *pfAttribFList,
UINT nMaxFormats, int
*piFormats,
UINT *nNumFormats);
BOOL (WINAPI *wglGetPixelFormatAttribivARB)(HDC hdc, int
iPixelFormat,
int iLayerPlane,
UINT nAttributes,
const int *piAttributes,
int *piValues);

HPBUFFERARB (WINAPI *wglCreatePbufferARB)(HDC hDC, int iPixelFormat,

int iWidth, int iHeight, const int *piAttribList);
HDC (WINAPI *wglGetPbufferDCARB) (HPBUFFERARB hPbuffer);
int (WINAPI *wglReleasePbufferDCARB)(HPBUFFERARB hPbuffer, HDC hDC);
BOOL (WINAPI *wglDestroyPbufferARB)(HPBUFFERARB hPbuffer);
BOOL (WINAPI *wglQueryPbufferARB)(HPBUFFERARB hPbuffer, int
iAttribute, int *piValue);

BOOL (WINAPI *wglBindTexImageARB)(HPBUFFERARB hPbuffer, int

iBuffer);
BOOL (WINAPI *wglReleaseTexImageARB)(HPBUFFERARB hPbuffer, int
iBuffer);

hwnd = CreateWindow("Test Window", "Test Window", WS_POPUP |

WS_DISABLED,
0, 0, 10, 10,
NULL, NULL, hInstance, NULL);
hdc = GetDC(hwnd);

// pfd = pfd_array;

pformat = ChoosePixelFormat(hdc, pfd);
SetPixelFormat(hdc, pformat, pfd);

hglrc = wglCreateContext(hdc);
if(hglrc)
{
	wglMakeCurrent(hdc, hglrc);
}

handle = LoadLibrary("OpenGL32.dll");

wglGetProcAddress = (void * (WINAPI *)(const char

*))GetProcAddress(handle, “wglGetProcAddress”);

wglGetExtensionsStringARB = (const char * (WINAPI

*)(HDC))wglGetProcAddress(“wglGetExtensionsStringARB”);

wglChoosePixelFormatARB = (BOOL (WINAPI *)(HDC, const int *,

const FLOAT *, UINT, int *, UINT *))
wglGetProcAddress(“wglChoosePixelFormatARB”);

wglGetPixelFormatAttribivARB = (BOOL (WINAPI *)(HDC, int, int,

UINT, const int *, int
*))wglGetProcAddress(“wglGetPixelFormatAttribivARB”);

wglCreatePbufferARB = (HPBUFFERARB (WINAPI *)(HDC hDC, int

iPixelFormat, int iWidth, int iHeight, const int
*piAttribList))wglGetProcAddress(“wglCreatePbufferARB”);

wglGetPbufferDCARB = (HDC (WINAPI *) (HPBUFFERARB

hPbuffer))wglGetProcAddress(“wglGetPbufferDCARB”);

wglReleasePbufferDCARB = (int (WINAPI *)(HPBUFFERARB hPbuffer,

HDC hDC))wglGetProcAddress(“wglReleasePbufferDCARB”);

wglDestroyPbufferARB = (BOOL (WINAPI *)(HPBUFFERARB

hPbuffer))wglGetProcAddress(“wglDestroyPbufferARB”);

wglQueryPbufferARB =(BOOL (WINAPI *)(HPBUFFERARB hPbuffer, int

iAttribute, int *piValue))wglGetProcAddress(“wglQueryPbufferARB”);

if ( hglrc ) {
	wglMakeCurrent(NULL, NULL);
	wglDeleteContext(hglrc);
}

ReleaseDC(hwnd, hdc);
DestroyWindow(hwnd);

}

Make sure that you’re using the local copy of wgetlGetProcAddress, e.g.
name it something like get_func, and see if the results are the same.

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment