I feel like such a noob about a question such as this, but maybe I've missed something altogether. I just started up with GLFW and started reading through the reference material, playing around to see how it all worked, and I came to a screeching halt the second I attempted any image related functions. With something as simple as glfwReadImage, it fails to load my image. Said image is a 256x256 targa, so it should comply to my understanding, but I may have missed something big elsewhere beside the code, perhaps a compiler setting I might be missing that's neglecting to include the location of where to start looking for files (currently said image is located within the same folder as the source code). I'm not exactly sure what I need to provide to help you help me, so if I miss something here, let me know. I'm using MinGW within CodeBlocks, and CodeBlocks is fairly new to me as well (been using Dev-C++ for a long time prior). The code that I'm using is the generic template that CodeBlocks creates w/ the added lines to attempt to load the image into memory: [Edited by - Cyntalan on July 22, 2008 8:36:00 PM]

Did you use debugger to watch what happens? Is the .tga compressed? Is it of a correct type that GLFW supports? I would start with just a simple RGB 24bit .tga file first and see if that works?

Quote:Original post by MARS_999
Did you use debugger to watch what happens? Is the .tga compressed? Is it of a correct type that GLFW supports? I would start with just a simple RGB 24bit .tga file first and see if that works?

I step-by-stepped in debug mode to track it, but I'm not sure exactly how to follow through the image load function within the GLFW library to find where in the function it's dropping the ball. I do know the image is failing to load into memory. The targa image was a straight open/resave in GIMP from a basic bitmap, so I would have thought that part would have been straight forward, but when I get home from work, I will give a straight-up saved targa instead, but if I can get some insight on how to track the process from within a library (or if that's possible), that would help me (hopefully) find the problem.

Would just edit, but to those that have read, it needs a bump, so I'll just post again.

Tested with a fresh TGA, same problem.

Sorry for another bump, but I would like to add another piece of information that might help. I brought the project into VC++ 2008 Express and had no problems, so I'm thinking this is more a CodeBlocks problem than anything else. I just have no idea what.

Another bump for another piece of information that catches me as weird. If I build the project, then drop said targa into the same folder as the executable then run the executable built, it runs fine. It's only when I attempt to run it from CodeBlocks (be it by Debug or Run) that it refuses to load the image into memory.

In project properties->build targets, you will see something called "Output filename" which will have something like ".\debug\mygame.exe". Change it to ".\mygame.exe" and it will work fine.

The problem is that you are not giving the absolute path of the image. Giving the filename as "font.tga" will make the exe file search the same directory in which it is present for the image. Giving it like "/images/font.tga" will make it search the "images" folder which is in the folder of the exe.

So for the purpose of loading images for CodeBlocks to understand it requires the full path for this particular function, but for the standalone executable, it doesn't? That seems slightly confusing.

Basically, what I have is the targa in the debug folder as well as in the project folder. Running debug/run from CodeBlocks nets me a failure unless I put the full path, but running the debug build outside of CodeBlocks regardless of its location so long as the targa is in the same folder gives me success. Shifting the location in where it's building the final executable didn't seem to make a difference. My problem seems to be not where the executable is created, but how I run that executable. Whatever configuration that is making that perform different is what I'm not sure is incorrectly configured.

Found the solution, and it was something I figured to be rather simple in CodeBlocks to fix, so I figured I'd end this along with a post of my solution.

The solution was found in the project options. Under the build targets tab is a value for the "execution working dir", which (for me) defaulted to MinGW's bin directory. Changing this to simply "." allowed CodeBlocks to work from the relative file location rather than requiring a full path. Note that since this was merely for the project options in CodeBlocks, this made it so the executable run on its own did what it was supposed to and work with relative file paths.