Hi Sean!
This is something that i reported some time ago in the MollyRocket forums but it never got fixed.

There's a little problem with the channels count returned in the PSD loading.
The PSD files are always loaded as 4 channels images, but the comp parameter returns the REAL number of channels of the image. So if i load a 3 channels PSD image, i don't know the final number of channels to use to load the image for example in OpenGL. I don't know if i'm being clear. But the problem is: i load a 3 channels PSD image, the image is returned correctly ALWAYS as a 4 channels image, but comp returns 3, and it should return 4, since the final image is 4 channels.
( if (comp) *comp = channelCount; should be if (comp) *comp = 4; )

In the forum i proposed to use the real channel count ( instead of using 4 channels, read the number of channels and create a the image with the channels count ). But i can't remember why you didn't want that solution.

Every time that i update stb_image in SOIL2 i've to patch this. It would be awesome to have this fixed, in any of the two ways mentioned.

Regards

In its current form it ignores the where parameter and burns through the entire input buffer.

I think: while (*p) { should be while (*p && p != where) {

That makes it work for me at least.

Error 1 error C2143: syntax error: missing ';' before 'enum [tag]' D:\Programming\WarpCore\WarpCore\include\stb_image.h 205 1 WarpCore
Error 2 error C4430: missing type specifier - int assumed. Note: C++ does not support default-int D:\Programming\WarpCore\WarpCore\include\stb_image.h 205 1 WarpCore

http://puu.sh/ba7hQ/2be31bcc02.png

Am I doing something wrong or is this an issue?

The declaration is

extern stbte_tilemap *stbte_create(int map_x, int map_y, int map_layers, int spacing_x, int spacing_y, int max_tiles);

The implementation is

stbte_tilemap *stbte_create_map(int map_x, int map_y, int map_layers, int spacing_x, int spacing_y, int max_tiles)
{
...
}

It could be implemented to output into a preallocated buffer like in stb_image_resize or with the ability to set a custom allocator for output buffer alloc/free. I am not interested in using custom allocator for internal, temporary buffers but others might find that useful too.

Hi Sean!

I received a bug report on one of my libraries that relies on stb_image to do the image decoding. It took me a while to understand what was happening since i couldn't reproduce it, until the user mentioned that it was building for 32bits with mingw32 ( and i was building 64 bit builds ).

It seems that the jpeg SSE2 decoder is failing strangely, since if i build with VC works just fine.
Here's an image of the callstack when fails:
.

Here's a project to test the issue.

I've also tested to cross-compile the project from linux and it also happens. I must say that i know nothing about SSE2 so i really can't help much with the bug. And AFAIK it's a 32bit mingw only problem, no problems so far in 32 or 64 bit builds in linux, and if i remember correctly, no problems in os x neither.

Edit:
I tried compiling with "-msse -msse2" enabled but didn't help.

Regards

When parsing the input "foo",1, stb_c_lexer will return CLEX_dqstring, CLEX_intlit, missing the comma.

I think the right fix is to change

   return stb__clex_token(lexer, type, start, p+1);

to

   return stb__clex_token(lexer, type, start, p);

I get the following error when I try to build stb_image from the current master(a7c8694) with MinGW-w64:

/usr/lib/gcc/i686-w64-mingw32/4.8/include/emmintrin.h:31:3: error: #error "SSE2 instruction set not enabled" 

got 0(22) : error C7011: implicit cast from "int" to "uint" while trying to compile caveview : )
generated fragments following:

#version 150 compatibility
#define rlerp(t,x,y) mix(x,y,t)
flat in uvec4  facedata;
     in  vec3  voxelspace_pos;
     in  vec3  vnormal;
     in float  texlerp;
     in float  amb_occ;
uniform vec3 transform[3];
uniform vec4 camera_pos;
uniform vec4 ambient[4];
uniform sampler2DArray tex_array[2];
uniform samplerBuffer color_table;
uniform samplerBuffer texscale;
uniform samplerBuffer texgen;
out vec4  outcolor;
vec3 compute_fog(vec3 color, vec3 relative_pos, float fragment_alpha);
void main()
{
   vec3 albedo;
   float fragment_alpha;
   uint tex1_id = facedata.x;
   uint tex2_id = facedata.y;
   uint texprojid = facedata.w & 31u;
   uint color_id  = facedata.z;
   vec3 texgen_s = texelFetch(texgen, int(texprojid)).xyz;
   vec3 texgen_t = texelFetch(texgen, int(texprojid+32u)).xyz;
   float tex1_scale = texelFetch(texscale, int(tex1_id & 127u)).x;
   vec4 color = texelFetch(color_table, int(color_id & 63u));
   vec2 texcoord;
   vec3 texturespace_pos = voxelspace_pos + transform[2].xyz;
   texcoord.s = dot(texturespace_pos, texgen_s);
   texcoord.t = dot(texturespace_pos, texgen_t);
   vec2  texcoord_1 = tex1_scale * texcoord;
   vec4 tex1 = texture(tex_array[0], vec3(texcoord_1, float(tex1_id)));
   bool emissive = (color.a > 1.0);
   color.a = min(color.a, 1.0);
   if ((color_id &  64u) != 0u) tex1.rgba *= color.rgba;
   fragment_alpha = tex1.a;
      albedo = tex1.xyz;
   vec3 normal = vnormal;
   vec3 ambient_color = dot(normal, ambient[0].xyz) * ambient[1].xyz + ambient[2].xyz;
   ambient_color = clamp(ambient_color, 0.0, 1.0);   ambient_color *= amb_occ;
   vec3 lit_color;
   if (!emissive)
      lit_color = albedo * ambient_color ;
   else
      lit_color = albedo;
   vec3 dist = voxelspace_pos + (transform[1] - camera_pos.xyz);
   lit_color = compute_fog(lit_color, dist, fragment_alpha);
   vec4 final_color = vec4(lit_color, fragment_alpha);
   outcolor = final_color;
}

vec3 compute_fog(vec3 color, vec3 relative_pos, float fragment_alpha)
{
   float f = dot(relative_pos,relative_pos)*ambient[3].w;
   f = clamp(f, 0.0, 1.0);
   f = 3.0*f*f - 2.0*f*f*f;
   return rlerp(f, color.xyz, ambient[3].xyz);
}

#version 150 compatibility
uniform usamplerBuffer facearray;
in uint attr_vertex;
uniform vec3 transform[3];
uniform vec4 camera_pos;
uniform vec3 normal_table[32];
flat out uvec4  facedata;
     out  vec3  voxelspace_pos;
     out  vec3  vnormal;
     out float  texlerp;
     out float  amb_occ;
void main()
{
   int faceID = gl_VertexID >> 2;
   facedata   = texelFetch(facearray, faceID);
   vec3 offset;
   offset.x = float( (attr_vertex       ) & 127u );
   offset.y = float( (attr_vertex >>  7u) & 127u );
   offset.z = float( (attr_vertex >> 14u) & 511u );
   amb_occ  = float( (attr_vertex >> 23u) &  63u ) / 63.0;
   texlerp  = float( (attr_vertex >> 29u)        ) /  7.0;
   vnormal = normal_table[(facedata.w>>2) & 31u];
   voxelspace_pos = offset * transform[0];
   vec3 position  = voxelspace_pos + transform[1];
   gl_Position = gl_ModelViewProjectionMatrix * vec4(position,1.0);
}

youtube video looks amazing
keep up the good work : )

Try building three signed-distance fields (see Valve paper, etc.).

For each one, differently perturb vertices away from sharp corners along different edges.

Use intersection of first two to get sharp convex corners

Get union with third to get sharp concave corners.

Write detector that tells if vertices get displaced too close to other edges; if so, try running the character at a higher resolution.

Store AA pixel coverage in fourth channel; shader dynamically chooses between SDF or manually subsampling coverage (use heavily biased mipmapping).

In stb_voxel_render.h line 1167 should be #elif defined(STBVOX_ICONFIG_VERTEX_8) instead of #else defined(STBVOX_ICONFIG_VERTEX_8)

(GCC correctly complains with error: #else after #else)

#else defined(STBVOX_ICONFIG_VERTEX_8)
typedef stbvox_uint8 stbvox_mesh_vertex;
#define stbvox_vertex_encode(x,y,z,ao,texlerp) \
((stbvox_uint8) ((z)+((ao)<<6))
#else
#error "internal error, no vertex type"
#endif

https://github.com/nothings/stb/blob/master/stb_image.h#L2642

I know this might sound like a weird idea, but especially for games this is very useful. Currently I have to resort to freetype for this, which is more than a little on the heavy side...

I'm experiencing a crash in stb-truetype.h when running it on android. I have a opengl based codebase and I'm using fontstash to draw text. fontstash uses stb-truetype.h to read and draw truetype fonts. My fork of fontstash is here: https://github.com/Discordia/fontstash. I have updated to the latest version of stb_truetype that I found here: 0.9 (same problem with 0.6 and 0.7). Everything works well on desktop (Linux Mint 17). Text is drawn and no crash, but on android I get a signal 7.

The crash is on row 1633 in the function stbtt__rasterize, the row is "if (p[j].y == p[k].y)".

Here is the stacktrace that I got from using ndk-dump (it starts in my cpp code and goes down through fontstash to stb_truetype.h):
********** Crash dump: **********
Build fingerprint: 'lge/geehrc_open_eu/geehrc:4.1.2/JZO54K/E97510h.1378050911:user/release-keys'
pid: 14257, tid: 14278, name: app.alienattack >>> org.discordia.game.app.alienattack <<<
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 5a98e34e
Stack frame #00 pc 000ea8d0 /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (stbtt__rasterize+376): Routine stbtt__rasterize at /home/robban/dev/bitbucket/alienattack/deps/audrey/deps/fontstash/src/fontstash/stb_truetype.h:1633
Stack frame #1 pc 000eb428 /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (stbtt_Rasterize+224): Routine stbtt_Rasterize at /home/robban/dev/bitbucket/alienattack/deps/audrey/deps/fontstash/src/fontstash/stb_truetype.h:1762
Stack frame #2 pc 000eb824 /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (stbtt_MakeGlyphBitmapSubpixel+268): Routine stbtt_MakeGlyphBitmapSubpixel at /home/robban/dev/bitbucket/alienattack/deps/audrey/deps/fontstash/src/fontstash/stb_truetype.h:1829
Stack frame #3 pc 000eb8a8 /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (stbtt_MakeGlyphBitmap+92): Routine stbtt_MakeGlyphBitmap at /home/robban/dev/bitbucket/alienattack/deps/audrey/deps/fontstash/src/fontstash/stb_truetype.h:1836
Stack frame #4 pc 000ef238 /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (fons__getGlyph+1180): Routine fons__getGlyph at /home/robban/dev/bitbucket/alienattack/deps/audrey/deps/fontstash/src/fontstash/fontstash.c:724
Stack frame #5 pc 000efebc /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (fonsDrawText+580): Routine fonsDrawText at /home/robban/dev/bitbucket/alienattack/deps/audrey/deps/fontstash/src/fontstash/fontstash.c:913
Stack frame #6 pc 000ba0c4 /data/data/org.discordia.game.app.alienattack/lib/libalienattack.so (audrey::Font::drawText(std::string const&, float, unsigned int)+248): Routine audrey::Font::drawText(std::string const&, float, unsigned int) at /home/robban/dev/bitbucket/alienattack/deps/audrey/src/audrey/font/Font.cpp:32

Info about the setup:
I'm using android ndk-r9d.
gcc/g++ version 4.8.2.
Building on Linux Mint 17.
Running on LG Optimus G with android 4.1.2.
The font I'm using is LinerationMono-Regular.ttf.

In stb_image.h at the moment there's a call directly to assert where the function isn't available if STBI_ASSERT is defined to something else before including.

There's also a warning generated by MSVC 2010 saying this cast truncates a constant value.

Forcing the number of components per pixel doesn't seem to be working with stb_image.h. Calling stbi_load() with any number between 0 .. 4 always results in 3. See code below. I'm loading a .jpg.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"

int main(int argc, char **argv) {
    const char *inputFile = argv[1];
    int x,y,n;
    unsigned char *data = stbi_load(inputFile, &x, &y, &n, 1); //This should force just one (gray) component per pixel. 

    if (!data) {
        fprintf(stderr, "Couldn't load image.\n"); 
        return (-1);
    }

    printf("%d\n", n); //This prints `3`, should print 1.

    stbi_image_free(data);
    return 0;
}

Seen in following functions:

stbi_load_from_callbacks
stbi_loadf_main
stbi_loadf_from_memory
stbi_loadf_from_callbacks
stbi_loadf
stbi_loadf_from_file
stbi_is_hdr_from_memory

It would be nice to check the whole API.

https://twitter.com/crlscrrsc/status/500232299389411329

https://github.com/nothings/stb/blob/master/stb_truetype.h#L2327

rects = (stbrp_rect *) STBTT_malloc(sizeof(*rects) * n, spc->user_allocator_context);

rects is never freed.

Hi!

I got some compile errors when I update stb_truetype.h to v1.01.
1.stb_truetype.h(2170) : warning C4013: 'assert' undefined; assuming extern returning int
After replacing all the "assert" with "STBTT_assert", this warning disappered.
2.stb_truetype.h(2339) : error C2065: 'stbrp_coord' : undeclared identifier
I thing this is because I don't have stb_rect_pack.h included in my application.
Copy the typedef of 'stbrp_coord' from the stb_rect_pack.h can avoid this error.

I'm compiling my application in a Debian x64 box, using an Windows cross-compilation toolchain.

The error message is:

In file included from ../retroluxury/src/rl_sound.c:25:0:
../retroluxury/src/stb_vorbis.c:941:1: error: multiple storage classes in declaration specifiers
 static __forceinline uint32 crc32_update(uint32 crc, uint8 byte)
 ^

followed by four more identical errors at lines 1558, 2042, and 2599.

__forceinline default definition has extern in it, as the error message shows when I add #define __forceinline to std_vorbis.c:

In file included from ../retroluxury/src/rl_sound.c:25:0:
../retroluxury/src/stb_vorbis.c:565:0: warning: "__forceinline" redefined [enabled by default]
 #define __forceinline
 ^
In file included from /opt/mingw64/x86_64-w64-mingw32/include/crtdefs.h:10:0,
                 from /opt/mingw64/x86_64-w64-mingw32/include/stdint.h:28,
                 from /opt/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.0/include/stdint.h:9,
                 from ../retroluxury/src/rl_sound.h:6,
                 from ../retroluxury/src/rl_sound.c:1:
/opt/mingw64/x86_64-w64-mingw32/include/_mingw.h:263:0: note: this is the location of the previous definition
 #define __forceinline extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
 ^

and it clashes with the functions declarations which are static.

I'm not sure how to fix this without redefining __forceinline in std_vorbis.c.

Building stb_image_write.h with MSVS 2012 yields the following warnings:

stb_image_write.h(300) : warning C4189: 'rlerun' : local variable is initialized but not referenced
stb_image_write.h(300) : warning C4189: 'head' : local variable is initialized but not referenced
stb_image_write.h(300) : warning C4189: 'runstart' : local variable is initialized but not referenced

These look to just be vestigial variables from a refactoring -- no ifdef-ed references or anything. Should be safe to delete.

Hello!

The addition of monochrome TGA writing broke monochrome BMP writing. This is because BMP expects the single Y component to be expanded to RGB, while TGA writes the Y as is.

In write_pixels():
where it used to say "case 2: write3(f, d[0],d[0],d[0]);" (needed for BMP)
you now have "case 2: fwrite(d, 1, 1, f);" (needed for TGA)

I use the following scheme to create a ogg-vorbis stream:

ogg_alloc.alloc_buffer = NULL;
ogg_alloc.alloc_buffer_length_in_bytes = 0;

int res;

do
{
  ogg_alloc.alloc_buffer_length_in_bytes += RL_OGG_INCREMENT;
  void* new_buffer = rl_realloc( ogg_alloc.alloc_buffer, ogg_alloc.alloc_buffer_length_in_bytes );

  if ( !new_buffer )
  {
    rl_free( ogg_alloc.alloc_buffer );
    return -1;
  }

  ogg_alloc.alloc_buffer = (char*)new_buffer;
  ogg_stream = stb_vorbis_open_memory( (const unsigned char*)data, size, &res, &ogg_alloc );
}
while ( !ogg_stream && res == VORBIS_outofmem );

if ( ogg_stream )
{
  ogg_position = ogg_available = 0;
  ogg_repeat = repeat;
  ogg_stop_cb = stop_cb;
  return 0;
}

return -1;

RL_OGG_INCREMENT is set to 32Kb, and when alloc_buffer_length_in_bytes reaches 128Kb stb_vorbis_open_memory crashes:

Program received signal SIGSEGV, Segmentation fault.
0x0406b39a in start_decoder (f=0x28b1f4) at ./stb_vorbis.c:3991
3991                r->classdata[j][k] = temp % r->classifications;

The backtrace is:

#0  0x0406b39a in start_decoder (f=0x28b1f4) at ./stb_vorbis.c:3991
#1  0x0406d23f in stb_vorbis_open_memory (data=0x4070720 "OggS", len=1742441,
    error=0x28b7cc, alloc=0x42210e4) at ./stb_vorbis.c:5031
#2  0x0406e39b in rl_sound_play_ogg (data=0x4070720, size=1742441, repeat=1,
    stop_cb=0x0) at rl_sound.c:169

