glshim

[dreamer]

Cool, will test it with Puredata/GEM soon.

[Edit: ok I now get past glMap2d, but on to the next one -> glEvalMesh1, which is basically implemented by glEvalMesh2. I briefly looked at how it 'should' work (but probably I'm doing this horribly wrong and possibly these could be handled in the same function?):

Spoiler

GLvoid glEvalMesh1(GLenum mode, GLint i1, GLint i2) {
    MapStateF *map;
    if (! state.map2.vertex3 || !state.map2.vertex4)
        return;

    if (map->type == GL_DOUBLE) {
        printf("libGL: GL_DOUBLE map not implemented\n");
        return;
    }

    GLfloat u, du, u1;
    GLint i;
    GLenum renderMode;
    switch (mode) {
        case GL_POINT:
            renderMode = GL_POINTS;
            break;
        case GL_LINE:
            renderMode = GL_LINE_STRIP;
            break;
        case GL_FILL:
            renderMode = GL_TRIANGLE_STRIP;
            break;
        default:
            printf("unknown glEvalMesh1f mode: %x\n", mode);
            return;
    }
    glBegin(renderMode);
    for (u = u1, i = i1; i <= i2; i++, u += du) {
        glEvalCoord1f(u);
    }
    glEnd();
}

I get it compiled and then I'm missing glEvalPoint1, which seems to be exactly the routine used by the glEvalMesh functions. I'm sure these details can be worked out easy enough. And then on to the next one o/]

 

[ptitSeb]

@lunixbosch, there is a little mistake, in src/gl/gl.c line 166

it should be

gles_glDrawElements(mode, count, GL_UNSIGNED_SHORT, shortIndices);

instead of

gles_glDrawElements(mode, count, GL_UNSIGNED_SHORT, indices);

 

[ptitSeb]

The libGLU on your github doesn't compile the "nurbs" components. a problem (at least for me) with cmake doesn't understand the "libnurbs/*/". I put all sources in the same folder (to avoid duplicate some .h), and added a "-DGLBUILD" and remove a #include <stdlib.h> in mysetjmp.h to have a successfull compile.

It's not that I want nurbs, but many "configure" check the presence of libGLU by testing the gluBeginCurve function...

*EDIT* nope, this isn't quite that. It compile, but failed when the result libGLU is linked, with undefined gl_longjmp

I think a -DLIBRARYBUILD is better then -DGLBUILD

*EDIT2* Yes, that did the trick !

 

[ptitSeb]

Also, on a very positive  note, the porting of Naev was very straightforward. I just altered some code to allow 800x480 (it was 800x600 minimum before).

A very good tool this lib !

 

[ingoreis]

Can you plz try the latest Version of Lxdream?

http://www.lxdream.org/hg/lxdream/archive/tip.tar.gz

This is the latest Version when i am right

 

[mcobit]

Tried to run UltimateStunts with your lib.

But got some errors.

Maybe you could have a look at that?

glXGetProcAddress: glLockArraysEXT not found.
glXGetProcAddress: glUnlockArraysEXT not found.
Compiled vertex array functions NOT found in openGL driver
ustunts: symbol lookup error: ustunts: undefined symbol: glInterleavedArrays

 

[lunixbochs]

Compile a new one from source. I just haven't uploaded a lib in a bit. I did implement glInterleavedArrays for Ultimate Stunts. Prepare yourself for a potential unrelated segfault

 

[mcobit]

Ok... I used 7.5 and did not have a segfault when running with mesa.

 

[mcobit]

Ok. Latest LIBGL reduced the errors to:


glXGetProcAddress: glLockArraysEXT not found.
glXGetProcAddress: glUnlockArraysEXT not found.
Compiled vertex array functions NOT found in openGL driver
Segmentation fault

As said, I can run it just fine with the mesa lib.
 So there might still be some libgl related problem.

I also disabled Compiled vertex arrays in the options but it still seems to complain.

 

[ptitSeb]

One thing I have notice trying to port Protoype is that it expected, for the font handling, that 2 glGenTexture call to give ID and ID+1 (ok, not very clear explanation, lok at Font.cpp for detail). It is was not the case, and so the shadow of the font where wrong. This assumption seems wrong to me, so I changed code to get 2 textures in 1 call instead.

I'm still having segfault in the game...

 

[mcobit]

I tried egoboo today and it segfaults with the latest version of libGL from git.

Worked before when I commented the glClearAccum stuff.

There might be something that lets programs segfault in the current version.

It runs fine with mesagl.

 

[mcobit]

A snippet from gdb with egoboo:


Initializing filesystem services...
Game directories are:
Binaries: /mnt/utmp/egoboo/games/
Data: /mnt/utmp/egoboo/share/games/egoboo-2.x
User Data: /home/maddin/.egoboo-2.x
Config Files: /mnt/utmp/egoboo/etc/egoboo-2.x

Program received signal SIGSEGV, Segmentation fault.
0x400bd524 in SDL_WM_SetIcon ()
from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0
Current language: auto
The current source language is "auto; currently asm".

Edit: Could this be a problem with the libSDL supplied by the codeblockspnd?

 

[ptitSeb]

That maybe. I have update many libs in codeblocks to develop with the new libGL. Maybe update the libSDL with the one from critical mass, or remove the codeblocks build?

Anyway, SetIcon doesn't look important...

 

[mcobit]

With normal sdl it works great. Looks nice but is slow as hell

So if someone wants to package up egoboo, go ahead

 

[ptitSeb]

With normal sdl it works great. Looks nice but is slow as hell

So if someone wants to package up egoboo, go ahead

I'll bive it a try maybe soon, if I don't go back to Quake engine games...

 

[lunixbochs]

One thing I have notice trying to port Protoype is that it expected, for the font handling, that 2 glGenTexture call to give ID and ID+1 (ok, not very clear explanation, lok at Font.cpp for detail). It is was not the case, and so the shadow of the font where wrong. This assumption seems wrong to me, so I changed code to get 2 textures in 1 call instead.

I'm still having segfault in the game...

Their assumption definitely broke the OpenGL spec. Texture numbers are somewhat random. A single call to glGenTexture can return nonconsecutive texture names.

 

[mcobit]

I tested a bit with glut|es and it works nicely with lunixbochs lib. Unfortunately it is not complete. If somebody wants to have a look at that, it could be improved. In this case we would have gl glu and glut

 

[ptitSeb]

I tested a bit with glut|es and it works nicely with lunixbochs lib. Unfortunately it is not complete. If somebody wants to have a look at that, it could be improved. In this case we would have gl glu and glut

I compiled freeglut, and I think it works, but I'm not sure, it's for BillardGL and it just crash, but don't now why yet.

 

[lunixbochs]

I use freeglut without errors.

 

[mcobit]

Hmmm. Tried freeglut and the program didn't start. Something with creating glx context... The I used glutes and it worked.