1. OpenGl again.

Hello everyone.

If any of you have read my previous postings you'll know that I'm working
on wrappers for OpenGL/GLUT. OpenGL is a 3D graphics API and GLUT is
similar to Win32lib, except designed for OpenGL. You can find out more from
<www.opengl.org>. I have for the last four weeks been pulling my hair out
trying to get it to work. I've been plagued by one problem that I
absolutely can not track down, because windows returns an encryptic error
message that does not point to any place in my program. I believe the
problem may lie in GLUT and the callbacks, but I cannot be sure.

I was hoping a few of you would mind downloading what I have, taking a look
at it, and see what you can come up with. I really  wanted to get this to
work on my own, but I'm missing some critical piece of the puzzle.

So far GLUT opens a window, clears it and then bombs with the error message:

>EXW caused an invalid page fault in
>module EXW.EXE at 023f:00405053.
>Registers:
>EAX=00000000 CS=023f EIP=00405053 EFLGS=00210216
>EBX=0000000f SS=0247 ESP=0056fb88 EBP=00000654
>ECX=00000000 DS=0247 ESI=005806fc FS=420f
>EDX=00000000 ES=0247 EDI=0056fba2 GS=0000
>Bytes at CS:EIP:
>8b 55 76 81 e2 ff 00 00 00 89 45 72 83 fa 04 75
>Stack dump:
>000001f6 0058040c 00000000 00000001 00000200 000001f6 00000201 00f30247
00000200 000001f6 0058040c 00000002 00000202 00f30247 00ec0000 00000040

 and then

>EXW caused an invalid page fault in
>module <unknown> at 0000:0b75fc5d.
>Registers:
>EAX=bff87fc0 CS=023f EIP=0b75fc5d EFLGS=00210246
>EBX=bff87fc0 SS=0247 ESP=005600f8 EBP=00560118
>ECX=0056019c DS=0247 ESI=81760af0 FS=420f
>EDX=bff76859 ES=0247 EDI=00560290 GS=0000
>Bytes at CS:EIP:
>
>Stack dump:
>bff7684d 00560290 bff87fc0 005601c4 0056019c 0056057c bff76859 bff87fc0
005601ac bff87fc0 00560290 bff87fc0 005601c4 0056019c 0b75fc5d 00560304

This means apparently I'm passing a bad value to GLUT. I've run a trace on
the program and it occurs when it's in glutMainLoop() which is C procedure.

If you are willing to take a look you will need Euphoria 2.1, because it
requires multiple callbacks. You will also need the Mesa dll's. I have
posted the wrappers (56k) at
<http://www.geocities.com/CapeCanaveral/Campus/8684/Cube.zip>. I have
provided two demo programs cube.exw and simple.exw, both return with the
same errors. The Mesa dll's (352k) can be download here
<http://www.geocities.com/CapeCanaveral/Campus/8684/mesa3dll.zip>. DO NOT
put them in your windows\system directory, make a new directory elsewhere,
and put them there. Mesa is not 100% OpenGL compliant so if you overwrite
the ones in your windows\system directory other programs may break. If you
want more documentation on Opengl and GLUT you can visit <www.opengl.org>.
I've also include the C programs that I used for the demos, and the
libraries for OpenGL/GLUT.

You will probably need to edit the sequence "prefix" in each of the
libraries (glu.ew, glut2.ew, and opengl3.ew), to tell it where you placed
the Mesa dll's. Other than that they should run (sorta).

Even if you are not successful at figuring out what's wrong, I'd also
appreciate any feedback.

Thanks
Paul Martin

new topic     » topic index » view message » categorize

2. Re: OpenGl again.

Hello again,

Well I hate replying to my own E-mails, but I've only got one other reply.
I was wondering if I stumped everyone or does nobody care? I hoping it more
that I stumped everone, but if it is because nobody cares then I need to
know that I'm wasting my time.

Thanks
Paul Martin


