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:
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.
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:
char wmcapt[256];
sprintf(wmcapt, "Phlipple ver %s", PACKAGE_VERSION);
SDL_WM_SetCaption(wmcapt, wmcapt);
}
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->w, screen->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:
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 ?:)
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 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)
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.
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".
@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.
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 ?
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.
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.
@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 :)
@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.
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:
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.
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).
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.
This is just like television, only you can see much further.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
