Singleton issues

[ooohYeah]

I test with GL_LINE and that show me everything but what I expected!
I think there is an issue during the process of datas as you said.
I did'nt test the final output values, but how to do that?

You are right for the 'upside down' rendering, probably caused by the viewport.

Thanks CE!
Regards.

[CrazyEddie]

I did'nt test the final output values, but how to do that?

I don't know I'm not sure it's possible, which is why I suggested the wireframe test.

[ooohYeah]

Ok thanks I will try!

[ooohYeah]

It seems that the there are issue when the object are more than 2 primitives ( more than 6 vextices).
Because when I attempt to draw window such as staticImage, that works. But when it is framewindow, the coordonates go everywhere!

[CrazyEddie]

Wow! That's certainly interesting!!

I'm going to have to think about this a bit and perhaps do some research and some tests in order to better understand the potential causes of such an issue.

CE.

[ooohYeah]

Thanks CE!
I keep looking for a solution!

Regards.

[ooohYeah]

Hi CE!
I glad to said that it works (ok almost works)!

The was in the appendGeometry method and in the way I stored vertices informations (textures, data etc.). With my implementation of OpenGL ES I couldn't store vertices in vector objects. I used static array because dynamic array didn't works!

The other issue (except the upside down and FBO and scale issues )I had now is about textures: I don't know how to switch textures when there is more than 1 texture using by a GeometryBuffer object (for instance where there text in a window (as you can see on the picture)!

I wondered something: Is it possible to implement a 3d effect such as a 'cubic desktop' like compiz?



Thanks CE!
Regards

[CrazyEddie]

Wow, very cool that you are making progress here

To know when to change texture, you need to keep track of when the texture gets changed and manage the per-texture batches in a manner of your choosing. The texture gets set via GeometryBuffer::setActiveTexture. In that function you might have a system to track the per-texture batches. i.e. if the texture is changing to a new one, keep track of this texture and the offset into the vertex buffer of start of this batch, when you later render the geometry buffer, rather than submitting the entire vertex buffer wholesale, you instead iterate over the batches in a way similar to:

Code: Select all

while (more batches)
    set texture for this batch
    submit geometry for this batch
end

In the OpenGL renderer we handle it slightly differently but the general idea is exactly the same.

With regard the the 'cubic desktop' type effects, this is theoretically possible, but you need some kind of support for rendering to texture to achieve it (which is what we need the FBO support for ).

HTH

CE.

[ooohYeah]

Ok thanks for your help CE! Happy to know that!

For now I'm trying to make fbo works! I checked extensions supported with glGetString(GL_EXTENSIONS), and I support GL_EXT_Framebuffer_object and GL_ARB_Framebuffer_object.

So I forced TextureTargetFactory to use OpenGLFBOTextureTarget, but when it initialises (initialiseRenderTexture()), an exception saying that there is an reading access violation occured when glGenFramebuffers is executed. Maybe I enable some array or matrix that make it crached?

Regards

[CrazyEddie]

Hmmm. I think this is GLEW related. When not using glew you might normally use some function or other to get pointers to the extension functions so that they can be called, since we use GLEW this is supposed to be handled for us. Since your GLEW version does not know about the FBO extension, it likely results in the glGenFramebuffers function pointer being zero or at least not pointing to a real function.

HTH

CE.

[ooohYeah]

Ok ok.
But that seems weird because when I use glGenFramebuffers (or other framebuffer functions), in OpenGLBaseApplication.cpp, it has an address.
Moreover, "my glew" implement glGenFramebuffers :

Code: Select all

...
glGenFramebuffers = (pfn_glGenFramebuffers)get_proc_address("glGenFramebuffersEXT");
...


It is as if extensions were not load while it is already done in the OpenGLBaseApplication.cpp when I create the context.

Regards

[CrazyEddie]

Sorry to ask such a question, but are you initialising GLEW via glewInit() ?

CE.

[ooohYeah]

In fact no because my "customized" glew doesn't implement glewInit') but implement a function that loads extensions (things such as "glGenFramebuffers = (pfn_glGenFramebuffers)get_proc_address("glGenFramebuffersEXT");") and that is called at the creation of the context. Maybe I should call it back in function initialiseGLExtensions() of CEGUIOpenGLRenderer?

I will test it!

Thanks CE!

PS: get_proc_address is just a wglGetProcAddress.

[ooohYeah]

Huum. I didn't managed to 'reload' extensions, c++ issues (didn't recognize the fonctions). I will retry later.

In fact I notice something: all windows created using Falagard are located at position (0,0), while logo for example (created in BaseApplication file) is located at the right place.
Weird because vertex prositions are good.

[CrazyEddie]

I'm not sure what's going on there with the positioning. Though the Logo is not a window but rather a geomerty buffer that we use to draw the logo and FPS directly. So given this, it seems that the window locations are not getting set to the geometry buffer objects correctly (issue in the geometry buffer code?).

CE.