At 11:53 AM 4/8/99 -0500, you wrote:
>Hello everyone.
>
>If any of you have read my previous postings you'll know that I'm working
>on wrappers for OpenGL/GLUT. OpenGL is a 3D graphics API and GLUT is
>similar to Win32lib, except designed for OpenGL. You can find out more from
><www.opengl.org>. I have for the last four weeks been pulling my hair out
>trying to get it to work. I've been plagued by one problem that I
>absolutely can not track down, because windows returns an encryptic error
>message that does not point to any place in my program. I believe the
>problem may lie in GLUT and the callbacks, but I cannot be sure.
>
>I was hoping a few of you would mind downloading what I have, taking a look
>at it, and see what you can come up with. I really  wanted to get this to
>work on my own, but I'm missing some critical piece of the puzzle.
>
>So far GLUT opens a window, clears it and then bombs with the error message:
>
>>EXW caused an invalid page fault in
>>module EXW.EXE at 023f:00405053.
>>Registers:
>>EAX=00000000 CS=023f EIP=00405053 EFLGS=00210216
>>EBX=0000000f SS=0247 ESP=0056fb88 EBP=00000654
>>ECX=00000000 DS=0247 ESI=005806fc FS=420f
>>EDX=00000000 ES=0247 EDI=0056fba2 GS=0000
>>Bytes at CS:EIP:
>>8b 55 76 81 e2 ff 00 00 00 89 45 72 83 fa 04 75
>>Stack dump:
>>000001f6 0058040c 00000000 00000001 00000200 000001f6 00000201 00f30247
>00000200 000001f6 0058040c 00000002 00000202 00f30247 00ec0000 00000040
>
> and then
>
>>EXW caused an invalid page fault in
>>module <unknown> at 0000:0b75fc5d.
>>Registers:
>>EAX=bff87fc0 CS=023f EIP=0b75fc5d EFLGS=00210246
>>EBX=bff87fc0 SS=0247 ESP=005600f8 EBP=00560118
>>ECX=0056019c DS=0247 ESI=81760af0 FS=420f
>>EDX=bff76859 ES=0247 EDI=00560290 GS=0000
>>Bytes at CS:EIP:
>>
>>Stack dump:
>>bff7684d 00560290 bff87fc0 005601c4 0056019c 0056057c bff76859 bff87fc0
>005601ac bff87fc0 00560290 bff87fc0 005601c4 0056019c 0b75fc5d 00560304
>
>This means apparently I'm passing a bad value to GLUT. I've run a trace on
>the program and it occurs when it's in glutMainLoop() which is C procedure.
>
>If you are willing to take a look you will need Euphoria 2.1, because it
>requires multiple callbacks. You will also need the Mesa dll's. I have
>posted the wrappers (56k) at
><http://www.geocities.com/CapeCanaveral/Campus/8684/Cube.zip>. I have
>provided two demo programs cube.exw and simple.exw, both return with the
>same errors. The Mesa dll's (352k) can be download here
><http://www.geocities.com/CapeCanaveral/Campus/8684/mesa3dll.zip>. DO NOT
>put them in your windows\system directory, make a new directory elsewhere,
>and put them there. Mesa is not 100% OpenGL compliant so if you overwrite
>the ones in your windows\system directory other programs may break. If you
>want more documentation on Opengl and GLUT you can visit <www.opengl.org>.
>I've also include the C programs that I used for the demos, and the
>libraries for OpenGL/GLUT.
>
>You will probably need to edit the sequence "prefix" in each of the
>libraries (glu.ew, glut2.ew, and opengl3.ew), to tell it where you placed
>the Mesa dll's. Other than that they should run (sorta).
>
>Even if you are not successful at figuring out what's wrong, I'd also
>appreciate any feedback.
>
>Thanks
>Paul Martin
>
>

new topic     » goto parent     » topic index » view message » categorize

3. Re: OpenGl again.

Hi Paul Martin,
        Sorry if I don=B4t answer that mail that u posted, but I=B4m only
interested on DOS programming.
        I think that you are doing a grat job with that lib.

Keep working on it, I=B4m sure that somebody is interested on it.

Best wishes,
        Red Knight

new topic     » goto parent     » topic index » view message » categorize

4. Re: OpenGl again.

Paul Martin wrote:

> Hello again,
>
> Well I hate replying to my own E-mails, but I've only got one other reply.
> I was wondering if I stumped everyone or does nobody care? I hoping it more
> that I stumped everone, but if it is because nobody cares then I need to
> know that I'm wasting my time.
>
> Thanks
> Paul Martin

Well, its well on my way to help my brother achieve his ultimate fantasy: build
his own game. Tho hes got a loooooong way to go (yeah, he needs to know how to
use euphoria first ;) its progress.

Blessed Be, --"LEVIATHAN"

new topic     » goto parent     » topic index » view message » categorize

5. Re: OpenGl again.

Your are exploring unknown frontier, my friend... keep going!

IOW, I can't help you, but I'm interested in your results. blink

-----Original Message-----
From: Paul Martin <twilight at WCC.NET>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Tuesday, April 13, 1999 3:40 PM
Subject: Re: OpenGl again.


>Hello again,
>
>Well I hate replying to my own E-mails, but I've only got one other reply.
>I was wondering if I stumped everyone or does nobody care? I hoping it more
>that I stumped everone, but if it is because nobody cares then I need to
>know that I'm wasting my time.
>
>Thanks
>Paul Martin
>
>
>At 11:53 AM 4/8/99 -0500, you wrote:
>>Hello everyone.
>>
>>If any of you have read my previous postings you'll know that I'm working
>>on wrappers for OpenGL/GLUT. OpenGL is a 3D graphics API and GLUT is
>>similar to Win32lib, except designed for OpenGL. You can find out more
from
>><www.opengl.org>. I have for the last four weeks been pulling my hair out
>>trying to get it to work. I've been plagued by one problem that I
>>absolutely can not track down, because windows returns an encryptic error
>>message that does not point to any place in my program. I believe the
>>problem may lie in GLUT and the callbacks, but I cannot be sure.
>>
>>I was hoping a few of you would mind downloading what I have, taking a
look
>>at it, and see what you can come up with. I really  wanted to get this to
>>work on my own, but I'm missing some critical piece of the puzzle.
>>
>>So far GLUT opens a window, clears it and then bombs with the error
message:
>>
>>>EXW caused an invalid page fault in
>>>module EXW.EXE at 023f:00405053.
>>>Registers:
>>>EAX=00000000 CS=023f EIP=00405053 EFLGS=00210216
>>>EBX=0000000f SS=0247 ESP=0056fb88 EBP=00000654
>>>ECX=00000000 DS=0247 ESI=005806fc FS=420f
>>>EDX=00000000 ES=0247 EDI=0056fba2 GS=0000
>>>Bytes at CS:EIP:
>>>8b 55 76 81 e2 ff 00 00 00 89 45 72 83 fa 04 75
>>>Stack dump:
>>>000001f6 0058040c 00000000 00000001 00000200 000001f6 00000201 00f30247
>>00000200 000001f6 0058040c 00000002 00000202 00f30247 00ec0000 00000040
>>
>> and then
>>
>>>EXW caused an invalid page fault in
>>>module <unknown> at 0000:0b75fc5d.
>>>Registers:
>>>EAX=bff87fc0 CS=023f EIP=0b75fc5d EFLGS=00210246
>>>EBX=bff87fc0 SS=0247 ESP=005600f8 EBP=00560118
>>>ECX=0056019c DS=0247 ESI=81760af0 FS=420f
>>>EDX=bff76859 ES=0247 EDI=00560290 GS=0000
>>>Bytes at CS:EIP:
>>>
>>>Stack dump:
>>>bff7684d 00560290 bff87fc0 005601c4 0056019c 0056057c bff76859 bff87fc0
>>005601ac bff87fc0 00560290 bff87fc0 005601c4 0056019c 0b75fc5d 00560304
>>
>>This means apparently I'm passing a bad value to GLUT. I've run a trace on
>>the program and it occurs when it's in glutMainLoop() which is C
procedure.
>>
>>If you are willing to take a look you will need Euphoria 2.1, because it
>>requires multiple callbacks. You will also need the Mesa dll's. I have
>>posted the wrappers (56k) at
>><http://www.geocities.com/CapeCanaveral/Campus/8684/Cube.zip>. I have
>>provided two demo programs cube.exw and simple.exw, both return with the
>>same errors. The Mesa dll's (352k) can be download here
>><http://www.geocities.com/CapeCanaveral/Campus/8684/mesa3dll.zip>. DO NOT
>>put them in your windows\system directory, make a new directory elsewhere,
>>and put them there. Mesa is not 100% OpenGL compliant so if you overwrite
>>the ones in your windows\system directory other programs may break. If you
>>want more documentation on Opengl and GLUT you can visit <www.opengl.org>.
>>I've also include the C programs that I used for the demos, and the
>>libraries for OpenGL/GLUT.
>>
>>You will probably need to edit the sequence "prefix" in each of the
>>libraries (glu.ew, glut2.ew, and opengl3.ew), to tell it where you placed
>>the Mesa dll's. Other than that they should run (sorta).
>>
>>Even if you are not successful at figuring out what's wrong, I'd also
>>appreciate any feedback.
>>
>>Thanks
>>Paul Martin
>>
>>
>

new topic     » goto parent     » topic index » view message » categorize

6. Re: OpenGl again.

Paul, everybody wants good working OpenGL routines, but the kind of information
you provide is limited.
Most memory addresses are dynamically assigned and have little meaning to
others. You should at least bring the crash down to
one statement, and then, try to vary the values going to that statement. Read
some more documentation, and if everything fails,
post to an OpenGL group (if the error is really being caused by an OpenGL-DLL
call)