Some additional info:

(gdb) p r
$1 = (Residue *) 0x2a2084c
(gdb) p *r
$2 = {begin = 0, end = 1536, part_size = 32, classifications = 10 '\n',
  classbook = 37 '%', classdata = 0x2a20cc4, residue_books = 0x2a20c24}
(gdb) p j
$3 = 53
(gdb) p k
$4 = 1
(gdb) p r->classdata[j]
$5 = (uint8 *) 0x0

So the memory allocation is failing and a segmentation fault is occurring instead of stb_vorbis_open_memory returning NULL and setting error to VORBIS_outofmem.

I'm using Visual Studio and the stb_image.h library.

If I call stbi_load in my program I get the following errors:

Error   3   error LNK2019: unresolved external symbol _stbi_load referenced in function "public: bool __thiscall CubemapTexture::Load(void)" (?Load@CubemapTexture@@QAE_NXZ)    ...\CubemapTexture.obj
Error   40  error LNK2001: unresolved external symbol _stbi_load    ...\Texture.obj

I commented on the commit that added the __cdecl specifier but I'll copy what I said there in an issue just to make sure it gets through:

"This change gives errors in GCC:
stb_vorbis.c:1087:20: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘uint32_compare’ static int __cdecl uint32_compare(const void *p, const void *q)

stb_vorbis.c:1243:13: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘point_compare’ int __cdecl point_compare(const void *p, const void *q)

Did a quick google and found this GCC and __cdecl
which would indicate that __cdecl is compiler specific and GCC specifically doesn't support it. (I have no idea though, I don't even know what __cdecl does)"

As I know stb_image was converted from a .c file library to a .h file library I just thought I'd make it known that there's interest in having stb_vorbis as a header only library as well. Simply because it makes it so much easier to incorporate into an existing C/C++ library.

Seeing how the previous issue I posted was about some minor issues I had with mixing C and C++ files in a premake project. Whilst mixing C and C++ files should work just fine, making stb_vorbis header only would make it much easier for me to use, hopefully for others as well.

This is a proposal for an enhancement that I've been thinking about for my use case in particular.

I've added some new image formats support in stb_image ( DDS, ETC1 and PVR ) for SOIL2, that i can't just propose to add to stb_image for various reasons ( licensing and because it doesn't make sense to add them in stb_image ). Every time that a new stb_image version rolls out I've to add this formats manually, and it's a little tiresome. But this could be easily solved if we add some function to plug-in the new format into stb_image, something like stbi_add_new_format( struct with_required_function_pointers ).

I know that this is a very specific use case, but i think that it wouldn't harm anyone, and you would be doing me a big favor to keep SOIL2 up to date against stb_image.

Thanks in advance,
Regards!

stb_truetype.h should declare the public functions in the header file section.

I ran the following program on a Windows 7 machine under Visual Studio 2013. To my knowledge, SSE2 is available.

#include <tchar.h>
#include <cassert>

#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"

#define STB_IMAGE_WRITE_IMPLEMENTATION
#include "stb_image_write.h"

int _tmain(int argc, _TCHAR* argv[])
{
    int width, height, nChannels;
    unsigned char *pixelData = stbi_load("test.jpg", &width, &height, &nChannels, 0);
    assert(nChannels == 1);

    if (!stbi_write_png("test-out.png", width, height, nChannels, pixelData, width*nChannels)) {
        return 1;
    }

    return 0;
}

Here are the source and result images:

test.jpg

test-out.png

Not sure why, but the rows of pixels at the bottom of the image are not right.

The image lib fails to load the following image:

I see this warning with clang++ with the latest in master.

./stb_image.h:1729:22: warning: add explicit braces to avoid dangling else [-Wdangling-else]
./stb_image.h:1765:25: warning: add explicit braces to avoid dangling else [-Wdangling-else]

clang++ --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

error : implicit conversion changes signedness: 'short' to 'unsigned long' [-Werror,-Wsign-conversion] stb_textedit.h 1010
error : implicit conversion changes signedness: 'short' to 'unsigned long' [-Werror,-Wsign-conversion] stb_textedit.h 1016
error : implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion] stb_textedit.h 1034
error : implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion] stb_textedit.h 1040

