nothings / stb

stb single-file public domain libraries for C/C++
https://twitter.com/nothings
Other
26.98k stars 7.72k forks source link

Requested libraries #203

Closed nothings closed 4 years ago

nothings commented 9 years ago

THIS THREAD IS FOR REQUESTING LIBRARIES, NOT FOR ADDITIONS TO OTHER_LIBS.

Over the years, people have suggested the following ideas for stb libraries. Here are your options for these libraries, where appropriate.

Leandros commented 9 years ago

:+1: for a C preprocessor, which is not completely bound to C, but the C preprocessor syntax.

eloj commented 9 years ago

Link for the PDB "specification"

hydexon commented 9 years ago

PhysFS-esque pak-file-esque handler with pluggable back-ends

^^^ this

theGiallo commented 9 years ago

Something about fuzzy search?

sagamusix commented 9 years ago

Once the last patent will have expired in 2017, what's your stance on implementing an MPEG 1 / 2 / 2.5 audio decoder? Naturally it's inferior to Vorbis and other more modern codecs, but there are still usage scenarios where a single-file MPEG decoder could come in handy (e.g. if you don't want to depend on something like mpg123).

nmr8acme commented 9 years ago

Would a simple path rasterizer be within reason? Something like SVG lite?

nothings commented 9 years ago

There's a software rasterizer for quadratic bezier paths in stb_truetype, but it just produces an alpha channel, no fill processing, no strokes.

glampert commented 9 years ago

A fast and lightweight library for video encoding would be great for frame-capture of games. It's a pain to integrate something like ffmpeg when you're just trying to record your frames for debugging and development.

alpha123 commented 8 years ago

Something to efficiently generate sorted suffix arrays would be rather nice. The best implementation I'm aware of currently is libdivsufsort, which is fairly large.

metiscus commented 8 years ago

It would appear that https://sites.google.com/site/yuta256/sais is a rather small and efficient sorted suffix array code and it is licensed with MIT as well.

mackron commented 8 years ago

Not sure if anybody here would be interested, but I finally got around to doing a simple FLAC decoder that I've been meaning to do for a while dr_flac.

C, single file, public domain. Performance roughly comparable to the reference implementation.

gingerBill commented 8 years ago

Did you want a Vector/Matrix library for game development? I've written one in C (and it works in C++ too!) C/C++, single file, public domain. https://raw.githubusercontent.com/gingerBill/gb/master/gb_math.h

kieselsteini commented 8 years ago

Hi there. I wrote a simple stereo audio mixer useful for games. I wrote it because I was unhappy with SDL_mixer and OpenAL. You still need to provide some "real" audio device where all the data is written to. The file includes a small SDL2 example where I used the audio callback to get my speakers working.

https://github.com/kieselsteini/sts/blob/master/sts_mixer.h

C/C++, single file, public domain. Compiles without warnings using gcc/g++ -Wall -Wextra :)

ddengster commented 8 years ago

How about writing to .tiff files using stb_image_write, so users can import a single file with both screenshot and color lut layers to an image editing program for convenient color correction?

nothings commented 8 years ago

@ddengster That doesn't require multiple layers http://the-witness.net/news/2012/08/fun-with-in-engine-color-grading/ in fact I think it would make it harder since how do you color correct multiple layers in e.g. Photoshop? Anyway, if you have more discussion of this, please open a new issue, as this is a thread for new libraries, not for adding features to existing libraries.

leilei- commented 8 years ago

a file handling procedural animation like those oldschool demos with the fire (with a palette color ramp) and the water refraction / ripple effects

starwing commented 8 years ago

Moved to https://github.com/nothings/stb/issues/333

r-lyeh-archived commented 8 years ago

stb_gltf :)

nothings commented 8 years ago

@r-lyeh I'm not thrilled with glTF. Should have been a pure binary format; as it stands if you want to pack everything in one file, you pointless pay in size and speed the base64 encoding. Of course there's the binary encoding extension, but then you still have to parse the JSON inside it--needless complexity. (I'm sure they see it as anti-complexity because they're leveraging existing JSON parsers, but blah.)

Still, it beats Collada.

