1. OpenGl again.
- Posted by Paul Martin <twilight at WCC.NET> Apr 08, 1999
- 435 views
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
2. Re: OpenGl again.
- Posted by Paul Martin <twilight at WCC.NET> Apr 13, 1999
- 447 views
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 > >
3. Re: OpenGl again.
- Posted by Caballero Rojo <ebonvehi at CPSARG.COM> Apr 13, 1999
- 403 views
- Last edited Apr 14, 1999
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
4. Re: OpenGl again.
- Posted by LEVIATHAN <lordlev at WA.FREEI.NET> Apr 13, 1999
- 405 views
- Last edited Apr 14, 1999
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"
5. Re: OpenGl again.
- Posted by "C. K. Lester" <cklester at TICNET.COM> Apr 14, 1999
- 397 views
Your are exploring unknown frontier, my friend... keep going! IOW, I can't help you, but I'm interested in your results. -----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 >> >> >
6. Re: OpenGl again.
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Apr 14, 1999
- 404 views
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.
7. Re: OpenGl again.
- Posted by Paul Martin <twilight at WCC.NET> Apr 14, 1999
- 404 views
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
8. Re: OpenGl again.
- Posted by ddhinc <ddhinc at ALA.NET> Apr 15, 1999
- 422 views
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