When the error is caused by exw.exe, Robert should be able to help you.
When the error is caused by you own direct memory manipulation routines, just
post the code or try to run if with safe.e rather
than with machine.e

Ralf

Paul Martin wrote:
> Well I hate replying to my own E-mails, but I've only got one other reply.
> I was wondering if I stumped everyone or does nobody care? I hoping it more
> that I stumped everone, but if it is because nobody cares then I need to
> know that I'm wasting my time.

new topic     » goto parent     » topic index » view message » categorize

7. Re: OpenGl again.

Hello Ralf

>Paul, everybody wants good working OpenGL routines, but the kind of
information you provide is limited.

That is because the information it returns is limited.

>Most memory addresses are dynamically assigned and have little meaning to
others. You should at least bring the crash down to
>one statement, and then, try to vary the values going to that statement.

Unfortunately, I've traced it down to a GLUT (a dll) routine
"glutMainLoop()" that is similar to "WinMain()" in Win32lib.ew. GLUT then
makes calls to two of my functions via call-backs, which is expected, and
then bombs (not expected). In the demo program that is a ported from an
example written in C, does not explicitly set the call backs that I'm not
using to NULL. Could this be a problem? The reason I asked is because
further research on the error I found that Windows is saying that the code
attempts to call a function through a pointer that has never been
explicitly initialized. I've attempted to set all of the ones that I do not
use to NULL, and I've tried sending them to a "do nothing" function, and it
still bombs.

>Read some more documentation, and if everything fails,
>post to an OpenGL group (if the error is really being caused by an
OpenGL-DLL call)

I have read tremendous amounts of information on OpenGl and GLUT. Frankly
the authors of OpenGL and GLUT never thought of someone attempting to write
a wrapper for it in Euphoria. So as it goes there is no information on the
subject. Posting my problem to a OpenGL group occurred to me, but what are
the odds that someone who writes software for OpenGl would be familar with
Euphoria?

>When the error is caused by exw.exe, Robert should be able to help you.

I guess since I cannot prove the origins of the error, and he's busy with
Euphoria 2.1, his help has been minimal.

>When the error is caused by you own direct memory manipulation routines,
just post the code or try to run if with safe.e rather
>than with machine.e

I have run my routines with safe.e and it does not report any errors. I use
only use direct memory routines in two places; when I have to pass the
command line parameters to GLUT, and when I have to pass a string to GLUT;
the rest are direct calls. I use the following routines for that:

>global sequence free_stuff
>free_stuff={}
>
>-----------------------------------------------------------------------------
>-- This routine handles the command line for glut and returns a sequence
>-- that has a pointer to the address where the number of elements in the
>-- command line are, and a pointer to an array that contain the actual
>-- elements.
>-- Thanks to Mathew Hounsell and Daniel Berstein for helping pointing me
>-- in the right direction for this routine.
>-----------------------------------------------------------------------------
>global function handle_comm_line()
>atom string, array_len, array_ad
>integer len
>sequence cmd
>cmd = command_line()
>cmd = cmd[2..length(cmd)] -- actually wants the name of the program
>len = length(cmd)
>array_ad = allocate ((len)*4)
>free_stuff= append(free_stuff,array_ad) -- so I can free it later
>for i = 1 to len do
>    string = allocate_string(cmd[i])
>    free_stuff = append(free_stuff,string)
>    poke (string,cmd[i] & 0)
>    poke (array_ad+((i-1)*4), int_to_bytes(string))
>end for
>array_len = allocate(4)
>free_stuff = append(free_stuff,array_len)
>poke (array_len, int_to_bytes(len))
>return {array_len, array_ad}
>end function
>----------------------------------------------------------------------------
>-- This is nifty routine that will free up all the memory that got
>-- allocated.
>----------------------------------------------------------------------------
>global procedure free_all()
>for i=1 to length(free_stuff) do
>    free(free_stuff[i])
>end for
>end procedure

For the strings this is typical:

>global function glutCreateWindow(sequence title) --(const char *title)
>        atom mem
>        mem = allocate_string(title)
>        poke(mem,title & 0)
>        return c_func( glut_CreateWindow,{mem})
>        free(mem)
>end function

If you see errors, by all means point them out.

Thanks
Paul Martin

new topic     » goto parent     » topic index » view message » categorize

8. Re: OpenGl again.

Hi Paul,
  This isn't garaunteed to work, but as a last resort it may be worth
a try...
Obtain the sources for Glut and recompile them with full debugging info
included. Run your program under your compiler's dubugger. If you're
lucky you might be abled to track the fault back to a call to a glut
function with your unitialized pointer.

Good Luck,
Christopher D. Hickman

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu