The two setups you are both talking about, ortho(-0.5,w-0.5,-0.5,h-0.5), vs. ortho(0,w,0,h) followed by translate(-0.5,-0.5,0), both create identical projection matrices. If you don’t believe me, use glGet to check. So, I would say they’re equally “hack-y”, which is to say, not at all hack-y. It’s what you need to do to get the results you want and it’s the only way to do it within the defined functionality. How can you call that a hack?
As to if using ortho by itself or ortho + translate is more hacky than the other, well that’s silly. There are many ways to specify matrices in OpenGL. The options are available for you to use the one you’re most comfortable with. For some people, that’s constructing a matrix by hand and passing it in with glLoadMatrix. For others, it’s passing the final params in to ortho, and for yet others, it’s passing basic params in to ortho and using matrix manipulation calls to adjust it until it’s right. None of this is a hack.
Specifically, sections 3.4.1 (line rasterization) and 3.5.1 (polygon rasterization). Or for a more recent version (in PDF format), take a look at the OpenGL 2.1 spec at:
You could have made your life much easier when considering what the formulas are for a 1x1 viewport.
For that you setup an ortho exactly on the corners of that single pixel: gluOrtho2D(0, 1, 0, 1), that’s it, not fudge factors, nothing.
For pixel aligned rendering of filled geometry you run on coordinates on corners of pixels, so simple integer coordinates, e.g. glRecti(0,0,1,1).
For lines rendering the diamond exit rule applies, so you need to run on pixel centers, that is your integer coordinates + 0.5 sent as float.
Same for points, render on pixel centers.
That’s all folks.