headers
Yann Morvan | 2 Oct 2004 02:49
Picon
Picon

Choice between old and new API

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
Permalink | Reply | 18 comments |
headers
Sven Panne | 2 Oct 2004 23:06
Picon

Re: Choice between old and new API

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
(Continue reading)

Permalink | Reply | 17 comments |
headers
Mike Thomas | 4 Oct 2004 02:02

RE: Choice between old and new API

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.
Permalink | Reply | 0 comments |
headers
Yann Morvan | 7 Oct 2004 17:23
Picon
Picon

Re: Choice between old and new API

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
Permalink | Reply | 15 comments |
headers
Yann Morvan | 8 Oct 2004 17:20
Picon
Picon

Runtime error when using blending (on windows XP)

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
Permalink | Reply | 14 comments |
headers
Sven Panne | 8 Oct 2004 18:39
Picon

Re: Runtime error when using blending (on windows XP)

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.
Permalink | Reply | 11 comments |
headers
Yann Morvan | 8 Oct 2004 22:25
Picon
Picon

Re: Runtime error when using blending (on windows XP)

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.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Sven Panne | 8 Oct 2004 23:23
Picon

Re: Runtime error when using blending (on windows XP)

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
(Continue reading)

Permalink | Reply | 9 comments |
headers
Yann Morvan | 9 Oct 2004 00:03
Picon
Picon

Re: Runtime error when using blending (on windows XP)

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
Permalink | Reply | 8 comments |
headers
Yann Morvan | 9 Oct 2004 01:29
Picon
Picon

Re: Runtime error when using blending (on windows XP)

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
Permalink | Reply | 6 comments |

Gmane