Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
100 user(s) are online (82 user(s) are browsing Forums)

Members: 1
Guests: 99

MickJT, more...

Support us!

Headlines






glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
While one of games i tring to port use Glew, i want to make glew works for me, and that what i do so far:

I get latest version of glew

As well as older aros port by Yannick as reference: here

Changes in the src/glew.c few bits (see on __amigaos4__ words) in a way how do Yannick on aros port.

There is changed file (as said check on __amigaos4__)

And compile it like this from the root:

Quote:

ppc-amigaos-gcc -DGLEW_NO_GLU -DGLEW_STATIC -O2 -Wall -W -Iinclude -c src/glew.c


It compiles fine, but once i trying to link that object with my project, i have:

Quote:

glew.o: In function `_glewInit_GL_ATI_vertex_array_object':
glew.c:(.text+0x644c): undefined reference to `glXGetProcAddressARB'
glew.c:(.text+0x6468): undefined reference to `glXGetProcAddressARB'
glew.c:(.text+0x6490): undefined reference to `glXGetProcAddressARB'
glew.c:(.text+0x64b0): undefined reference to `glXGetProcAddressARB'
glew.c:(.text+0x64d0): undefined reference to `glXGetProcAddressARB'
glew.o:glew.c:(.text+0x64f0): more undefined references to `glXGetProcAddressARB' follow


The glXGetProcAddressARB i define like this from aros-port sources:

Quote:

extern void ( * glXGetProcAddressARB (const GLubyte *procName)) (void);
#define glewGetProcAddress(name) (*glXGetProcAddressARB)(name)


Definately that no go for our old minigl , and we didn't have that function inside of our libgl.a , so, to put it simple, on what and how to change those 2 lines to make it all works. Thanks.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@All
Changed it as it done in blender sources:

Quote:

extern void ( * glXGetProcAddressARB (const GLubyte *procName)) (void);
#define glewGetProcAddress(name) (*glXGetProcAddressARB)(name)


On:

Quote:

#define glewGetProcAddress(name) MGLGetProcAddress(name)


It builds (through with warning "implicit declaration of function 'MGLGetProcAddress'", and when i link to that object with my project, its all happy crashes on the first glGenBuffers all, right after glewinit() successfully done. And stack trace exactly as i show in that thread. I.e. null pointer access in the instruction pointers, which mean that address of gl context still isn't here (imho).

Any ideas ? Linking like to game which want that glew are:

Quote:

# ppc-amigaos-gcc -o phlippe main.o game.o camera.o engine.o gfxconstants.o gradientrenderer.o interpolator.o levels.o mainscreen.o osinterface_sdl.o phlippler ootscene.o quad.o quadrenderer.o scenes.o settings.o textrenderer.o texture.o glew.o vertex.o -lSDL_image -lpng12 -ltiff -ljpeg -lSDL_mixer -lvorbisfile -lvorbis -logg -lmikmod_no_pthreads -lflac -lsmpeg -lSDL -lgl -lstdc++ -lz


_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Andy
Quote:

Did you actually open a GL context anywhere?


As i know GL context already here once i do SDL_SetVideoMode with SDL_OPENGL flag. That how it done in game:

int main(int argcchar **argv)
{
    
SceneManager_init(&phlipple_root_scene, &argcargv);
    return 
SceneManager_run();
}

void SceneManager_init(Scene *rootint *argcchar **argv)
{
    
destroyed 0;

    
scnMgr.current 0;
    
scnMgr.size 8;
    
scnMgr.scenes malloc(sizeof (Scene) * scnMgr.size);

    
scnMgr.scenes[scnMgr.current] = *root;
    
OS_init(argcargv);
}


void OS_init(int *argcchar **argv)
{
    
settings_load();
    
frameTime 1.0 / ((double) ENGINE_DEFAULT_FPS);

    
evts SceneManager_eventsInit();
    if (
SDL_Init(SDL_INIT_AUDIO SDL_INIT_VIDEO SDL_INIT_TIMER) < 0)
    {
        
fprintf(stderr"Could not initialize SDL:%sn"SDL_GetError());
        exit(-
1);
    }

    if (
Mix_OpenAudio(44100AUDIO_S1624096) < 0)
    {
        
fprintf(stderr"No audio: %sn"SDL_GetError());
    }
    else
    {
        
audioInitialized 1;

        
music_theme Mix_LoadMUS(OS_getFileName("PROGDIR:data/theme.ogg"));
        
music_success Mix_LoadMUS(OS_getFileName("PROGDIR:data/success.ogg"));
        
music_failure Mix_LoadMUS(OS_getFileName("PROGDIR:data/failure.ogg"));

        
snd_phlip Mix_LoadWAV(OS_getFileName("PROGDIR:data/phlip.ogg"));
        
snd_click Mix_LoadWAV(OS_getFileName("PROGDIR:data/click.ogg"));
        
snd_click2 Mix_LoadWAV(OS_getFileName("PROGDIR:data/click2.ogg"));
        
snd_buzz Mix_LoadWAV(OS_getFileName("PROGDIR:data/glitch.ogg"));

        
Mix_VolumeMusic(MIX_MAX_VOLUME);
    }

    
vi SDL_GetVideoInfo();
    
    
int bpp vi->vfmt->BitsPerPixel;

    switch (
bpp)
    {
    case 
16:
        
SDL_GL_SetAttributeSDL_GL_RED_SIZE);
        
SDL_GL_SetAttributeSDL_GL_GREEN_SIZE);
        
SDL_GL_SetAttributeSDL_GL_BLUE_SIZE);
        
SDL_GL_SetAttributeSDL_GL_DEPTH_SIZE16 );
        
SDL_GL_SetAttributeSDL_GL_DOUBLEBUFFER);
        break;

    case 
24:
    case 
32:
        
SDL_GL_SetAttributeSDL_GL_RED_SIZE);
        
SDL_GL_SetAttributeSDL_GL_GREEN_SIZE);
        
SDL_GL_SetAttributeSDL_GL_BLUE_SIZE);
        
SDL_GL_SetAttributeSDL_GL_DEPTH_SIZE16 );
        
SDL_GL_SetAttributeSDL_GL_DOUBLEBUFFER);
        break;

    default:
        
fprintf(stderr"This program requires at least 16bit display");
        exit(-
1);
    }

    
screen SDL_SetVideoMode(640480bppSDL_OPENGL SDL_RESIZABLE); 
    
width screen->w;
    
height screen->h;

    
char wmcapt[256];
    
sprintf(wmcapt"Phlipple ver %s"PACKAGE_VERSION);

    
SDL_WM_SetCaption(wmcaptwmcapt);
}


So at this point we already have GL context. Then second fucntion from main called (SceneManager_run() ):

int SceneManager_run()
{
    
//scnMgr.scenes[scnMgr.current].reshape(w, h);
    
return OS_mainLoop();
}

int OS_mainLoop()
{
    
GLenum err glewInit();
    if (
err == GLEW_OK)
    {
        
SceneManager_reshape(screen->wscreen->h);
        while(!
hasQuit)
            
gameLoop();
    }

    return 
EXIT_SUCCESS;
}


So glewInit(); called after we have GL context done by SDL, and then SceneManager_Reshape called which call quad_renderer_init, on first function of which (glGetBuffers) we have that crash.


Quote:

And where do you open mingl.library ?


Nowhere .. Should i open it manually ? I was in hope that if i use -lGL, then mglGetProcAddress will already use all the functions from automatically, just like on aros/gallium. I.e. if we already use opengl which are minigl , and we already use SDL with opengl flag, i somehow think there wasn't needs to open one more time minigl.library ?

But just in case, i add right at begining of main() that:

#include "scenes.h"
#include "phlipplescenes.h"
#include "settings.h"

int main(int argcchar **argv)
{

#ifdef __amigaos4__

    #include <proto/exec.h>
    
    #define MIN_MINIGLVERSION 2
    
    
struct Library *MiniGLBase;
    
struct MiniGLIFace *IMiniGL;

    
MiniGLBase IExec->OpenLibrary("minigl.library"MIN_MINIGLVERSION);
    if (!
MiniGLBase)
        return 
NULL;
    
    
IMiniGL = (struct MiniGLIFace *)IExec->GetInterface(MiniGLBase"main"1NULL);
    
    if (!
IMiniGL)
    {
        
IExec->CloseLibrary(MiniGLBase);
        
        return 
NULL;
    }
    
    
#endif


    
SceneManager_init(&phlipple_root_scene, &argcargv);
    return 
SceneManager_run();
}


Still same crash :( Or should i open it in some other place ? Maybe in glew.c itself ? (through in blender's sources you did't open it in glew.c). Damn, why all of this just didn't works automatically ?:)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:
The glXGetProcAddressARB i define like this from aros-port sources:

Quote:

extern void ( * glXGetProcAddressARB (const GLubyte *procName)) (void);
#define glewGetProcAddress(name) (*glXGetProcAddressARB)(name)


Definately that no go for our old minigl , and we didn't have that function inside of our libgl.a , so, to put it simple, on what and how to change those 2 lines to make it all works. Thanks.


That function is part of GLX which is the "OpenGL extension to the X windows system" (i.e., its specific to Linux). Likewise, wglGetProcAddress() is the WGL equivalent for Windows. Basically, each platform has its own specific API for interfacing between OpenGL and the rest of the GUI/graphics system.

The AmigaOS MiniGL equivalent is: mglGetProcAddress().

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Hans
Yep, in post #2 i already show that i use it, but still have crash once glGenBuffer is called after sdl/opengl context is created, and even manually open minigl.library (check post #3 for all info plz)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:
Yep, in post #2 i already show that i use it, but still have crash once glGenBuffer is called after sdl/opengl context is created, and even manually open minigl.library (check post #3 for all info plz)


MiniGL doesn't have glGenBuffers(), so you're trying to execute a NULL pointer.

The reason why you're getting a crash instead of a compile-time error, is that GLEW has created a glGenBuffers pointer, and attempted to get a pointer to the function via mglGetProcAddress(). Since it doesn't exist, it ends up being NULL.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

BTW, if you build and execute GLEW's glewinfo tool, then you'll get a list of which functions and extensions are supported, and which are not.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Hans
Quote:

MiniGL doesn't have glGenBuffers(), so you're trying to execute a NULL pointer.

The reason why you're getting a crash instead of a compile-time error, is that GLEW has created a glGenBuffers pointer, and attempted to get a pointer to the function via mglGetProcAddress(). Since it doesn't exist, it ends up being NULL.


Agrr :( you are right , i just do search in gl.h and there is no glGenBuffers at all. Also there is no glGenBuffersARB (which is older). Maybe you know how i can fast change code on something which will works on minigl, just without too much rewriting ? There is actual code:

Quote:

GLuint qvbos[2];

glGenBuffers(2, qvbos);


In whole game it uses like this about 5-6 times. Or maybe even faster will be to write some stub for that function which will works almost as intended ?

Quote:

BTW, if you build and execute GLEW's glewinfo tool, then you'll get a list of which functions and extensions are supported, and which are not.


Yep.. I just think before that if no extensions or functions not supported, mgl for extensions just skip them silency, but for functions will says something like "you have no such function".

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Hans
And as expected our minigl didn't have also glBindBuffers() and glDeleteBuffers() which game also uses everywhere. Seems some rewrite of game is need it , or just put it on hold if someday gallium with mesa will come.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 3369
@kas1e

Mate thanks for the try .. btw since these changes doesn't seem so huge and since Mesa/Gallium could take months (years ?) how feasible would be to just update MiniGL with the few features we need now ?

http://www.hyperion-entertainment.biz/svn/MiniGL/trunk/

   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

It wouldn't be hard to adapt code that uses glBindBuffers(). All you have to do is switch to vertex arrays. For example, taking the code at: http://sourceforge.net/p/phlipple/cod ... /trunk/src/quadrenderer.c

You would #ifdef out this section in quad_renderer_init():
glGenBuffers(2qvbos);

glBindBuffer(GL_ARRAY_BUFFERqvbos[0]);
glBufferData(GL_ARRAY_BUFFERsizeof(verts), verts,
                 
GL_STATIC_DRAW);

glBindBuffer(GL_ELEMENT_ARRAY_BUFFERqvbos[1]);
glBufferData(GL_ELEMENT_ARRAY_BUFFERsizeof(ind),
                 
indGL_STATIC_DRAW);


and replace the following in quad_renderer_begin():
glBindBuffer(GL_ARRAY_BUFFERqvbos[0]);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFERqvbos[1]);

glVertexPointer(3GL_FLOAT00);
glTexCoordPointer(2GL_FLOAT0, (void *)(12 sizeof(float)));


with:
glVertexPointer(3GL_FLOAT0verts);
    
glTexCoordPointer(2GL_FLOAT0, (void *)&(verts[12])));


Finally, render_quad() becomes:
glDrawElements(GL_TRIANGLES6GL_UNSIGNED_SHORTind);


Using #ifdefs to make the changes would enable switching back to using vertex/element buffers once they're supported.

EDIT: I forgot, you also need to remove the following in quad_renderer_destroy(): glDeleteBuffers(2, qvbos);

@samo79
Given the code changes outlined above, it would definitely be feasible to add glGenBuffers() and associated functions to MiniGL. The buffers would be emulated using vertex arrays; essentially doing what I outlined above. We won't get the performance improvements that can come from using vertex buffers instead of vertex arrays, but the code would run.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@Hans

Quote:

Using #ifdefs to make the changes would enable switching back to using vertex/element buffers once they're supported.


On second thoughts, a smarter move would be to check if glGenBuffers exists (using GLEW), and then use if/else. That way you wouldn't even have to recompile it when it does get supported.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Hans
Thanks ! Will try now

@Samo
That link on which you point out didn't have latest version. As i remember Karlos do some more work on minigl as well lately, and dunno if he update that repo (i assume no, as its all was work-in-progress). I write mail to him with asking about adding those 3 functions, just in case of luck :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Hans
Changes in quadrenderer.c helps, but the same kind of stuff uses in 4 more files: game.c, gradientrenderer.c, mainscreen.c and textrenderer.c.

While them seems the same easy, i still fail. For example in gradientrenderer.c, "verts" and "ind" are inside of one function and use params which passed to that function => so i can't just simple put away those arrays out of function and use later them for glVertexPointer/glColorPointer and co. And not only that, but they also use structures as offsets which have VBOs only.

I do not know, maybe better to make just stubs for that project (and lately can be added to minigl maybe)? I.e.

void glGenBuffers()
{
 ...
}

void glBindBuffer()
{
 ...
}
void glBufferData()
{
 ...
}
void glDeleteBuffers()
{
 ...
}



So no code changes need it, i just can add on linking that object with implemented functions, and no needs for mess with code.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Quote:
While them seems the same easy, i still fail. For example in gradientrenderer.c, "verts" and "ind" are inside of one function and use params which passed to that function => so i can't just simple put away those arrays out of function and use later them for glVertexPointer/glColorPointer and co. And not only that, but they also use structures as offsets which have VBOs only.


In that case, you should replace glGenBuffers() and glBufferData() with code to allocate buffers for those vertex and index arrays, and copy the data in. Then, replace glDeleteBuffers() with code to free the buffers again.

In the case of GradientRenderer, you would either change the type of its vbos field to an array of buffer pointers, or add a new field to store those pointers.

Quote:
I do not know, maybe better to make just stubs for that project (and lately can be added to minigl maybe)? I.e.


Simple stubs won't work because of code such as the following:
glBindBuffer(GL_ARRAY_BUFFERqvbos[0]);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFERqvbos[1]);

glVertexPointer(3GL_FLOAT00);
glTexCoordPointer(2GL_FLOAT0, (void *)(12 sizeof(float)));


Here, you bind buffers, and then set offsets within those buffers with glVertexPointer(), etc. Since these are called after glBindBuffer(), a simple stub won't work. For it to work, gl#####Pointer() would have to be aware of the bound buffers and switch to using the final parameter as an offset instead of a pointer.

So, either you change the game code, or you update MiniGL properly.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6445
@Hans
Thanks for help.

I know you already busy with everything, but if karlos works on minigl in some repo, maybe you can just add on top of his work those 4 functions ?:) Or even on latest public one, will be more than enough too (and later can be backported by him).

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2007/1/26 21:48
From New Zealand
Posts: 2310
@kas1e

Sorry, I don't have any time for working on MiniGL.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
   Report Go to top

Re: glew port: need some help
Home away from home
Joined:
2006/12/2 3:55
From Italy, Perugia
Posts: 3369
@kas1e

If i remember m3x was also involved, maybe you can try to contact him aswell

   Report Go to top

Re: glew port: need some help
Quite a regular
Joined:
2013/10/17 16:21
From Hungary
Posts: 647
I decided to add fake VBO support to MiniGL. Fake in the sense that functions above will be implemented (and some more), but there won't be any speed benefit using them over plain vertex arrays, because the buffers will be stored in the system memory instead of the VRAM. This can be changed later if Warp3D receives vertex buffer support.

_________________
I see the jimmies have been rustled.
   Report Go to top





[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project