nothings / stb Goto Github PK
View Code? Open in Web Editor NEWstb single-file public domain libraries for C/C++
Home Page: https://twitter.com/nothings
License: Other
stb single-file public domain libraries for C/C++
Home Page: https://twitter.com/nothings
License: Other
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?
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!
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
.
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:
Current status in the code:
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;
}
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
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
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.
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).
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.
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.
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.
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)"
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
.
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.
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
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).
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.
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,
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);
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.
// 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.)
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 : )
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.
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.
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
stb_truetype.h should declare the public functions in the header file section.
Just a small suggestion: in stb_image.h, on line 194, there's a define:
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
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.
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
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
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.
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 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
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.
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.
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.
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"
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.
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)
{
...
}
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] =
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...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.