Further, none of this needs to be there during image load:


Also, mikey is doing GLUT right now, so the UIKit image loading facilities aren't available anyway.

Quote:Also, please hoist the line that sets GL_TEXTURE_MIN_FILTER to occur before the call to glTexImage2D. It is correct either way, but setting the min filter before creating texture level 0 may allow GL to operate more efficiently.

Great tip Frogblast, I've never heard that before! ... although I always have it above anyway.

Thanks everyone again.

JohnCMurphy, that tutorial sounds right up my street, could you please give me a link when you're finished?

Thanks, Frogblast, I made the changes you recommended.
The code comes from Apple's GLSprite sample code, and I think the reason they are enabling blending there is because they don't want to enable it if the image fails to load.

johncmurphy Wrote:The code comes from Apple's GLSprite sample code, and I think the reason they are enabling blending there is because they don't want to enable it if the image fails to load.

No, that would make absolutely no difference at all. The reason they enabled it there is because OpenGL operates as a state machine and they only have one texture in the demo, and so it's just convenient to enable it once when they load it. That particular instance of enabling it after loading the texture should be completely ignored as a prototypical procedure of when to enable/disable blending. And it definitely doesn't operate on a per-texture basis, so it shouldn't even be associated with the loading code -- just pretend those three lines aren't even in between the braces of the if(image) block. You should only enable blending when you need it. Enabling after a texture load is just a waste of a call.

Just imagine using that generic code to load 24 textures. That would be 24 calls to glEnable(GL_TEXTURE_2D)/glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)/glEnable(GL_BLEND) which would have essentially no effect, other than to waste CPU cycles.

If you happen to know that your application uses blending for all textures and needs it to be enabled all the time, then you could call those three functions once during init, but certainly not after loading each texture.

I'm coming in late here, but I want to throw out my personal favorite, SOIL:

http://www.lonesock.net/soil.html

It's small, easy to use, and generally OK. Plus, it will gladly load textures with an alpha channel without premultiplying them.

Ah yes, thanks for the SOIL reminder. I had forgotten to check that out in the past. Very nice, and in the public domain too! Looks like the only minor drawback I see off the top is that it doesn't save out to compressed formats.

Quote:I'm coming in late here, but I want to throw out my personal favorite, SOIL:

http://www.lonesock.net/soil.html

It's small, easy to use, and generally OK. Plus, it will gladly load textures with an alpha channel without premultiplying them.

Hmm... looks good! I was using unknowns 'Image loader' but that was too slow. JohnCMurphy's code looked promising, but I'm a bit of a beginner, really.

I think I will use SOIL until I can write my own image loader.

Thanks again.

EDIT:

I add libSOIL.a and that works, but when I #include <SOIL.h> it doesn't find it. ???

AnotherJake Wrote:Ah yes, thanks for the SOIL reminder. I had forgotten to check that out in the past. Very nice, and in the public domain too! Looks like the only minor drawback I see off the top is that it doesn't save out to compressed formats.

SOIL's a little limited -- I think it doesn't support progressive JPEGs, for example. But I only use PNGs and DDSs, so that limitiation isn't a problem. And, yeah, it doesn't save to compressed, which is too bad. But, for my uses it's not a problem.

Regarding mikey's problem:

Quote:I add libSOIL.a and that works, but when I #include <SOIL.h> it doesn't find it. ???

When you use angle brackets in your include, GCC will expect to find the header in one of the global include paths, such as /usr/local/include. You'll want to copy SOIL.h there.

TomorrowPlusX Wrote:You'll want to copy SOIL.h there.

Ack, no! Doing that makes your project require a particular system installation in order to compile. As much as possible, you'll want to try to keep everything that doesn't come by default on the system contained in your project directory, so that you can simply check it out onto any Mac with developer tools installed and be able to build it out-of-the-box. So, I'd suggest putting it in one of your user-defined search paths and using double quotes instead of angle brackets to include it.

ThemsAllTook Wrote:Ack, no! Doing that makes your project require a particular system installation in order to compile. As much as possible, you'll want to try to keep everything that doesn't come by default on the system contained in your project directory, so that you can simply check it out onto any Mac with developer tools installed and be able to build it out-of-the-box. So, I'd suggest putting it in one of your user-defined search paths and using double quotes instead of angle brackets to include it.

I agree -- I was just trying to keep it simple

unknown Wrote:I've made a tool for putting images into C source code for OpenGL.

You can do that really easily in the GIMP—when you go to save an image, select "C source code" from the "Select File Type" box. You could probably do that (using the GIMP) with a script—I can recall an article in Linux Journal to that effect.

Here are my favourite ways to load textures:

- PPM files. I have a simple loader based on code from one of Edward Angel's books. The code is here, in Laboration 1:

http://www.computer-graphics.se/TSBK07.html

- JPEG files. My preferred way to load JPEGs is using libjpeg. Interface code for that is also in the link above.

- TGA files. Easy to load, supports transparency. I can post a loader if you wish.

I used to use QuickTime for loading textures in the past, but my old loader code uses QuickDraw GWorlds so I'd have to rewrite it, so instead of spending X time to get into Apple's increasingly complex APIs I spent X/10 time for the above solutions, which are much simpler and cross-platform.

Quote:- TGA files. Easy to load, supports transparency. I can post a loader if you wish.

Hmmm. I will maybe look into these at a later date. They sound right up my street.

Quote:You can do that really easily in the GIMP—when you go to save an image, select "C source code" from the "Select File Type" box. You could probably do that (using the GIMP) with a script—I can recall an article in Linux Journal to that effect.

Cool. I have a copy of GIMP (An unfortunate name) and I'll maybe use that feature for small images, like the HUD. Save loading times, eh?

TGA is a really bad idea. Use PNG instead.

For a little perspective on why TGA stinks: http://www.idevgames.com/forum/showpost....ostcount=5

AnotherJake Wrote:TGA is a really bad idea. Use PNG instead.

For a little perspective on why TGA stinks: http://www.idevgames.com/forum/showpost....ostcount=5

To be precise, your argument is poor compression ratios, right? Of course 700 vs 1600 is a good argument, but only if compression ratio is the only thing that counts. The same goes for PPM, but in terms of simplicity, PPM and TGA are winners. It would be interesting to see a comparison on loading times. I am pretty sure what happens if I compare implementation time.

Quote from the link above: "So, don't use TGA format. Ever." What an overstatement! It is a nice and simple format, the simplest format I know that supports transparency. And it solves the problem. Solve the problem first, optimize when needed.