stb_voxel_render doesn't compile as C++ with GCC. There are a few lines where the type is missing, and apparently GCC doesn't allow or assume int as a default type for C++:

stb_voxel_render.h:2361:8: error: 'stbvox_planar_face_up_normal' does not name a type
static stbvox_planar_face_up_normal[4][4][4] =

stb_voxel_render.h:2388:8: error: 'stbvox_face_up_normal_012' does not name a type
static stbvox_face_up_normal_012[4][4][4] =

stb_voxel_render.h:2413:8: error: 'stbvox_face_up_normal_013' does not name a type
static stbvox_face_up_normal_013[4][4][4] =

stb_voxel_render.h:2438:8: error: 'stbvox_face_up_normal_023' does not name a type
static stbvox_face_up_normal_023[4][4][4] =

stb_voxel_render.h:2463:8: error: 'stbvox_face_up_normal_123' does not name a type
static stbvox_face_up_normal_123[4][4][4] =

Thanks Sean!
This will work wonders for my game. Been using Paint.NET as a leveleditor for it so far....yea....

Anyway, so far so good, really nice work!

// STB_TEXTEDIT_GETWIDTH(obj,n,i) returns the pixel delta from the xpos of the i-1'th
// character to the i'th char for a line of characters
// starting at character #n (i.e. accounts for kerning
// with previous char)

