Kamujin's picture

Fliping Screen Origin

I am making a lot of progress on my GUI port.

I am somewhat stuck on one issue and I'd like to hear what you all think about it.

In OpenGL, the Y axis is inverse relative to most GUI coordinate systems that I've used. In other words, the Y values get larger as you move from the bottom of the screen to the top.

Most GUI systems use the top left as the origin (0,0) for widget locations.

Obviously, I need to make an adjustment somewhere to account for this. My question is where? My current choices seem to be.

1) Build the whole system with a bottom-left origin. As this is most native, I would think things like mouse picking and gui events would be the simplest and fastest to compute.

2) Build the GUI system with a top-left origin and convert the coordinates when I construct the vertex arrays.

3) Build the GUI system with a top-left origin and convert the coordinates in a shader.

Is there an established "best practice" for this?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

Well, I'm eager to learn more about GL and have no card that supports the instancing extension, thus the question.

The problem with uniforms is that the driver has to figure out in which registers to stuff them. Built-in uniforms are known to it and thus are minimal work. OpenGL itself will also calculate several derivations from your application's projection and modelview matrices for internal operation, and exposes them 'for free' in GLSL (most important: gl_NormalMatrix and gl_ModelViewProjectionMatrix, but it also has a dozen inverses and transposes of them).

I don't think you can override GL's internal calculation of those matrices, so might aswell use them for your purposes (i.e. gl_NormalMatrix will be defined - even if you use uniforms - but it will be only considering the last GL state you had set before drawing - not your custom matrix).

Kamujin's picture

Yeah, but I can always just switch over to using the built in uniforms. Its too early for me to worry about that kind of optimization. I am just trying to learn as much as I can first.

Kamujin's picture

Here is a screenshot of the current state of my GUI port.

http://www.robotechmmo.com/image/Screen43.png

Inertia's picture

Looks promising, you should really consider adding it to the personal projects section of the forum, the rules should be interpreted that any project - that is beyond sketch-on-paper state - is welcome and completeness is not a requirement. It's quite interesting to see it grew and take a look at your initial steps, in half a year or so.

Kinda have to disagree with you that using builtin matrices is an optimization, on the contrary I think that using uniforms over them is a premature optimization. In my current renderer it works like this (ignoring materials and sorting here to keep it straightforward):

GL.MatrixMode( Projection );
GL.LoadTransposedMatrix( Camera.ProjectionMatrix );
GL.MatrixMode( ModelView );
GL.LoadTransposedMatrix( Camera.ViewMatrix );
foreach ( Model m in Scene )
{
  GL.PushMatrix();
  GL.MultTransposedMatrix( m.ModelMatrix );
  Draw();
  GL.PopMatrix();
}
Kamujin's picture

I don't feel like losing an argument with you over a topic that you clearly know better.

So, I'll just say that this is how my code looks with my helper classes. Maybe it will make things somewhat clearer without going into the implementation details.

            GL.ActiveTexture(TextureUnit.Texture0);
            GL.BindTexture(TextureTarget.Texture2D, handleTexture);
 
            positionTextureShader.Use();
            positionTextureShader.SetMatrix("modelViewProjection", modelViewProjection);
            positionTextureShader.SetSamplerUniform("sampler0", 0);
 
            PositionTexture.Draw(beginMode, vertexData);
Inertia's picture

I'm not saying that my approach is the ultimate solution, there's always a choice ... in fact for the UI your solution is quite viable. Just trying to warn you that using uniforms will lead to problems (in fact some optimizations rely on passing variables through gl_ state uniforms to remove the driver work of finding appropriate registers). Looking at the scope of your project it could be quite a bit of work changing the design at a later stage.