Make Square Fill Entire Window

Hello,

How do I determine what transforms I need to make a square fill an entire window in modern OpenGL? Say for example I have an 800 x 600 window and the coordinates with the vertices of two triangles extending from -1 and 1. Without any type of transformation, these coordinates would fill an 800 x 600 window because OpenGL's coordinates extend from -1 to 1. What if I want to use a standard MVP transformation, though? How do I determine what needs to be done in order to fill an entire window. Consider this code:

with the same coordinates. I would now get a square somewhere in the middle of the window. Assuming I do not change the projection matrix, what changes would need to be made to the View and Model matrices? I understand the matrix math, but not how it relates to window coordinates themselves.

So you want to fill the whole window with a e.g. rectangle in 3D, so that its projection covers the whole [-1, -1 .. 1, 1] screen?

For this, you could take a look at gluUnProject. With this, you could calculate the un-projected near and far coordinate of every corner of the screen, and interpolate a line between them, calculating the coordinate that suits your depth.

What exactly are you trying to accomplish? Maybe there's an easier way that does neither require projection nor un-projection.

€dit: I just read that you want modern openGL... but that doesn't exclude the above method, you can just do the matrix transformations yourself, they're not so difficult once you understood them

I am trying to make a very simple side-scrolling game; I want to fill the background with a textured shape. The rectangle is made and the texture is applied, but my problem is with positioning. When I begin to add sprites, I'd like to know how to position them in relation to the window itself. If I don't use any type of MVP matrix, then the coordinates will all be from -1 and 1, making it difficult to precisely place things. Is there no way I can place things like how I described using a typical MVP matrix?

Tell you what: I'm doing exactly the same thing right now, and it looks like this:
(the floor in the red blocks is temporarily invisible.)

All you need for this is:

The screen's size should be a power of two, so the texture is not blurred (aliased) anywhere. This way, the other parameters can be chosen in a way that can be fully stored in a float (e.g. not 0.1, that doesn't store well) and you get no (or only few) drawing artefacts (like unwanted lines between the objects).

You can transform the drawing space, putting the origin to the bottom left by subtracting (1, 1) from everything you draw. The top right will then be (2, 2) so you need a factor 2 to even this out if you want the screen to cover exactly one square.

Use no kind of matrix, that's unnecessary. If you want to add an offset if your player moves to the right, simply define a global offset vector that you add to all what you draw. The background gets the offset/2, so it appears to be moving slower than the player.

You can transform the drawing space, putting the origin to the bottom left by subtracting (1, 1) from everything you draw. The top right will then be (2, 2) so you need a factor 2 to even this out if you want the screen to cover exactly one square.

If I subtract (1,1) from everything I draw, what if I had something at (-1, -1)? Then wouldn't this become (-2, -2)? I though that the coordinate system ranges from -1 to 1 so that something at (-2, -2) wouldn't draw. Furthermore, how does (2,2) exist considering the coordinate system with a range of only [-1, 1] Can you please explain?

Imagine the standard openGL window [-1, -1 .. 1, 1]. Placing objects in here is not very intuitive if you want the origin (0, 0) to be at the bottom left corner. So you subtract (1, 1) from everything you draw, moving the origin (0, 0) to the bottom left corner (-1, -1) and resulting in a now visible window [0, 0 .. 2, 2]. This offset is static, but you can of course add other offsets to further move the window. For example, if the player moves right, you add an additional (1, 0) so the window will be [1, 0 .. 3, 2] or if he jumps, you could add (0, 2) so the window will be [0, 2 .. 2, 4] (both times, the origin is no longer in the window). A consequence of this (and also your goal) is drawing only a certain number of objects, namely those that lie in the window. In a side scroller, you will rarely move to the left, so everything with an x-coordinate smaller than 0 (taking the offset into account) won't ever be drawn. If you want it to be drawn, just reverse the x-direction of the offset. If it's still unclear, I could prepare some graphics for you

Imagine the standard openGL window [-1, -1 .. 1, 1]. Placing objects in here is not very intuitive if you want the origin (0, 0) to be at the bottom left corner. So you subtract (1, 1) from everything you draw, moving the origin (0, 0) to the bottom left corner (-1, -1) and resulting in a now visible window [0, 0 .. 2, 2]. This offset is static, but you can of course add other offsets to further move the window. For example, if the player moves right, you add an additional (1, 0) so the window will be [1, 0 .. 3, 2] or if he jumps, you could add (0, 2) so the window will be [0, 2 .. 2, 4] (both times, the origin is no longer in the window). A consequence of this (and also your goal) is drawing only a certain number of objects, namely those that lie in the window. In a side scroller, you will rarely move to the left, so everything with an x-coordinate smaller than 0 (taking the offset into account) won't ever be drawn. If you want it to be drawn, just reverse the x-direction of the offset. If it's still unclear, I could prepare some graphics for you

It's starting to make more sense. I understand the concept (I think) , but in terms of application I don't understand how I would implement it. I still don't see how the window's new coordinates surpass [1,1].