I believe it should be the delta from the i'th to i+1'th. In particular, for i==0, with the description above, I would expect to return 0.f, assuming that "xpos" means the logical x of the character near the bottom left baseline, but it seems that i==0 should return the width of the 0th character (more in line with the name).

Relatedly (? lumping in here in case I'm misinterpreting above) mouse click selection doesn't seem quite right. At the moment, it behaves as if clicking anywhere in the bounding box of a character puts the cursor at the index of that character. I think clicking should be trying to select the holes in between characters, not the characters themselves, so the X range check should be checking 0.5 of the step width as it searches. i.e. Clicking on the left half of a character should selects before it, and clicking on the right half should select after it. (This is easiest to see if you compare behaviour against e.g. notepad.exe set to a very large font size).

(I'm happy to attempt the code changes, I just wanted to confirm whether you agree with this before I do.)

First of all thanks for this great module and your other fine works.

My configuration: MS VS2013 w/STB_VORBIS_NO_STDIO & STB_VORBIS_NO_PUSHDATA_API
defined as I load my Oggs from a resource w/no streaming.

As I usually like to do with such algorithmic setups I tweaked stb_vorbis to use it's own private local heap with a HeapCreate() then I put macros to replace all malloc, realloc, and free() calls with HeapAlloc, HeapReAlloc, and HeapFree's respectively;
Added two methods, a "stb_vorbis_free_buffer(short *buffer);" to free up the buffer returned by "stb_vorbis_decode_memory", then after the Ogg has played a "stb_vorbis_heap_destroy()" calls "HeapDestroy" to remove this private heap.

Just to check, I run a two second Ogg and setup a mini-memory test setup looping HeapWalk() to count any unfreed blocks and sum up the bytes.
To my surprise my trace text: "Total 1094016 bytes leak from 101 unfreed blocks." The total is ∑(cbData + cbOverhead).

Now not really a problem for me since I destroy this heap after each play it mitigates any leaks, but not good if you are still using the default/main heap (loosing ~1mb each play).

I expanded my "poorman's" memory tracker by putting stubs around the HeapAlloc and HeapReAlloc to trace out the pointers, sizes, and source line #'s. Tried to trace it down for a few hours but the control flow in the inner decoding loops are not trivial.
I see a few large blocks leaked and then a bunch of 128byte sized, then a large one (126992), then a string of 8 sized blocks..
Could be it's allocating a something twice, or just not freeing them in the end (almost the same but different).

If you want I'll send you a text paste of the setup I'm using, and, or recommend you use some sort of memory tracer package.

Thanks,

Just a small suggestion: in stb_image.h, on line 194, there's a define:

define _CRT_SECURE_NO_WARNINGS

unfortunately when this is already defined (outside the header files), you get ugly warnings.
(some people set this define project wide)
so maybe this could be put inside an #ifndef _CRT_SECURE_NO_WARNINGS / #endif

I don't know if there are any other files with the same problem, I haven't bothered to check

First, let me express my sincere gratitude to you for these powerful libs.

I am looking for a vector math lib and I think stb_vec.h is enough for my needs. Is there any particular reason this header file is not included?

Actually other files are also missing compared to the original repo

Hi (I will try to be as brief as possible).
Is there a chance to add STBI_NO_GIF, STBI_NO_TGA, STBI_NO_BMP, STBI_NO_PSD (and other) just like it was introduced to STBI_NO_HDR?

Since there is a format checking in the code, this would eliminate additional conditions from the code, specially that coders usually stick to one (favourite) image format in their apps.

This request actually would also 'force' to use more 'independent/modular' code parts (for example STBI_NO_HDR doesn't hide all hdr implementation, there are still some functions available (not sure why).

main.c

I noticed that the zlib compression in stb_image_write was rather poor compared to what the actual zlib library would do. For example saving an rgba image filled with the gray color (128,128,128,255) prodices a png of size 42KB. When I use zlib to compress the data instead of stb algorithm, I get 6.4KB.

Many projects already use zlib, so I think having the option to use it would be nice, if that is not too much work.

I have come across a progressive jpeg that loads in GD, OS X Preview and checks out okay with jpeginfo, but returns "bad huffman code" from stbi_load.

The image in question can be downloaded from https://unsplash.com/photos/8bMPkZgazyY/download, but you'll probably have to go there with a browser and save-as as using curl straight on the URL gives a lower resolution one.

$ jpeginfo -ic X_canal.jpg
X_canal.jpg 5184 x 3456 24bit Exif  Progressive Huffman 3967267  [OK]

$ sha1sum X_canal.jpg
95345ef7f8d26330196149e32ec09457f58c49a8  X_canal.jpg
$ md5sum X_canal.jpg
1d68c5995aeb1bf6c346039f9d6e4d8e  X_canal.jpg

It entirely possible that the image is indeed corrupt, but I thought I'd offer you the chance to look at it if you want. If it's an unsupported format I feel like the error message should be made clearer, if possible.

$ identify -verbose X_canal.jpg
Image: X_canal.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Class: DirectClass
  Geometry: 5184x3456+0+0
  Resolution: 72x72
  Print size: 72x48
  Units: Undefined
  Type: TrueColor
  Endianess: Undefined
  Colorspace: sRGB
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
  Channel statistics:
    Red:
      min: 0 (0)
      max: 255 (1)
      mean: 129.937 (0.509558)
      standard deviation: 97.7956 (0.383512)
      kurtosis: -1.62445
      skewness: -0.101304
    Green:
      min: 0 (0)
      max: 255 (1)
      mean: 134.391 (0.527025)
      standard deviation: 74.1044 (0.290606)
      kurtosis: -1.3512
      skewness: -0.246102
    Blue:
      min: 0 (0)
      max: 255 (1)
      mean: 92.2491 (0.361761)
      standard deviation: 95.85 (0.375882)
      kurtosis: -1.1492
      skewness: 0.596392
  Image statistics:
    Overall:
      min: 0 (0)
      max: 255 (1)
      mean: 118.859 (0.466115)
      standard deviation: 89.8938 (0.352525)
      kurtosis: -1.36635
      skewness: 0.0719763
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Interlace: JPEG
  Background color: white
  Border color: srgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Compose: Over
  Page geometry: 5184x3456+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  Quality: 93
  Orientation: Undefined
  Properties:
    date:create: 2015-02-04T14:22:31+01:00
    date:modify: 2014-10-16T10:33:00+02:00
    exif:ColorSpace: 1
    exif:ExifImageLength: 3456
    exif:ExifImageWidth: 5184
    exif:ExifOffset: 26
    jpeg:colorspace: 2
    jpeg:sampling-factor: 2x2,1x1,1x1
    signature: 2d5107242c6865b8d58a351a3567d178dbe21500f48169391dffde797a0a5aba
  Profiles:
    Profile-exif: 74 bytes
    Profile-icc: 3144 bytes
      Description: sRGB IEC61966-2.1
      Manufacturer: IEC http://www.iec.ch
      Model: IEC 61966-2.1 Default RGB colour space - sRGB
      Copyright: Copyright (c) 1998 Hewlett-Packard Company
  Artifacts:
    filename: X_canal.jpg
    verbose: true
  Tainted: False
  Filesize: 3.967MB
  Number pixels: 17.92M
  Pixels per second: 38.95MB
  User time: 0.460u
  Elapsed time: 0:01.459
  Version: ImageMagick 6.7.7-10 2014-03-06 Q16 http://www.imagemagick.org

EDIT: Testing more images this seems very common, so not quite the white unicorn I thought I'd found.

When trying to load a .png file using stbi_load, Visual Studio stops execution with a run-time check failure. I'm not sure if this is specifically a Visual Studio 2012 thing or not. All these images fail to load, except the color_map when in release.

Nothing really major but I was wondering if the following warning:
cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C [enabled by default]
is anything to be worried about? Since I'm using Premake and just give it a bunch of source files (including stb_vorbis.c), most of which is C++ files I can't really differentiate between C and C++ files that much. I know you can compile C and C++ code separately and link together the .o files but currently with Premake4 this isn't possible, might be with Premake5.

Using g++ as compiler.

Just a heads-up: stb_image.h errors out on a certain GHS compiler because of a missing memory.h file. It seems to work fine if you comment out the include <memory.h> line, but I don't know if that causes problems in other contexts.

Someone has currently declared their intent to pursue this. Historically, multiple people have looked at this and given up, though, so it may re-open.

stb_vorbis is this single-file C library for decoding ogg vorbis files: https://github.com/nothings/stb/blob/master/stb_vorbis.c

stb_vorbis doesn't have correctly-working seek functionality (e.g. being able to say 'start playback from sample number 31415926').

The payment for a correct implementation of this feature is 5000 USD. (It may go down again in a few months as the current amount is the sum of several individuals who may drop out if it doesn't get done soon enough.) Please let me know if you are working on it to make sure we don't end up with two people doing it at the same time, as only one correct implementation will be paid out.

Requirements:

• seeking must be sample-accurate
• reasonably efficient (binary search, interpolation search, etc)
• cannot generate an off-line index or scan the whole file at start
• changes must be placed in the public domain
• you can start with the existing non-working implementation of seek (see below) or start from scratch
• you'll need to learn about both the ogg specification and the vorbis specification to do this (see the link below for some insight why)
• I (@nothings) am available to provide guidance about what the existing code is doing (aka write better comments)

Current status in the code:

• there is a 2007 implementation of seeking in the code which doesn't work. I no longer remember the details of how it doesn't work. I wrote this document about the frustrations of trying to do a performance-optimal implementation: http://nothings.org/stb_vorbis/ogg_seek.txt but at this point I will accept some suboptimality.
• the "pushdata" API supports an approximate seeking; this is satisfactory for the pushdata API but not for the normal ("pulldata") API. you can just ignore the pushdata case

Minor but I thought I'd submit it. Found this while I was running my project through Coverity static analysis, In stbtt_FindGlyphIndex()

      while (entrySelector) {
         searchRange >>= 1;
         start = ttUSHORT(data + search + searchRange*2 + segcount*2 + 2);
         end = ttUSHORT(data + search + searchRange*2);
         if (unicode_codepoint > end)
            search += searchRange*2;
         --entrySelector;
      }
      search += 2;

      item = (stbtt_uint16) ((search - endCount) >> 1);

      STBTT_assert(unicode_codepoint <= ttUSHORT(data + endCount + 2*item));
      start = ttUSHORT(data + index_map + 14 + segcount*2 + 2 + 2*item);

The assignment to 'start' within the loop is unnecessary, the value is never used. It's probably already compiled out.

https://gist.github.com/emoon/c635437f33d2c8d43570

In several places in stb_textedit, such as stb_textedit_find_charpos and stb_text_locate_coord, it assumes that the baseline is at the top of the characters. This is mildly inconvenient when integrating with stb_truetype, which assumes the usual baseline position.

It should be quite simple to fix this in a way that doesn't break existing code.