Question about handling non power-of-two bitmaps

[Malarkey]

Okay, I've finally decided to buckle down and start learning how to use OpenGL for a 2D game that I'm working on. Now, I know that when you load a bitmap file to use as a texture map, it has to be a power of two and that this limitation can be worked around by various means. I've been scouring the message board, tutorials, and source code and it pretty much looks like the way to go with this is to:

- Load a bitmap with non power-of-two dimensions and determine the smallest POT square that will contain it.
- Allocate a new block of memory with those dimensions and copy the bitmap data into it.
- Keep track of the original width and height and use texture coordinates to only use the section that's actually the bitmap.

Is this correct? I've also read that you can use gluBuild2DMipmaps to handle bitmaps with a non-POT size but the caveat is that it stretches the bitmap to fit within a POT square.

[Josh]

If your target is fairly recent computers (with Radeons and up), then you don't need to worry about the POT restriction.

[OneSadCookie]

"don't need to worry" is misleading -- you can use EXT_texture_rectangle, which lifts the power-of-two restriction but imposes some more of its own, but TEXTURE_2D textures are still limited to power-of-two. On GeForce 6-class hardware you don't need to worry -- when ARB_texture_non_power_of_two is supported, which it isn't yet on the Mac.

Malarkey -- what you've said is fine, and the only way to go if you want to support Rage 128s. If you don't care about Rage 128s and don't mind EXT_texture_rectangle's restrictions, that's probably an easier way to go.

[arekkusu]

I've been scouring the message board, tutorials, and source codeSee also the real documentation on the old (http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt) and new (http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of_two.txt) extensions that handle NPOT textures.

[AnotherJake]

See also the real documentation...
"See" being the operative term here. You have to be arekkusu or OSC to actually comprehend it! :p (yes, I admit, reading plain text files in a web browser confuses me)

[arekkusu]

The language used in the specifications can take some getting used to. But so does, say, C.

[AnotherJake]

arekussu, C does not look like this:
There is no additional procedural or enumerant api introduced by this
extension except that an implementation which exports the extension
string will allow an application to pass in texture dimensions for
the 1D, 2D, cube map, and 3D targets that may or may not be a power
of two.

... actually, I take that back. C does indeed look very much like that. Which begs the question:

Why are programmers allowed to write in English? They aren't very good at it...

[arekkusu]

Yes, I agree that the specifications can be hard to understand. They are highly technical and use very long winded wording. But this is necessary because the things being described are complicated and every detail has to be spelled out.

What I meant was: similar to how you, the programmer, must invest some time and energy in order to learn a programming language and all of the details and side effects therein, you must also invest time and energy in reading and understanding the OpenGL documentation if you want to make the most of OpenGL. Nobody said it would be easy. OpenGL is pretty complicated ;)

But consider this-- would you rather have very verbose and detailed documentation written by programmers, or simple documentation that glosses over the details, written by people who don't understand the technology they are documenting?

[w_reade]

There's a trick to learning useful things from the specifications, which took me a while to work out, so it might be worth sharing. It's actually quite a simple procedure, and it goes as follows:

1) Open the specification :rolleyes:.

2) Read it until your eyes glaze over -- certainly the "Overview" section and the first few "Issues", but then stop reading at the first real "WTF?" moment.

3) Go directly to the "New Procedures and Functions" section. If it's a big spec, it might be quite a long way away, so search raher than scroll ;).

4) Start reading again. Skim this section and the following "New Tokens", and then settle down to properly read the various "Additions to..." sections; these will tell you what you need to know to start actually doing things.

5) Do some coding.

IMO, the Issues section is rather a cruel trap: it starts off like a nice simple FAQ, and then suddenly metamorphoses into an arcane Hardly-Ever-AQ which leaves the newcomer feeling distressed and inadequate :sneaky:, and likely to go back to google in search of richer pickings elsewhere.

Oh, and there's another cunning trap: if you try to search the specs for terms like GL_FOO_BAR or glFooBarParam3fARB, you won't find them. You need to lop the "GL_" prefix off constants, and the "gl" prefix off functions; you should probably also remove any part of the function name after the format wart*, to be sure that you aren't missing any information that belongs to your family of functions (so GL_FOO_BAR becomes FOO_BAR, and glFooBarParam3fARB becomes FooBarParam ).
* there's probably a better name for those bits like "3fv" and "2f" and "4ub" which specify the parameters the function takes, but I don't know it. Anyone?

Anyway, once you've avoided the Issues landmine and learned how to navigate, you can try to understand the information you actually need. This might be tricky, and it will of course be in "technical" language, but it's a doddle compared to ploughing one's way through 30K of Issues without really knowing what they mean, or how (or if) they will affect you ;).

[Malarkey]

Cool. Thanks for the responses, guys. Well, at least about the informative stuff and not the debate over technical documentation. :)