• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lonesock

SOIL: new lightweight image loading lib

130 posts in this topic

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
0

Share this post


Link to post
Share on other sites
How much work do you think it would be to add functions for loading images from raw data?

I'm asking as I'm implementing my game's data file access using physfs, which means I need to extract the file's raw data into a char[] before I can do anything with it. I know stb_image has functions for loading from data, but it looks like SOIL keeps the filename around through most of the process.
I'll have a look to see if I can find an easy way to abstract the back end from whether the input type, but I'm doubting it's going to be trivial.

Thanks.

EDIT: I guess I could just use stb_image myself to convert the image data and then call SOIL_create_OGL_texture =)

[Edited by - DeathCarrot on August 29, 2007 5:36:49 AM]
0

Share this post


Link to post
Share on other sites
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 ;-)
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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.




0

Share this post


Link to post
Share on other sites
Quote:
Original post by shotgunnutter
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.

Great, thanks! I have 0 access to any Mac machines, so thanks for verifying it at least compiles [8^)

Quote:
Original post by shotgunnutter
Many thanks for an excellent library.

You're welcome! Feel free to hit me with any suggestions or requests for making it better.
0

Share this post


Link to post
Share on other sites
Looks like a very interesting library, I'll have to try it out when I get home :). D3DX-esque texture loading for OpenGL, yay!

I, too, am using PhysFS, so being able to load from a custom file source would be great. :)

Good work.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by DeathCarrot
How much work do you think it would be to add functions for loading images from raw data?

Quote:
Original post by cow_in_the_well
I, too, am using PhysFS, so being able to load from a custom file source would be great. :)

Ah, sorry I misunderstood you earlier, DeathCarrot. As you saw, stb_image already supports decoding images from a block of RAM, so this feature will not be too hard to implement. I'll add in the interface to decompress images from memory as I upgrade to stb_image 0.98, so expect the next SOIL release in a few days.

Thanks so much for your feedback!
0

Share this post


Link to post
Share on other sites
Quote:
Original post by lonesock
Quote:
Original post by shotgunnutter
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.

Great, thanks! I have 0 access to any Mac machines, so thanks for verifying it at least compiles [8^)

Quote:
Original post by shotgunnutter
Many thanks for an excellent library.

You're welcome! Feel free to hit me with any suggestions or requests for making it better.


Your library is so easy to use that I would like to rate you up again, if only I hadn't done so twice already.

Ok, initial tests on my MBP running OS X 10.4.10, and gcc 4.0.2 are successful. I can load .tga files, and .bmp files. I haven't yet tested screen shots, I'll do that next.

Here is an OS generated screen shot from my quake 3 clone:



























OK, I cheated. Here is what I actually managed to do:



I'm writing my own renderer; My code at the moment is the result of a year of reading tutorials and copy / pasting code from examples on the web. The class which handles the MD2 character also renders him. Thanks to your library, I can now design a better system far more quickly.


I did have to make a change to the compiler macros in soil.c, to ensure platform cross- compatibility:

in soil.c, where you have

#ifdef _MSC_VER
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#endif

#include "SOIL.h"
#include "stb_image.h"
#include "image_helper.h"

#include <stdlib.h>
#include <string.h>
#include <GL/gl.h>

// for using DXT compression
#define SOIL_RGB_S3TC_DXT1_EXT 0x83F0
#define SOIL_RGBA_S3TC_DXT1_EXT 0x83F1
#define SOIL_RGBA_S3TC_DXT3_EXT 0x83F2
#define SOIL_RGBA_S3TC_DXT5_EXT 0x83F3







i changed this to


#ifdef _MSC_VER

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <GL/gl.h>
#else
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#endif

#include "SOIL.h"
#include "stb_image.h"
#include "image_helper.h"
#include <stdlib.h>
#include <string.h>

// for using DXT compression

#define SOIL_RGB_S3TC_DXT1_EXT 0x83F0
#define SOIL_RGBA_S3TC_DXT1_EXT 0x83F1
#define SOIL_RGBA_S3TC_DXT3_EXT 0x83F2
#define SOIL_RGBA_S3TC_DXT5_EXT 0x83F3







This will allow the code to compile on gcc 4.0.2 and on MSC. I haven't tested it on a Linux system but the headers are the same as for OS X.

[update: png files work. Alpha transparency on .tga and .png also works]

[Edited by - shotgunnutter on September 5, 2007 11:31:27 PM]
0

Share this post


Link to post
Share on other sites
hey good library but i was solwed image loading problem.
so we need a 3d image loader like 3ds or any other.

can you do that.
but anyway i dont need it but dds support is good.
i can use your source for this.
but i like open source things.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by RSC_x
hey good library but i was solwed image loading problem.
so we need a 3d image loader like 3ds or any other.

can you do that.
but anyway i dont need it but dds support is good.
i can use your source for this.
but i like open source things.


Why not write your own?
0

Share this post


Link to post
Share on other sites
Hi, All.

SOIL has 2 updates:
* it can now handle some non-compliant DDS files (which did not specify a pitch or linear size)
* it can now decompress images from memory for you PhysicsFS users (note, this is mostly untested, especially the DDS direct upload version...I'd really appreciate any feedback!)

@shotgunnutter: Thanks for the heads-up regarding the includes. I think the includes you mentioned were from a previous version, would you mind testing the latest version? If there are still issues I'd be happy to make changes [8^)

@RSC_x: I'm not sure I understood. Are you requesting that SOIL be able to load DDS files with 3D (volume) textures in them? Or are you looking for some mesh-loading libraries with licenses similar to Public Domain? (if so, there are many libraries out there, like Trimeshloader...I recommend checking this list as a first step).
0

Share this post


Link to post
Share on other sites
Quote:
Original post by lonesock

@RSC_x: I'm not sure I understood. Are you requesting that SOIL be able to load DDS files with 3D (volume) textures in them? Or are you looking for some mesh-loading libraries with licenses similar to Public Domain? (if so, there are many libraries out there, like Trimeshloader...I recommend checking this list as a first step).


Nobody except me and a few other people understand RSC_x. he was asking you could write him a loader for a 3d model format, and gave .3ds as an example.
I told him to write his own.
0

Share this post


Link to post
Share on other sites
@shotgunnutter: Thanks for the clarification. Quick question, did the new includes work for you on your various platforms?

Has anybody tried SOIL with PhysicsFS? I'd like to verify that it works, or fix it in the other case [8^)
0

Share this post


Link to post
Share on other sites
Hi. The library is looking good so far. Thanks!

I'm having a small problem, though, and I was hoping you could point me in the right direction. I'm using VS.NET 2003, have the project linked to libSOIL.a, and the file in question includes SOIL.h. When I build the project, the following linker error comes up:

error LNK2019: unresolved external symbol _sqrtf referenced in function _compute_color_line_STDEV

The error goes away when I comment out the SOIL_load_OGL_texture_from_memory line. Are there any other libraries I need to link to or settings I need to change to get it working? The code for the function in question is below.

Thanks a lot!

const unsigned int getTexture(string fileName) {
PHYSFS_File* filePtr;
int fileLength;
unsigned char* imageData;
unsigned int textureID;
map<unsigned int, PNTexture>::iterator textureIter;

textureIter = loadedTextures.begin();
while (textureIter->second.fileName != fileName) {
textureIter++;
}

if (textureIter != loadedTextures.end()) {
textureIter->second.refCount++;
textureID = textureIter->first;
}
else {
filePtr = PHYSFS_openRead(fileName.c_str());
fileLength = PHYSFS_fileLength(filePtr);
PHYSFS_read(filePtr, imageData, 1, fileLength);

textureID = SOIL_load_OGL_texture_from_memory(imageData, fileLength, 0, 0, NULL);
if (textureID > 0) {
loadedTextures[textureID].fileName = fileName;
loadedTextures[textureID].width = 320; //TODO: Read the dimensions from the data file, along with the
loadedTextures[textureID].height = 320; //texture coordinates for each tile
loadedTextures[textureID].refCount = 1;
}
PHYSFS_close(filePtr);
}

return textureID;
}
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Davian_
Hi. The library is looking good so far. Thanks!
...
I'm using VS.NET 2003, have the project linked to libSOIL.a, and the file in question includes SOIL.h.

Thanks! When using VS.NET 2k3, I'd recommend linking against one of the MS compiler generated *.lib files. (The libSOIL.a file is meant for the MinGW compiler.) I'd try SOIL_vc7.lib first to verify that it works.

If that doesn't fix the issue, I'd try including "math.h" in that same source file and try doing a "temp = sqrtf( temp );" and see if that causes any problems.
0

Share this post


Link to post
Share on other sites
Hi. Switching to SOIL_vc7.lib produces the following errors:

error LNK2019: unresolved external symbol _convert_image_to_DXT1 referenced in function _SOIL_internal_create_OGL_texture
error LNK2019: unresolved external symbol _convert_image_to_DXT5 referenced in function _SOIL_internal_create_OGL_texture
error LNK2019: unresolved external symbol _save_image_as_DDS referenced in function _SOIL_save_image

It doesn't seem that there is any difference in including math.h or not, and using a function like sqrt() does not cause an error.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Davian_
Hi. Switching to SOIL_vc7.lib produces the following errors:

error LNK2019: unresolved external symbol _convert_image_to_DXT1 referenced in function _SOIL_internal_create_OGL_texture
error LNK2019: unresolved external symbol _convert_image_to_DXT5 referenced in function _SOIL_internal_create_OGL_texture
error LNK2019: unresolved external symbol _save_image_as_DDS referenced in function _SOIL_save_image

It doesn't seem that there is any difference in including math.h or not, and using a function like sqrt() does not cause an error.

Hey, as it turns out, I'm a moron! In the VS projects I forgot to include the DXT code. And in VS2k3 I can use sqrt(), but not sqrtf(), so I'll make the changes to the code, recompile everything, and upload the new version by tonight. Thanks so much for finding and reporting these errors!
0

Share this post


Link to post
Share on other sites
Quote:
Original post by lonesock
...so I'll make the changes to the code, recompile everything, and upload the new version by tonight...

I ran into a small problem. I'm trying to have just a single one of the compiled libraries for MS compilers in the distribution. The VC6 version of the lib is now working with all MS compilers. The 2k3 version of the lib is unfortunately the largest. The 2k5 version of the lib is the smallest & fastest, so I wanted to use that, however when I try to use it with 2k3 I get an error about ftol2_sse not being defined.

So I have uploaded the fixed (for MS compilers) version of SOIL with the VC6 version of SOIL.lib. If anybody knows what I should be doing to get 2k5 to compile without the _sse version of the function, I'll update the "one true lib" to using the 2005 compiler's version. I will update the website documentation after I've ironed all this out, but at least the current version should get you up and running, Davian_!

thanks for you patience, everybody.
0

Share this post


Link to post
Share on other sites
I've uploaded a new version of SOIL:
* upgraded to stb_image version 1.00
* only including 1 prebuilt library file (libSOIL.a) which works for MinGW and Microsoft compilers (including VS 2003)
* added the DXT source files to the MS projects so you can recompile the lib if you wish
* updated the Usage section of the SOIL website with an example of SOIL_load_OGL_texture_from_memory

Please let me know if the new version works for all'y'all. Thanks so much for testing SOIL and reporting problems.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by shotgunnutter
This will allow the code to compile on gcc 4.0.2 and on MSC. I haven't tested it on a Linux system but the headers are the same as for OS X.


I thought I'd let you know: the headers definitely aren't the same. The OpenGL headers are in a GL/ directory on most UN*X-like systems. Mac OS X is an exception.
0

Share this post


Link to post
Share on other sites
I just used swig to translate soil.h for FreeBasic. I don't really know enough about ogl to really use it yet, but by plugging it into some FB ogl examples I was able to verify that libSOIL.a does work when linked statically in FB.

''
''
'' soil -- header translated with help of SWIG FB wrapper
''
'' NOTICE: This file is part of the FreeBASIC Compiler package and can't
'' be included in other distributions without authorization.
''
''
#ifndef __soil_bi__
#define __soil_bi__
#inclib "SOIL"

enum
SOIL_LOAD_AUTO = 0
SOIL_LOAD_L = 1
SOIL_LOAD_LA = 2
SOIL_LOAD_RGB = 3
SOIL_LOAD_RGBA = 4
end enum

enum
SOIL_CREATE_NEW_ID = 0
end enum

enum
SOIL_FLAG_POWER_OF_TWO = 1
SOIL_FLAG_MIPMAPS = 2
SOIL_FLAG_TEXTURE_REPEATS = 4
SOIL_FLAG_MULTIPLY_ALPHA = 8
SOIL_FLAG_INVERT_Y = 16
SOIL_FLAG_COMPRESS_TO_DXT = 32
SOIL_FLAG_DDS_LOAD_DIRECT = 64
end enum

enum
SOIL_SAVE_TYPE_TGA = 0
SOIL_SAVE_TYPE_BMP
SOIL_SAVE_TYPE_DDS
end enum

declare function SOIL_load_OGL_texture cdecl alias "SOIL_load_OGL_texture" (byval filename as zstring ptr, byval force_channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_load_OGL_cubemap cdecl alias "SOIL_load_OGL_cubemap" (byval x_pos_file as zstring ptr, byval x_neg_file as zstring ptr, byval y_pos_file as zstring ptr, byval y_neg_file as zstring ptr, byval z_pos_file as zstring ptr, byval z_neg_file as zstring ptr, byval force_channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_load_OGL_single_cubemap cdecl alias "SOIL_load_OGL_single_cubemap" (byval filename as zstring ptr, byval face_order as zstring ptr, byval force_channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_load_OGL_texture_from_memory cdecl alias "SOIL_load_OGL_texture_from_memory" (byval buffer as ubyte ptr, byval buffer_length as integer, byval force_channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_load_OGL_cubemap_from_memory cdecl alias "SOIL_load_OGL_cubemap_from_memory" (byval x_pos_buffer as ubyte ptr, byval x_pos_buffer_length as integer, byval x_neg_buffer as ubyte ptr, byval x_neg_buffer_length as integer, byval y_pos_buffer as ubyte ptr, byval y_pos_buffer_length as integer, byval y_neg_buffer as ubyte ptr, byval y_neg_buffer_length as integer, byval z_pos_buffer as ubyte ptr, byval z_pos_buffer_length as integer, byval z_neg_buffer as ubyte ptr, byval z_neg_buffer_length as integer, byval force_channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_load_OGL_single_cubemap_from_memory cdecl alias "SOIL_load_OGL_single_cubemap_from_memory" (byval buffer as ubyte ptr, byval buffer_length as integer, byval face_order as zstring ptr, byval force_channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_create_OGL_texture cdecl alias "SOIL_create_OGL_texture" (byval data as ubyte ptr, byval width as integer, byval height as integer, byval channels as integer, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_create_OGL_single_cubemap cdecl alias "SOIL_create_OGL_single_cubemap" (byval data as ubyte ptr, byval width as integer, byval height as integer, byval channels as integer, byval face_order as zstring ptr, byval reuse_texture_ID as uinteger, byval flags as uinteger) as uinteger
declare function SOIL_save_screenshot cdecl alias "SOIL_save_screenshot" (byval filename as zstring ptr, byval image_type as integer, byval x as integer, byval y as integer, byval width as integer, byval height as integer) as integer
declare function SOIL_load_image cdecl alias "SOIL_load_image" (byval filename as zstring ptr, byval width as integer ptr, byval height as integer ptr, byval channels as integer ptr, byval force_channels as integer) as ubyte ptr
declare function SOIL_load_image_from_memory cdecl alias "SOIL_load_image_from_memory" (byval buffer as ubyte ptr, byval buffer_length as integer, byval width as integer ptr, byval height as integer ptr, byval channels as integer ptr, byval force_channels as integer) as ubyte ptr
declare function SOIL_save_image cdecl alias "SOIL_save_image" (byval filename as zstring ptr, byval image_type as integer, byval width as integer, byval height as integer, byval channels as integer, byval data as ubyte ptr) as integer
declare sub SOIL_free_image_data cdecl alias "SOIL_free_image_data" (byval img_data as ubyte ptr)
declare function SOIL_last_result cdecl alias "SOIL_last_result" () as zstring ptr

#endif




*edit*

Is there a function to get the pixel width and height of the image?

[Edited by - Merick Zero on September 21, 2007 9:39:32 PM]
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Merick Zero
I just used swig to translate soil.h for FreeBasic. I don't really know enough about ogl to really use it yet, but by plugging it into some FB ogl examples I was able to verify that libSOIL.a does work when linked statically in FB.

*** Source Snippet Removed ***

*edit*

Is there a function to get the pixel width and height of the image?

Awesome! Do you mind if I include this file in the SOIL distribution zip?

As to getting the image size, you have 2 options:
1) use the OpenGL function glGetTexLevelParameter (see here) once the texture object is bound (which it is right after a call to SOIL's upload functions)
2) use a 2-step process where you call SOIL_load_image and get the image data (including size), then call SOIL_create_OGL_texture with the image data you just loaded.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by lonesock
Awesome! Do you mind if I include this file in the SOIL distribution zip?


Sure thing. After all, all I did was just run it through the FB version of swig to get a machine translation. -- And as such, it should be noted that all the functions should be tested with FB to make sure that there are no glitches in the translation (I actually only tested one function, SOIL_load_OGL_texture). I'd do it myself, but as I said before I'm still trying to figure out opengl and it'll probably be a while before I can really do anything with it.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0