I prefer to use the minimum libraries as possible, so did the whole treatment of windows and events handling using the native windows API.

In this case I was practically forced to use the ' glew ' because the OpenGL extensions are not provided by windows "gl.h" header ( I dont know if its the same thing in Mac or Linux).

Now I'm running into a problem trying to load images. While I'm working with BMP file format that's fine ( I wrote my own function to load BMP data ). However loading images from other formats ( PNG , TGA , JPG , etc ) is not so simple.

In this case I realize that running from third-party libraries will not work. So , I wonder what would be the most appropriate libraries to use with OpenGL ( 3.0 + ) .

I've seen setups using "SDL + OpenGL", "SFML + OpenGL" , "GLFW + OpenGL" or a mix of it all .

So, what would be a good 'toolbox' to a simple OpenGL project??

for example:

Window and Event handling : SDL, GLFW, SFML

Mathematics : GLM

Uploading Photos : DevIL

Charging Models : Assimp

ps: I did some research in this forum, but I don't find recent topics about it... the newest I found was dated from 2006... so I think that a new topic was necessary...

For math, use GLM unless you're not using C++ or know you absolutely need something a different library uses. GLM seems as close to universally used as anything gets in OpenGL.

For Windows handling, I'd recommend SDL or SFML (not GLFW). Probably SDL if you're more C-like in your coding, and SFML if you're more OO.

For extensions, I'm using GLLoadgen since I prefer a c/h pair of files instead of an entire library and all that. It doesn't matter what you use though, they just use different init functions and then are the same.

For images, don't use DevIL. It's not maintained, so you'll run into trouble whenever you deviate from "normal" at all. You can use ResIL which branched off of it if you want basically the same thing. You can use libPNG like tons of people do. You can use stb_image if you prefer the simple c/h pair of files again. Once an image is a texture, you don't care how it got there though. So it doesn't really matter which image library you use as long as it works.

For models, I'd think that's more personal preference than anything. You can even load by hand pretty easily, although there's no reason to bother.

I like FreeImage for loading images (DevIL is nice too but less features), and glew is basically must-have. glm seems nice but I don't have hands on experience. SDl is generally pretty decent and adds a lot of useful core functionality. On the other hand, I found that Assimp seemed to have a lot of bugs and both GLFW and SFML seem dicey to me.

I used GLFW for a month. Ive found at least 3 annoying bugs and things that were done in a very unprofessional way. Like it didnt choose the proper window mode(WS_POPUPWINDOW / WS_POPUP) and my FPS dropped considerably. The input handling was also weird.

There is no reason not to use GLM, it's very good and it is made to go with OpenGL.

I've had no issues with GLFW3. In fact it is my favorite window and context creation library because it is very light weight and does exactly one thing, unlike a lot of the other libraries which try to do everything.

I've had better luck with the FreeImage library, but I would recommend you use it for creating your asset tools. For your actual texture assets you are probably going to be wanting to store things like mipmaps and compressed texture data, so you are better off using a custom texture file format and leaving FreeImage out of your game engine.

Same goes with Assimp. There is no reason to be loading your game models in your game engine from a format like Collada or any other format that requires parsing. Your game engine should be using a custom format that is ready to go.

There is no reason not to use GLM, it's very good and it is made to go with OpenGL.

I've had no issues with GLFW3. In fact it is my favorite window and context creation library because it is very light weight and does exactly one thing, unlike a lot of the other libraries which try to do everything.

I've had better luck with the FreeImage library, but I would recommend you use it for creating your asset tools. For your actual texture assets you are probably going to be wanting to store things like mipmaps and compressed texture data, so you are better off using a custom texture file format and leaving FreeImage out of your game engine.

Same goes with Assimp. There is no reason to be loading your game models in your game engine from a format like Collada or any other format that requires parsing. Your game engine should be using a custom format that is ready to go.

I disagree. GLFW has MANY bugs.. I ran into enough that I just gave up on it.

And as for assimp, I use assimp in my engine because my engine supports modding and I want modders to be able to load any file type that they want. Think of an engine like Unity. If it used a special format, no one would use it because it would be to complicated to convert EVERY model to the proprietary format.

I disagree. GLFW has MANY bugs.. I ran into enough that I just gave up on it.

I hope you reported those bugs, so that they can be fixed. I haven't ran into any thus far.

And as for assimp, I use assimp in my engine because my engine supports modding and I want modders to be able to load any file type that they want. Think of an engine like Unity. If it used a special format, no one would use it because it would be to complicated to convert EVERY model to the proprietary format.

Unity is more than a game engine, it is a game engine and a advanced editor. There is absolutely no logical reason that the engine needs to be loading models from a number of different textual file formats. Have your assimp support built into the editor, so your modders can load assets to their heats content, and have that editor convert them to a binary representation specific to your engine, that way when someone actually distributes a game it can load the assets quickly. People don't like long loading times, and that is exactly what you will get if the engine has to parse every single model from a text or XML file.

I hope you reported those bugs, so that they can be fixed. I haven't ran into any thus far.

I did report the ones I found. My fear, however, is that there are many that I HAVEN'T yet found.

With as many bugs as you are likely to encounter with OpenGL drivers, I wouldn't worry too much about them. Just report them when you encounter them, and hopefully they will be ironed out. GLFW is growing in popularity and it is becoming more streamlined.