Simple texture loading with DevIL revisited

I wrote an article a while back about loading images to use as textures in OpenGL, and in it I’d written my own single line image to texture-handle function because I couldn’t get the built-in ilutGLLoadImage function to work. Since I’ve been getting blank looks and failure to compile reports about it, I thought I’d go and take a look at it again, and this time ilutGLLoadImage seems to work just fine, so let’s document it up properly shall we?


You will need:

  • A C++ compiler of your choice (I prefer Code::Blocks)
  • Working OpenGL drivers
  • A copy of DevIL
  • A copy of GLEW (GL Extension Wrangler – to make the functionality in your OpenGL drivers availble for use)
  • A copy of GLFW (GL FrameWork – to quickly and easily set up a OpenGL context)
  • An image to load

Preparation and libraries

Create a new project in your IDE of choice, and link in the following libraries:
DevIL required libraries

You’ll have to figure out where the libraries are on your own system but these are where they are on mine, where a /usr/local/ address indicates packages I’ve build myself, /usr/lib/ indicates standard system installed packages, and no prefix uses any paths defined by the compiler (in this case /usr/ where the lib and include directories are assumed). I’ve also added /usr/local/ to the include path so that any headers in /usr/local/include/ are picked up before any in /usr/include. Yes, library paths are a pain ;)

Also, be sure that your project includes its own directory as the working directory (i.e. the directory to be in when executing) so that you can place your image (in this example, a file called abstract-image.jpg) in the main project directory and it’ll be picked up when we try to load it. The way that you specify the working directory will vary depending on the IDE you’re using, but in Code::Blocks you set it from Project | Properties | Build targets like this:

Code::Blocks Working Directory

Source Code

Create a new project with source code something like this:

End Result

If you’ve linked in the libraries and used source code like the above, you should end up with a working texture that looks something like this:
ilutGLLoadImage Example

And information regarding the image being used that looks something like this:
DevIL Image Data

I’ve attached a copy of my Code::Blocks project here for anyone who wants it.


Credits: The wallpaper I used as the texture in this guide is Life by N.Design Studio, which you can find here.

Single-Call OpenGL Texture Loader in DevIL

I’ve been playing around with the DevIL image loading library today, and it has a command to load an image and assign it to an OpenGL texture in one fell swoop like this:

Only I’m damned if I could get it to work, through I could take the long route and get DevIL to load/bind textures just fine, so I went and wrote my own version of ilutGLLoadImage, which works wonderfully =D

OpenGL DevIL Image Loader

Here’s the code:

This means that if I had a picture called SpringLandscape.jpg in the same folder as my code, I could bind it to a texture like this:

Ha! I’m getting the hang of this coding lark… =P

Here’s some complete example code to get you up and running: DevIL-Image-Loader.cpp

Update 11/2010: I had a think about this the next day and decided I wanted the best quality filtering available (which is MipMaps using the GL_LINEAR_MIPMAP_LINEAR function), so to do this you can replace lines 51 to 53 with:

And then straight after the glTexImage2D statement, add this line:

You’re going to have to abide by that caveat though and use GLEW or something to make the extension available to you, I’d suggest putting something like this into your code immediately after initialising your OpenGL context:


Update 09/2011: To use any DevIL functionality in your C++ project, you need to link in libIL, libILU and libILUT (in that order), and then initialise DevIL before you use it with:

You either have to specify your renderer before or after initialisation, and I don’t know which, so I just call it twice and don’t worry about it. If you know definitively whether it should be called before or after the il/ilu/ilut initialisation calls then share the wealth, bubba ;)