I am doing research in computer graphics and have been using the old HOpenGL to try ideas. Recently I've wanted to use 2D convolution and discovered it wasn't supported in HOpenGL 1.5. I am a bit constrained by time (I have a Ph.D. to finish) and I wanted to know what would be the easiest between: -learning how to build the old HOpenGL 1.5 API and then adding the bindings for the convolution functionnalities -or porting my existing code (which is around a few thousand lines) to use the new most recent API, provided it supports texturing and convolution Unfortunately I am developping under windows XP, using the cygwin environment. If I have to compile the latest version of the GHC distribution to get those functionnalities, I am worried that it may prove very time consuming. Assuming that this is not a problem, how different is the new API from the old one ? Will the changes I'll have to make to my old code be merely cosmetic or more in depth ? Thank you for your help. Yann Morvan
Yann Morvan wrote:
I am doing research in computer graphics and have been using the old HOpenGL to try ideas. Recently I've wanted to use 2D convolution and discovered it wasn't supported in HOpenGL 1.5. I am a bit constrained by time (I have a Ph.D. to finish) and I wanted to know what would be the easiest between: -learning how to build the old HOpenGL 1.5 API and then adding the bindings for the convolution functionnalities
This would be wasted effort IMHO...
-or porting my existing code (which is around a few thousand lines) to use the new most recent API, provided it supports texturing and convolution
Sounds more promising... :-)
Unfortunately I am developping under windows XP, using the cygwin environment. If I have to compile the latest version of the GHC distribution to get those functionnalities, I am worried that it may prove very time consuming. Assuming that this is not a problem, how different is the new API from the old one ? Will the changes I'll have to make to my old code be merely cosmetic or more in depth ?
As almost always, the answer is somewhere in between: The new API is much more symmetric and centred around OpenGL's notion of state variables. If you know OpenGL quite well (as you obviously do when you use rather uncommon things like convolution), you should have no real problems switching to the new API. Documentation for the bleeding edge stuff can be found at http://haskell.org/HOpenGL/newAPI/ and lots of examples are in the CVS HEAD, see http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/examples/ Especially http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/examples/Re... might be of interest to you. Building under Windoze should pose no real problems nowadays, but Mike is doing some nightly builds, perhaps he can even provide you with a binary snapshot. The "real thing", i.e. GHC 6.4 with full OpenGL 1.5 support, will probably take 1-2 months until it is released. The soon-to-be-released GHC 6.2.2 does offer the new API, but no convolution stuff. Cheers, S.
Hi Sven, Yann Svenn wrote to Yann:
Building under Windoze should pose no real problems nowadays, but Mike is doing some nightly builds, perhaps he can even provide you with a binary snapshot.
I'll include --enable-hopengl in my builds. Note that I'm producing MinGW32 rather than Cygwin GHC executables. There was some trouble with HEAD over the past few days but hopefully that has already been ironed out. I'll need somewhere to upload the resulting archive as I don't have a suitable distribution site. Cheers Mike Thomas.
Thanks a lot for the advice. I chose to try and compile GHC and the new HOpenGL api, it worked with very little tweaking. I just finished porting my code to the new API, which looks better indeed, I'm in the process of figuring out linking errors, I have good hopes it will run as it should once it compiles. Yann
Hello, I am getting a runtime error when I set blendEquation to Just FuncAdd it happens in my code as well as in Alpha.hs. I'll be looking into it in the binding but I thought it could be a known issue and I'm sure you'll be faster to fix it than I will (if I can). Yann
Yann Morvan wrote:
I am getting a runtime error when I set blendEquation to Just FuncAdd it happens in my code as well as in Alpha.hs. I'll be looking into it in the binding but I thought it could be a known issue and I'm sure you'll be faster to fix it than I will (if I can).
Hmmm, without a little bit more info it will be hard to guess what's going on. Could you send the exact error message, your platform (incl. OpenGL driver version), etc., please? Apart from that I guess you used the GHC and the OpenGL/GLUT stuff from HEAD, correct? Cheers, S.
Yes I'm sorry for the lack of details, here is what I could gather. I am using GHC 6.3 that I compiled from the fptools distribution that I downloaded from the CVS server whithout specifying any branch. It was compiled under windows XP in a cygwin environment, with all the mingw tools, targeting a mingw environment. I copied the glut.h from usr/include/GL into usr/local/include/mingw/GL. Unfortunately I only get a windows XP error window of the type "main.exe has encountered a problem and needs to close". The error report says the code of the exception is 0xc0000005 (access violation). I am sorry but I don't know how to get a more accurate error description. (I'm reading right now about the -xc RTS option so I might get back to you with a better error). However the error seems to clearly come from the call to blendEquation, since the program runs fine when I comment it out.
From having a look at the binding, my guess is that the call to hOpenGL_getProcAddress returns a NULL pointer, the reason for that would be that a configuration problem with the opengl headers and libraries when I built the package is causing hOpenGL_gpa in HsOpenGL.c to behave oddly.
The thing is I am very confused as to how GHC configures itself when it comes to the OpenGL headers and libraries. Does it use the headers in usr/local/include/mingw or usr/include/w32api, does it use the libraries from lib/w32api, or usr/local/gcc-lib, or the windows dlls, or something else ? The opengl32.dll in windows/system32 says it's version 5.1.2600.1106 The registry key for OpenGLDrivers points to atioglxx.dll, I could find 4 on my machine, the one in windows\system32 says it's version 6.14.10.4332, from Microsoft. I guess a good start would be to -know what implementation of OpenGL works best with HOpenGL under windows -place the corresponding files where fptools will look when configuring the build, and prevent it from finding headers that don't match libraries and vis versa -re-build HOpenGL It would be great if you could help me with the first two steps, in the meanwhile I'll be trying to figure things out. Yann
Yann Morvan wrote:
[...] However the error seems to clearly come from the call to blendEquation, since the program runs fine when I comment it out.
From having a look at the binding, my guess is that the call to hOpenGL_getProcAddress returns a NULL pointer, the reason for that would be that a configuration problem with the opengl headers and libraries when I built the package is causing hOpenGL_gpa in HsOpenGL.c to behave oddly.
Hmmm, is any example requiring the OpenGL extension mechanism working for you, e.g. FogCoord, BlendEqn, MultiTex, Histogram, ...?
The thing is I am very confused as to how GHC configures itself when it comes to the OpenGL headers and libraries. Does it use the headers in usr/local/include/mingw or usr/include/w32api, does it use the libraries from lib/w32api, or usr/local/gcc-lib, or the windows dlls, or something else ?
Once I knew this, but I think I'll have to take a closer look at these things again before I can make any statement. :-]
[...] I guess a good start would be to -know what implementation of OpenGL works best with HOpenGL under windows
The OpenGL implementation should really not matter at all, the only issue I'm aware of is tessellation under any WinDoze: Microsoft's DLL only supports an ancient GLU version, so someday I'll have to find a workaround. It doesn't seem to be mission-critical for anybody so far, so I was simply too lazy fixing this.
-place the corresponding files where fptools will look when configuring the build, and prevent it from finding headers that don't match libraries and vis versa [...]
configure should take care of this, not you. Having the output of the configure run and the compilation log plus config.log might help. Cheers, S.
Well, it looks like I've been too quick to speak. I was stuck with an old opengl dll (the one that came with windows, somehow I expected it to be reasonably up to date), so most wglGetProcAddress calls are indeed returning NULL. Replacing it with a recent mesa one made my C test program return non NULL addresses. I don't really understand how libHopenGL is built from the relevent dlls, but it looks like I will have to recompile the package, since my program still crashes. Sorry to have bothered you for so little. Yann
Well, sorry to be poluting the list, but I'll have to display my ignorance of how libraries work again :) It seems that my problems come from the fact that the opengl libraries that come with cygwin are ancient, and have little to do with the windows dll. When building under cygwin, do the opengl libraries need to be tweaked for cygwin, or can I use any ? If I can, and choose the latest MESA for windows ones for instance, which are import libraries by default, how do I force the building process to use them and will gcc be able to use them as is ? Yann
Erratum to my last message: I don't know what went through my head but I used windows' "search in files" feature instead of greping, needless to say, I did find many instances of DONT_WANT_WIN32_DLL_SUPPORT... So I'll be looking into it. But if you know what could be going on, feel free to end my pain. Yann
My message before the last one is waiting for approval of a moderator (the configure log file made it huge), hence the confusion. I tried to force fptools to produce dlls by putting a DLLized = YES in build.mk I get: ------------------------------------------------------------------------ ==fptools== make all - --unix -wr; in /cygdrive/c/fptools2/ghc/rts ------------------------------------------------------------------------ make[2]: *** No rule to make target `Main.dll_o', needed by `all'. Stop. make[1]: *** [all] Error 1 make[1]: Leaving directory `/cygdrive/c/fptools2/ghc' make: *** [build] Error 1 Main.dll_o being the file that ld couldn't find when I tried to compile Alpha.hs with the -dynamic option I feel quite lost and don't even know if I'm investigating in the right direction. Should I try and build only the HOpenGL library using the last stable GHC for windows and then somehow plug the package into it ? Yann
I tried to force fptools to produce dlls by putting a DLLized = YES in build.mk
Unfortunately, dynamic linking support has last worked in GHC version 4 or something like that. It's been unsupported for some time now, so you won't have any luck in that direction. Cheers, Wolfgang
I indeed went in the wrong direction. It seems that the problem is in the HOpenGL code that handles extensions. So far I think I have identified two problems: -calling wglGetProcAddress was raising an access violation, after it returned the proper address for the opengl extension function (as compared with the result of similar C code) When I use newCString instead of withCString in getProcAddress (in Extensions.hs), the problem goes away. But then, when to free it ? And what was the exact cause of the problem ? - In the macro that defines the extension Invoker (in HsOpenGLExt.h), it seems that the "dyn_" prefix in the dynamic foreign import call is not consistent with opengl dlls symbols. Removing it gets rid of the last access violation. I'll try to incorporate the hacks in HOpenGL and compile it, so far I've only been copying the problematic bits in a test program to tweak them. Yann
Once again I spoke too quickly, the dyn_ prefix doesn't seem to mater. Yann
And it also looks like that thing about withCString causing problems when calling wglGetProcAddress was a red herring. Must read about scientific method... Over all pretty much everything I said and tried in this thread was garbage. I started a new thread that will hopefully be sounder. Apologies for the spam. Yann
Yann Morvan wrote:
Well, it looks like I've been too quick to speak. I was stuck with an old opengl dll (the one that came with windows, somehow I expected it to be reasonably up to date), so most wglGetProcAddress calls are indeed returning NULL. Replacing it with a recent mesa one made my C test program return non NULL addresses. I don't really understand how libHopenGL is built from the relevent dlls, but it looks like I will have to recompile the package, since my program still crashes.
OpenGL libraries which support hardware acceleration (including the
one supplied with Windows) simply act as a front end to a separate
driver which is specific to your graphics hardware. A particular
driver may or may not support a specific OpenGL extension; if the
driver doesn't support it, then wglGetProcAddress() will return NULL.
If the driver doesn't implement a particular function, it may be
because the hardware isn't capable of providing the corresponding
functionality. In that situation, the only solution would be to get a
more featureful graphics card.
OTOH, if you use Mesa, the functionality available doesn't depend upon
the hardware, as Mesa does all of the rendering in software. If one
version of Mesa doesn't provide a particular extension, a later
version might.
--
Glynn Clements
Hello, I am getting a strange bug while using automatic texture generation, the specification of a plane for eye linear generation will sometimes fail depending on wether or not I call an unrelated function before, which doesn't even contain calls to OpenGL functions. It was working properly under the old API, and the new API bindings of the texture generation functions seem correct to me, so I thought maybe the compiler itself was at fault, but when I try to install the HOpenGL package inside my ghc 6.2.1 distribution, it complains about mismatched interface file versions upon building (since the HOpenGL .hi files are 6.3). Is there a way around this ? Does that mean I should rebuild the HOpenGL .hi files using ghc 6.2.1 ? Thank you for your help, Yann Morvan
I compiled the latest new api for use with ghc 6.2.1, the bug I was talking about disappeared. I don't have any idea what could have caused it. The function whose behaviour was buggy was textureGenMode, the buggy behaviour happened only when a function doing floating point operations was called before. I can send further details if there is an interest, but I haven't narrowed the problem much so it could be tedious. Yann Morvan
participants (5)
-
Glynn Clements -
Mike Thomas -
Sven Panne -
Wolfgang Thaller -
Yann Morvan