Well, Ive just read the header file and was astonished to find that it supports loading and saving files, and can automaticaly generate a screenshot. I'll definitely be using this for the next few days. Good Job!

ye lonesock its becoming more and more interesting, keep up the good work!

@ speciesUnknown & ForestMaster: thanks!

Updated SOIL a bit:
* now has the SOIL_CREATE_NEW_ID enum in SOIL.h (as shown in the usage examples)
* can now load uncompressed DDS files (directly which will preserve MIPmaps, or via stb_image which will ignore the MIPmaps, then regenerate them if requested)

The next thing I'm going to implement is loading cubemaps from single image files. This would include DDS cubemap files, and also any other format where the width is 6x the height (or vice versa). This way you could stitch together your 6 265x265 cubemap faces side to side into a single 1536x256 texture, or vertically to form a 256x1536 texture, then save it as png/jpg(make sure that your image size is a multiple of 8 so the jpeg blocks don't cross image boundaries)/dds(ditto, but multiples of 4)/whatever.

I'd like to just add a flag to SOIL_load_OGL_texture(), SOIL_FLAG_SPLIT_CUBEMAPS. This way SOIL would automatically split any image texture where the width is 6x the height and load it as a cubemap. Here's my question...does that make sense to everybody, or should I introduce a new function (SOIL_load_OGL_single_cubemap() or similar)? I'm not sure which way would be more intuitive.

Please cast your votes!

P.S. this version of the zip only has the library built with MinGW and VC2k5 Express...the VC6 and VC2k3 versions will have to wait till I get back to work. But the project files are still there, so you can easily perform the build if necessary.

Quote:Original post by lonesock
I'd like to just add a flag to SOIL_load_OGL_texture(), SOIL_FLAG_SPLIT_CUBEMAPS. This way SOIL would automatically split any image texture where the width is 6x the height and load it as a cubemap. Here's my question...does that make sense to everybody, or should I introduce a new function (SOIL_load_OGL_single_cubemap() or similar)? I'm not sure which way would be more intuitive.

Please cast your votes!

you can make two functions with the same name:

that can work either this way

or this way


so you have one function 'name' only that can work ordinarily without specifying the flag or using the cubemap if the last parameter is added
similarly you can make 2 versions of the soil load ogl cube map function

and you have two different definitions of the function, the one with one char* prameter only will have to be split.
hope its clear

forest

Quote:Original post by bubu LV
ForestMaster: I think author is making SOIL as C not C++ library. So function overloading is not available.

oh what a pity :D in this case id vote for the separate function

Quote:Original post by DeathCarrot
How much work do you think it would be to add functions for loading images from raw data?
...I guess I could just use stb_image myself to convert the image data and then call SOIL_create_OGL_texture =)

That works [8^)

Also, the newest version of stb_image allows you to register your own file-loader. If you can wait till this weekend I should be able to upgrade SOIL by then to use the newest version, and the DDS loader will be implemented using that interface, so there should be a decent bit of example code.

In other news, the single file to cubemap function is almost done...I just need to read DDS cubemaps...so that should be out this weekend too (thanks for casting the deciding vote, ForestMaster ;-)

SOIL can now load cubemaps from a single image file, either a DDS cubemap or any other image type with the six cube faces stitched together. It can now handle uncompressed DDS files too.

Sorry to anyone who downloaded SOIL between yesterday afternoon and now, I had a temp version up with some bugs, fixed now.

I really appreciate everyone who has tested SOIL, thanks for trying it out. Has anyone tried compiling SOIL under OS X?

Quote:Original post by lonesock
SOIL can now load cubemaps from a single image file, either a DDS cubemap or any other image type with the six cube faces stitched together. It can now handle uncompressed DDS files too.

Sorry to anyone who downloaded SOIL between yesterday afternoon and now, I had a temp version up with some bugs, fixed now.

I really appreciate everyone who has tested SOIL, thanks for trying it out. Has anyone tried compiling SOIL under OS X?

HI,

I've got SOIL compiling under OS X on gcc 4.2. I'm going to test the different file format loaders, and will probably use calls to these functions in my resource loader library.

Many thanks for an excellent library.