Problem with displaymode switching

[Nicolas Lelong]

Hi,

don't know if this will help, but I saw that, in the code you posted, you never do the following:

From MSDN:[B]
Before calling EnumDisplaySettings, set the dmSize member to sizeof(DEVMODE), and set the dmDriverExtra member to indicate the size, in bytes, of the additional space available to receive private driver-data.

In my experience, not doing such initializations lead to wierd bugs ...

[Michael Steinberg]

Nicolas: Thanks!!!
That seems to be the thing, I think, because the is the only thing I see that is actually buggy. But if so, why do I actually get the correct screen settings. Well, win is a bit weird sometimes, so I'll try that!
See ya!

[Michael Steinberg]

Well, it has not been the problem. There was a bug somewhere, but I didn't find it.
So, what everyone would do, I decided to simply recode that stuff. It works really nice now. Thanks for all of your support.

I've got another question now, sorry.
I've got some virtual "windows", the position and the size given.
So I do a:

glViewport( x,y, width, height );

after that:

glOrtho( 0, width, 0, height );

Shouldn't I get pixel precise lines like that:

glTranslatef( 0.5, 0.5, 0 );
 
glBegin( GL_LINES );
   glVertex( 0, width-1 );
   glVertex( height-1, width-1);
glEnd();

I end up not getting cool loking shaded buttons, because the lines aren't as long as they should be, what do I make wrong?
Thanks!

[mcraighead]

Your lines are actually starting at the _corners_ of pixels in that case. You'll be at the whim of floating-point inaccuracies.

You should add 0.5 to the coordinates as appropriate.

To draw a 1-pixel point at the pixel (x,y), you draw a point at (x+0.5,y+0.5).

To draw a 1-pixel-wide line between (x1,y) and (x2,y) that is inclusive of both x1 and x2, you draw a line from (x1,y+0.5) to (x2+1,y+0.5).

To draw a rectangle from (x1,y1) to (x2,y2) that is inclusive of both corner points, you draw a rectangle from (x1,y1) to (x2+1,y2+1).

To start a bitmap or DrawPixels rectangle at the pixel (x,y), set your raster pos to (x+0.5,y+0.5).

Think about the way primitives get sampled (center of pixel rectangle) and this will all make sense.

This is why glVertex2i and glRasterPos2i are evil.

- Matt

[Michael Steinberg]

Uhmm, that sounded hard...
Oh, I used that glTranslate(0.5,0.5,0) Matt!
Shouldn't do that the trick to move the vertices to the center?

[Michael Steinberg]

Oh well, it wasn't hard, sorry...
Uhmm, if I follow you correctly, I need to include the complete starting and ending pixel of the line in order to draw them correctly. I always thought, that if a line starts in the center of a pixel (which I was actually doing), that pixel will also be drawn, same applies to the ending. Why that difference between lines and vertices?

[mcraighead]

Pixel-exact line drawing (AA lines or non-AA lines, either way), by the way, is considered a rather high-end workstation feature. Be warned.

Imagine the line as a quad. You're starting the quad at the center of the pixel. So the sample is on the edge of the primitive, and whether you'll draw it or not will be essentially random based on precision issues.

This is not a perfect analogy because lines aren't quads (though AA lines are very similar to quads), but it should work.

I strongly urge anyone trying to get pixel-exact lines across all HW (especially consumer HW) to actually use a quad in the app instead. And make sure the centers of the pixels you want fall _entirely inside_ the quad, ideally by a half-pixel.

- Matt

[mcraighead]

Also, OpenGL-compliant line hardware can include the start or end, but not both. Consider a line strip. If it included both, you'd get a double hit. 1-pixel-wide lines are not allowed to have double hits.

For more information, you will have to read the OGL spec. I am not an expert on the aliased line rasterization rules by any means. I do know the rules for points and triangles and for AA lines, though.

- Matt

[Michael Steinberg]

Thanks Matt.
I think I'm gonna use textured quads, where the texels will exactly fall onto the pixels, if you know what I mean. It's also easier to change the look of my in-game windows...