r-lyeh-archived commented 8 years ago

Yep fair points. Still, I would use stb_gltf always over the bloated assimp importer :D

zumpchke commented 8 years ago

@nothings How about a hash table?

nothings commented 8 years ago

@VanushVaswani There is one in stb.h, though it's tricky to configure.

darkuranium commented 7 years ago

PhysFS-esque pak-file-esque handler with pluggable back-ends

@hydexon: I'm working on one, but it'll be a two-file library (because of miniz woes), at least until I write my own decompressor (I plan on doing that eventually).

Builtin will be ZIP + dirs only (but extensible), and I also intend to add some other nifty features (e.g. globbing).


Here's some other things I'd find useful, in no particular order (some of these I'm already working on):


@nothings: Just a FYI, that "mts" link (for threading) is broken. Also, what's SVD in this list?

crypto library -- consider TweetNaCl

This is strongly related: https://github.com/eduardsui/tlse


Would a simple path rasterizer be within reason? Something like SVG lite?

@nmr8acme: There's NanoVG, which is a HTML canvas-like path rendering frontend to GL & GLES (custom backends are possible, too). Not public domain, though, and not single-file (it's zlib, and it's still only a few files). The guy even made a NanoSVG library in the same vein, though I'm not sure how well it works (never tried it).

benblo commented 7 years ago

Request: clipboard read-write access, cross-platform (Windows, OSX, X11, etc) ... clipboard access is ridiculously complex and non-portable :(

sagamusix commented 7 years ago

Once the last patent will have expired in 2017, what's your stance on implementing an MPEG 1 / 2 / 2.5 audio decoder? Naturally it's inferior to Vorbis and other more modern codecs, but there are still usage scenarios where a single-file MPEG decoder could come in handy (e.g. if you don't want to depend on something like mpg123).

The last MP3 patents have expired and MP3 licensing has ended a week ago.

Edit: There is also MiniMP3, which is a header+source MP3 decoder forked from an old FFmpeg version (hasn't been updated in a while and is LPGL-licensed, which might be a blocker for some people).

strega-nil commented 7 years ago

If I'd like to work on one of the requested libraries (key-value store), how do I start? Should I contribute it under stb, or under my own thing?

nothings commented 7 years ago

@ubsan You can absolutely just tackle anything and make it your own thing and if it meets the requirements I'll list it on https://github.com/nothings/single_file_libs rather than as part of stb.

I'm pretty selective about adding libraries I didn't write to stb, because it typically becomes my job to support them. If you wanted to go down this path I'd have to see if it's something I'd be willing to support and I'd probably want to have some input on the API design. But obviously the most important question is whether you event want to do that; there's maybe some benefit (stb "brand" hopefully gives a presumption of quality for some people, and people see it when they come to the stb github) but drawbacks as well (people may assume I wrote it; I will interfere with it).

strega-nil commented 7 years ago

@nothings I wanted to make it a part of stb because of that interface feedback, as well as that interference 😄.

nothings commented 7 years ago

I'm happy to do those things and still NOT make it an stb library so I don't have to support it!

strega-nil commented 7 years ago

@nothings cool, then that's perfect :)

nothings commented 7 years ago

If you're ok with it, further discussion is probably best done over email.

lieff commented 6 years ago

@sagamusix here new https://github.com/lieff/minimp3 . It's not forked from FFmpeg, CC0/public domain licensed, have sse/neon opts and ISO conformant.

sagamusix commented 6 years ago

@lieff Great news! I will have a look at it.

kphillisjr commented 6 years ago

I have a few algorithm suggestions for the STB Library that is generally used in many places.

darkuranium commented 6 years ago

@kphillisjr I've been meaning to do much of that, though in a few different libraries (instead of single).

  • Basic 3D Geometry Functions - These are the generic 3D models that are created mathematically. A short list of geometric types are as follows...

For the meshes, the plan was to implement (at least) the following ones:

No reason why I couldn't add in a torus, too (and maybe a teapot, for good measure?). NURBS might be handy, too (in fact, they could be the basis for many [most?] of these).

  • Surface Subdivision Algorithms

For that, I'd probably implement at least simple and Catmull-Clark subdivision surfaces. Most likely in the same library.

  • Binary Space Partitioning (BSP) algorithm - This is used in scene rendering, and game levels. The general implementation of this algorithm uses either a k-d Tree or a Quadtree.

I have little use for BSP, myself, but if I'm doing the rest, perhaps I could be persuaded to do that, too.

  • Constructive Solid Geometry (CSG) - The general idea of this is algorithm is to take simple Geometry elements ( for example cones, cubes, cuboids, cylinders, prisms, pyramids, and spheres ) to create more complex geometry.

I have a need for this, yes. Though I plan on making it a more advanced one, namely, by encoding spheres as-is, rather than as triangular approximations (if I find the time to do so ...).

  • T-Junction elimination Algorithm - This is the Optimization of geometry generated through BSP and CSG algorithms. Sometimes this increases polygon count slightly, but leads to overall speed improvements since it prevents degenerate triangles.

Sounds useful, but this is me first hearing about it.

kphillisjr commented 6 years ago

@darkuranium

@kphillisjr I've been meaning to do much of that, though in a few different libraries (instead of single).

  • Basic 3D Geometry Functions - These are the generic 3D models that are created mathematically. A short list of geometric types are as follows...

For the meshes, the plan was to implement (at least) the following ones:

I figured the Basic 3D geometry functions would depend on a 3D Vector library by default.

No reason why I couldn't add in a torus, too (and maybe a teapot, for good measure?). NURBS might be handy, too (in fact, they could be the basis for many [most?] of these).

Binary Space Partitioning (BSP) algorithm - This is used in scene rendering, and game levels. The general implementation of this algorithm uses either a k-d Tree or a Quadtree.

I have little use for BSP, myself, but if I'm doing the rest, perhaps I could be persuaded to do that, too.

In general BSP and CSG are very similar. the Basic Geometry of CSG is called Brushes when referring to BSP Systems used by games. The biggest things that BSP requires for implementation to help with performance is as follows...

  • T-Junction elimination Algorithm - This is the Optimization of geometry generated through BSP and CSG algorithms. Sometimes this increases polygon count slightly, but leads to overall speed improvements since it prevents degenerate triangles.

Sounds useful, but this is me first hearing about it.

The T-junction elimination algorithm is part of the CSG and BSP pipeline to prevent visible seams at locations where geometric primitives intersect and/or overlap.

darkuranium commented 6 years ago

@kphillisjr

I figured the Basic 3D geometry functions would depend on a 3D Vector library by default.

That's a bit of a problem, because such a lib made in C (as is most of stb) would look completely different than such a lib made in C++. I have a bunch of C vector libraries, but converting them to C++ would not be very practical (for starters, such C++ libs rely heavily on inlining, which is more difficult in C --- unless I limit this to C99).

C99 has C++-like inline, though it still needs a .c file for $REASONS (I consider this a design flaw in C99, but that's how it is). In older C, one would be stuck with compiler-specific utilities (e.g. __attribute__((always_inline)), or with compiler warnings (by using static, which would warn for every unused function in many [most?] compilers).

  • Teapot - This was not added since this is a complex geometry form, is generally considered a low priority. This is generally a data type related to NURBS.
  • NURBS - This requires a lot of math to complete, and really belongs to it's own library set. This is honestly best suited for generating organic modeling.

Eh, maybe. Technically, every shape up there (except maybe the plane & cube) is better done with NURBS anyhow.

In general BSP and CSG are very similar. the Basic Geometry of CSG is called Brushes when referring to BSP Systems used by games. The biggest things that BSP requires for implementation to help with performance is as follows...

They are related, but ultimately, still very different beasts (even if one commonly uses the other). I think it would be beneficial to have support for fixed-point here (perhaps as a compile-time #define?).

nothings commented 6 years ago
raysan5 commented 6 years ago

In raylib, I use http://github.prideout.net/shapes for basic 3D geometry creation, it works very good, just need to convert loaded data to my own Mesh struct format.

EDIT: @nothings just answered while writting this message!

lieff commented 6 years ago

I think BVH is more useful these days than BSP.

kphillisjr commented 6 years ago

@nothings -

  • 3d geometry functions: there's a single file lib at http://github.prideout.net/shapes but I've never used it. it's found on my list in the single_file_libs repository

I know of this, but there is different takes on the basic premise of generating the basic types I mentioned.

  • surface subdivision - this seems a little specialized, is there really much demand for it?

This is not exactly specialized. In general these algorithms are used by 3D rendering pipelines involving tesselation like OpenGL 4.x, DirectX 11, DirectX 12, Vulkan, Metal, etc... The general algorithm is generally simple to implement once a solid basic 3D library is in place.

  • BSP - similarly, this was common in the past, esp. with software rendering, but it doesn't seem very useful these days?

Honestly BSP systems are still in use by many game engines even today. A short list of current game engines with BSP implemented is as follows...

Some of the current uses for BSP are as follows:

  • Constructive Solid Geometry - I've been working on a CSG library on and off for a couple of years. It uses 128-bit integer math and is designed to be robust and exact, but to do this you have to work with relatively low-precision vertices (around 14-bit if I recall correctly) or you have to define polyhedra as the intersection of half spaces defined with fixed-point plane equations, which makes it hard to make vertices on independent shapes line up; indeed, makes it hard to even make a rotated octahedron. (This might include an internal BSP tree for efficiency, but I wouldn't want to reuse some other BSP tree library nor would it be suitable for exposing as its own thing.) Even though this is really restrictive, some kind of restriction like this is necessary to make CSG robust. Otherwise numeric errors and things will cause weird breakages. And I don't think a CSG library that just randomly breaks some of the time is that great. (When we made Thief/System Shock 2, the CSG engine there was similarly non-robust and could just randomly break and the designers had to live with it, but that was part of their job and a trade-off the dev team just had to accept for 'there is no way to fix this' reasons. In the marketplace of free libraries, a library that just randomly breaks is very different.)

I figured precision notes and warnings would be part of the CSG and BSP algorithm documentation. As far as the purpose of the libraries, I figured the BSP and CSG single header libraries would serve as a sample implementations for developers wishing to implement a BSP/CSG in their own game engine.

Photosounder commented 6 years ago

I had no idea that there was a whole world of one file libraries out there, this is so cool. I have a whole big library that contains a variety of things, some of which can definitely be useful on their own, like fast fixed point or floating point approximations of math functions (I'd say a pretty good candidate given how useful it can be to anyone who needs fast math), antialiased primitive drawing (lines, rectangles, circles), PRNG stuff, like to generate Gaussian random numbers or to treat the output sequence of a PRNG (in my case a slight modification of MINSTD) as if it was a huge randomly accessible array (useful for GPU-based parallel noise generation), some vector font thing (not based on actual fonts), some useful text, unicode, parsing, formatting functions, a whole load of functions to deal with point vectors or rectangles, file management/filesystem stuff like loading a tree, tiled mipmapping, selection algorithms (like, you have a list of things, and you want them to be selectable the same way they are in a typical file explorer), all kinds of stuff I might need.

I'm not going to do one-file standalone libraries and maintain them, I just want to share my code but not actually cater to anyone else's needs, but if anyone is interested in doing that from any of my code go right ahead. https://github.com/Photosounder/rouziclib

kphillisjr commented 6 years ago

I forgot to make the post I had mentioned on issue #518. At any rate, here is a list of a few more libraries that game developers may find useful.

I probably should mention that for the MP3 Decoder that I found another public domain decoder that dates back to April of 2002 or so ( See: https://github.com/technosaurus/PDMP3 ).

darkuranium commented 6 years ago

@kphillisjr I made part of that.

The rest of what you're describing is planned (see "TODOs" at the start of each file).

If anyone's interested in contributing, let me know!

(EDIT: If anyone knows where to find some test DDS files and such, I'm very much interested!)

lieff commented 6 years ago

I'm also cover h264/svc encoder as alternative to x264: https://github.com/lieff/minih264 Is someone needs h264 decoder too?

nothings commented 4 years ago

I don't wish to make any more stb libraries because I don't wish to increase my maintenance load beyond the libraries I have now and any other libraries I might want to make for myself in the future. So I'm closing this issue.