If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

More than one CL_FrameBuffer and gc.set_map_mode()

A post-process compositor can involve more than one CL_FrameBuffer that can be used both as render target or as texture source.

When more than one CL_FrameBuffer is involved in that process if I not call gc.set_map_mode(cl_map_2d_upper_left) each time before rendering to a CL_Framebuffer I lose the map mode and I have strange results on display.

To solve the problem without using gc.set_map_mode(cl_map_2d_upper_left) I can call gc.reset_frame_buffer() after each time I render to a CL_Framebuffer.

Is this normal ?
When I started to develop my CompositorManager I thought that I could call gc.reset_frame_buffer() only one time before drawing my post-process final result to the screen but I now I'm calling this function each time I draw to a Cl_FrameBuffer.

The way its supposed to work (but sounds on your description there's a bug) is that when you set a mapping mode, this one remains active until you change it, regardless of frame buffers set active and so on.

However, there are two exceptions to this rule:

If you set the map mode to custom, the automatic mapping code will not make any adjustments needed (since the application now control the modelview matrix)

If you change the projection or modelview matrices using custom OpenGL. Generally this is not safe unless you set the map mode to custom, since ClanLib may change the projection and modelview matrices when changing the active framebuffer

The reason a reset()+set() of a framebuffer fixes the mapping mode is because ClanLib reapply its settings to the projection and modelview matrices. It is a bug if you need to do this. The bug is in ClanLib if you did not do any custom OpenGL matrix operations. But if you did do custom OpenGL you may be able to fix the problem by properly restoring the matrices after the OpenGL code, or by first switching to the custom mapping mode and then back to 2D mapping afterwards.

The reason ClanLib reapply the mapping mode on framebuffer changes is because the coordinate system in OpenGL starts in the lower left corner, while our mapping defaults to the upper left. This means that if the height of the frame buffer changes, we have to adjust the matrices to the new height.

Thank you for your explanation.
Unfortunately in my code I never changed the projection or modelview matrices using custom OpenGL and the only projection I use is cl_map_2d_upper_left at the moment.

The reason ClanLib reapply the mapping mode on framebuffer changes is because the coordinate system in OpenGL starts in the lower left corner, while our mapping defaults to the upper left. This means that if the height of the frame buffer changes, we have to adjust the matrices to the new height.

I think that something wrong happens when I write to a framebuffer from a framebuffer.

I would have to say that something strange happens to my map mode when I draw a texture,that was previously used as color attachment of a framebuffer, to a color attachment of another framebuffer.

Example:

1) Framebuffer 1 has a color attachment called "MyTexture1"
2) I draw something to "MyTexture1" with one shader.
3) Framebuffer 2 has another color attachment called "MyTexture2"
4) I draw "MyTexture1" to "MyTexture2" with some post-process shader applied for example.
5) I draw "MyTexture2" to the screen

If I'm not wrong if in the passage 4 I don't call gc.set_map_mode(cl_map_2d_upper_left) I will have an inverted image in the final window.

I have no idea what that image depicts, but it sure looks cool. What project are you working on?

Thank you. Currently I'm only working on the game engine but the image tests belong to the first project I want to develop after the engine will be more mature.

The name of the game will be SupaMix and it's a remake of a famous old boulderdash-like game: Supaplex.

I started some year ago to think about it. Before discovering ClanLib I started to develop the engine in real 3D with Ogre but I found that this type of games are still better in 2D and with shaders you can give a fake 3D effect with a better performance. Currently ClanLib in its 2.x version is the only library that I found to be such complete..you think about something that you need..and it has it!

Before discovering ClanLib I started to develop the engine in real 3D with Ogre but I found that this type of games are still better in 2D and with shaders you can give a fake 3D effect with a better performance.

Just a note to say that ClanLib 2.0 can do real 3D. I have written an application where you fly around a huge landscape (10km^2) where the landscape (scene) and objects were created in Lightwave3D. All using ClanLib 2.0 API (no direct OpenGL calls).