Jump to content

  • Log In with Google      Sign In   
  • Create Account


SOIL: new lightweight image loading lib


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
130 replies to this topic

#101 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 23 May 2008 - 11:59 AM

Quote:
Original post by syndicatedragon
If anyone is interested, I've packaged the SOIL library as a MacOSX framework. Looking forward to an update, especially size reporting!


I would like that. I am still using a beta version of the library, and it has not failed me yet, however I had to make some changes to make it compile on GCC. An OS X framework would be great.


Sponsor:

#102 syndicatedragon   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 May 2008 - 09:15 AM

Here's a link. It's built as a universal binary, and as "private" framework i.e. it's intended to be copied into the app bundle.

I only have 10.5 machines so I don't know if it works with 10.4. It *should*, but I haven't tested it.

http://shodanproductions.com/misc/SOIL/SOIL_framework_20071110.dmg

#103 JMNightmare   Members   -  Reputation: 122

Like
0Likes
Like

Posted 20 September 2008 - 03:45 PM

Quote:
Original post by syndicatedragon
... size reporting!
What is size reporting? Like size in bytes?

Anyways great library, and quite efficient I may add. =]


#104 muster   Members   -  Reputation: 151

Like
0Likes
Like

Posted 14 October 2008 - 08:55 PM

nice library you have, i managed to fix the problem with loading the texture in soil.

#105 lonesock   Members   -  Reputation: 799

Like
0Likes
Like

Posted 15 October 2008 - 06:39 AM

Quote:
Original post by JMNightmare
Quote:
Original post by syndicatedragon
... size reporting!
What is size reporting? Like size in bytes?

Sometimes SOIL resizes the image on load (if the card needs a power-of-2 size, for example). There have been requests for SOIL to report the original size of the texture as it was loaded, before any manipulation (and/or an easy way to just determine what was the size of the texture that was loaded). I've had a pretty busy few months, but I'm getting some free time again, so development of SOIL is back on. Thanks for your patience everybody!

#106 lonesock   Members   -  Reputation: 799

Like
0Likes
Like

Posted 15 October 2008 - 06:39 AM

Quote:
Original post by muster
nice library you have, i managed to fix the problem with loading the texture in soil.

Thanks! Glad you got it working!

#107 MrPhil   Members   -  Reputation: 122

Like
0Likes
Like

Posted 19 January 2009 - 08:57 PM

Thanks for the library! It is wonderful!
Mr. Phil Games - Download Computer Game

#108 EzraBC   Members   -  Reputation: 122

Like
0Likes
Like

Posted 03 February 2009 - 08:43 AM

Hey,

Thank you for an awesome library, first of all. Unfortunately for me, it seems that no matter what I tweak, I invariably receive the following errors:

1>libSOIL.a(stb_image_aug.o) : error LNK2019: unresolved external symbol __alloca referenced in function _stbi_zlib_decode_noheader_buffer
1>libSOIL.a(image_helper.o) : error LNK2019: unresolved external symbol _sqrtf referenced in function _RGBE_to_RGBdivA2

I know I am most likely missing a .lib file but after extensive searching online I have found no resolutions to this problem. Any help would be greatly appreciated.

Thank you in advance,
Ezra

#109 MatthewBurk   Members   -  Reputation: 122

Like
0Likes
Like

Posted 07 February 2009 - 02:51 PM

I had the same linking errors trying to use libSOIL.a with VC9. I fixed it by builiding a new SOIL.lib from the included VC9 project. This also increased the size of the library x 4.

#110 Khaos Dragon   Members   -  Reputation: 196

Like
0Likes
Like

Posted 10 February 2009 - 05:43 PM

I've modified soil to support saving uncompressed dds images and fixed bugs with it not being able to distinguish with ARGB8888 and ABGR8888 in its saving and loading of uncompressed dds files.

Additionally I have added SOIL_get_imageinfo_fromfile( const char* filename, SOIL_imageinfo* imageInfo ) which is akin to direct3d's D3DXGetImageInfoFromFile. It allows you to extract the size, format, and other properties of a file without actually loading the entire thing. I needed this because fully parsing an image (png's in particular) just to get some dimension info was too slow for my needs.

Due to being busy with work and such, I'm going to give myself a week to clean up my changes and I'll submit them.

#111 Kamos   Members   -  Reputation: 122

Like
0Likes
Like

Posted 14 February 2009 - 06:03 PM

I have the same problem as EzraBC.
Strange, because last time I used it I had no such problem.
Are we doing something wrong?

I can't use the .sln file to build the library myself because my MSVC version is too old (2005).

#112 lonesock   Members   -  Reputation: 799

Like
0Likes
Like

Posted 17 February 2009 - 12:20 PM

Hi, all.

As you know, SOIL uses stb_image internally for most if the loading/saving functionality. In recent times Sean updated his stb_image code to be thread-safe. In doing so he apparently made a bunch of changes that are compiler specific. I didn't notice at the time, and I was only distributing a precompiled lib made with MinGW. It used to work on all compilers, but now that stb_image uses compiler specific functions, SOIL now needs to be compiled on each target compiler.

SOIL ships with a number of project files: Code::Blocks, a makefile for GCC (Linux and Mac and MSYS folks), Visual Studio 6, 2003, 2005, 2008 (in the VC6, 7.1, 8, 9 directories, respectively). So everybody should be able to build it on their dev machine, in theory. Is this a problem? Should I just have N compiled library files ready to go in the zip?

Jonathan

#113 swiftcoder   Senior Moderators   -  Reputation: 9516

Like
0Likes
Like

Posted 06 March 2009 - 08:34 AM

Quote:
Original post by lonesock
Is this a problem? Should I just have N compiled library files ready to go in the zip?
Can we get a source-only zip as well? I *never* want any form of binary, so it is wasted space.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#114 Skyy   Members   -  Reputation: 139

Like
0Likes
Like

Posted 07 March 2009 - 01:31 AM

Loving it. Thanks!
Thanks for giving us all the different project files to make the compile process ALOT easier. Since I'm a total noob with compiling libraries and I almost 99.9% of the time won't get the libraries to compile for the stupidest reasons but this one I did since I was supplied with everything. Thanks!

So far the librarys been awesome :)

#115 TyphoidHippo   Members   -  Reputation: 122

Like
0Likes
Like

Posted 13 April 2009 - 02:12 PM

This library is all kinds of badass. It was a pleasant surprise when I didn't even have to change a few of my functions to transition from my loaders to SOIL. Maybe that's not as unlikely as it seemed to me at the time...at any rate: Thank you very much, lonesock. You rock!

#116 ricardo_ruiz_lopez   Members   -  Reputation: 218

Like
0Likes
Like

Posted 24 May 2009 - 02:40 AM

Thanks a lot, nice library.

#117 velk   Members   -  Reputation: 122

Like
0Likes
Like

Posted 30 May 2009 - 09:56 PM

hi

i ve got problem with soil for a 2d opengl engine

rendering quality is bad especially when i ve got color gradients on my textures.

dont know why, but I m sure that the problem is related to soil options , because when i use my own LoadBitmap code , i dont get this problem

http://www.vm-games.com/imgs/in_jpg.jpg

http://www.vm-games.com/imgs/in_engine.jpg


i cant explain because i m using the same filtering (linear) with both soil code and load bitmap code

any ideas?


#118 lonesock   Members   -  Reputation: 799

Like
0Likes
Like

Posted 02 June 2009 - 06:38 PM

Quote:
Original post by velk
hi

i ve got problem with soil for a 2d opengl engine

rendering quality is bad especially when i ve got color gradients on my textures.

dont know why, but I m sure that the problem is related to soil options , because when i use my own LoadBitmap code , i dont get this problem

http://www.vm-games.com/imgs/in_jpg.jpg

http://www.vm-games.com/imgs/in_engine.jpg


i cant explain because i m using the same filtering (linear) with both soil code and load bitmap code

any ideas?

Any chance you could post the code you're using to load the image via SOIL? Is it possible you have DXT compression enabled? Depending on the resolution of the original image and the options you've supplied to SOIL, SOIL may be upsizing the image to a power of two, which could lead to stair-stepping like that over long gradients.


#119 donnelpg   Members   -  Reputation: 100

Like
0Likes
Like

Posted 16 September 2009 - 12:44 PM

Hi,

I'm also having these same linker errors when I try to use SOIL:

1>libSOIL.a(stb_image_aug.o) : error LNK2019: unresolved external symbol __alloca referenced in function _stbi_zlib_decode_noheader_buffer
1>libSOIL.a(image_helper.o) : error LNK2019: unresolved external symbol _sqrtf referenced in function _RGBE_to_RGBdivA2

MatthewBurk says it was fixed by "building a new SOIL.lib". I wonder if you could go into a little more detail? (I'm kinda new to visual).

#120 donnelpg   Members   -  Reputation: 100

Like
0Likes
Like

Posted 16 September 2009 - 01:02 PM

Actually, it fine now. Yeah, its the SOIL.lib file in the project that's provided. Include that and it is fixed.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS