next »

[ferreiradaselva]

I thought we could use a thread to share cool projects that we find on GitHub, open for discussion, too.

I will start sharing @antirez's SDS (Simple Dynamic Strings) library. It's probably the best string manipulation library for C out there.

Link: https://github.com/antirez/sds

[qMopey]

Another option is to just not used strings at all, except for debug purposes (or for tools). For debug stuff, std::string works perfectly fine. In my own project I use a processor to convert strings to integers with a hash function, and then save out a debug table file of all the strings.

For in game dialogue and whatnot the strings are stored inside of utf8 text files and loaded into the game as a chunk of binary data, so no string wrapper is needed.

There's a pretty good argument *against* ever using an all-purpose string library like sds. Not that we want to get into all the nitty gritty details of pros vs cons, but just pointing out one way to make a game is by excluding strings as much as possible from the final product.

---

I was looking at tinygizmo today. It creates 3D manipulators for scale/rotate/translate in a single-header style. Looked pretty cool. Unfortunately it does use a bunch of STL containers internally, and the header is a bit monstrous in regards to templates. But the final product looks useful. I was considering writing a header like this for 2D manipulators, and probably will sometime soon!

[pmprog]

Not directly a project, but an "Awesome" list for Game Dev
https://github.com/ellisonleao/magictools

[buto]

Not directly a project, but an "Awesome" list for Game Dev
https://github.com/ellisonleao/magictools

That's great! Thanks!

[ferreiradaselva]

Another option is to just not used strings at all, except for debug purposes (or for tools). For debug stuff, std::string works perfectly fine. In my own project I use a processor to convert strings to integers with a hash function, and then save out a debug table file of all the strings.

For in game dialogue and whatnot the strings are stored inside of utf8 text files and loaded into the game as a chunk of binary data, so no string wrapper is needed.

There's a pretty good argument *against* ever using an all-purpose string library like sds. Not that we want to get into all the nitty gritty details of pros vs cons, but just pointing out one way to make a game is by excluding strings as much as possible from the final product.

True. I find the library interesting mostly because how antirez saves the string length "behind" the string, and return the string only. But, I agree with all that.

I was looking at tinygizmo today. It creates 3D manipulators for scale/rotate/translate in a single-header style. Looked pretty cool. Unfortunately it does use a bunch of STL containers internally, and the header is a bit monstrous in regards to templates. But the final product looks useful. I was considering writing a header like this for 2D manipulators, and probably will sometime soon!

Hmmmm , I should make that kind of thing as example for my game framework.

[ferreiradaselva]

It's 2017 and people still use GLEW as OpenGL loader.

Use GLAD, folks: https://github.com/Dav1dde/glad

[ProgramGamer]

My college professor is teaching us OpenGL and he's using GLEW. What's the main difference between GLAD and GLEW?

[Cheezmeister]

It's 2017 and you still need to use 3rd-party code to in order to even use half of OpenGL. That's what gets me. Can we all agree this is not a great situation?

<shameless plug>Procjam is coming up. I wrote some SDL/GL boilerplate so you don't have to: https://github.com/Cheezmeister/jamboot</shameless plug>

[qMopey]

My college professor is teaching us OpenGL and he's using GLEW. What's the main difference between GLAD and GLEW?

GLEW is old and annoying and difficult to setup and link against. Glad loads a bunch of function pointers, and is just a c + header combination.

Both of them are trying to load OpenGL function pointers from a dynamic library.

[ferreiradaselva]

My college professor is teaching us OpenGL and he's using GLEW. What's the main difference between GLAD and GLEW?

Both requires calling an initialization function after the context creation gladLoadGL()/glewInit()

The differences:

GLEW

• Doesn't use the spec released by Khronos. The spec file that can be parsed (gl.xml) can be used to check what is extension, what is core, what is deprecated and what is not, for each version. This spec (it's on github: https://github.com/KhronosGroup/OpenGL-Registry) changes *really* fast. GLEW doesn't keep track of that.
• Doesn't support OpenGL ES.
• "glewExperimental()" is broken s**t. Don't expect that to work with others just because it worked on your computer.

GLAD

• Is a python script that will generate a header based on the later (will automatically download) spec
• Has support for GLES.
• The generated files (glad.c/glad.h) will be for your OpenGL target choice. For example, in my project I generated for OpenGL 3.3 core.
• If you don't want to download the generator, you can generate the files online (http://glad.dav1d.de/)

It's 2017 and you still need to use 3rd-party code to in order to even use half of OpenGL. That's what gets me. Can we all agree this is not a great situation?

It's not great, but since each GPU vendor has to ship their own implementation of OpenGL, that's what we got.

There's also gl3w, which seems good. But I never used.

[ProgramGamer]

I'll mention GLAD to my professor then. It might be worth teaching lol.

[JWki]

I used gl3w last time I did something with OpenGL and can recommend it.
Tbqh it doesn't really make a lot of a difference.

[powly]

I have a system that's a lot like GLAD but it parses glext.h directly and doesn't update it automatically. This may be a bit cumbersome as the formatting of the file can change in principle and introduce things I haven't accounted for, but this hasn't really been a problem so far -- I do recall making a single change since gl4.3. I'm not sure what you mean with the spec changing really fast since there should be no changes to a core version after release and new ones aren't usually released even yearly. Well, maybe if you really want to try out new extensions as they come out.

Indeed, after you have something up and running that gives you the function pointers it's all fine and you can focus on the important things.

[ferreiradaselva]

Converts 3D Wavefront .OBJ to C headers:

https://github.com/takeiteasy/obj2header

[ferreiradaselva]

Bitmap generation with local similarity algorithm:

https://github.com/mxgmn/WaveFunctionCollapse

Useful for procedural level generation. Certainly for other things, too.

[Fulby]

For VR dev in Unity the https://github.com/thestonefox/VRTK project is the most extensive toolkit I'm aware of.

Also in Unity but not VR specific, I found https://github.com/Chman/Moments to be a good base for generating gifs directly from within the game. With this I can create gifs to upload to Twitter/Imgur far faster than either saving individual images and putting them together in GIMP/Photoshop, or recording video and converting part of it to gif.

[qMopey]

Mattias Gustavsson wrote some high quality single file C headers. I've adopted his assetsys.h. It's a really well written piece of software! It can be a little hard to figure out why such a system is useful for a game -- at least for me it was. I went ahead and asked Mattias directly on Twitter why it was useful and why someone would want to use it. He said:

The main thing it does for me, and which my previous system also did (but in a more limited and messy way), is to allow me to put all my data files in one single "data.dat", and access it without having to extract the files somewhere. I find it a bit messy when a game has an exe and a million files in lots of subfolders, when I can just have the exe and a single file with assets. Also, the process of opening a file on windows is actually kind of slow - there's all sorts of kernel stuff involved like looking up user rights etc. I think I read somewhere that these days, that bit takes more time than the actual harddrive IO. So having a single file which is only opened once makes a lot of sense.

The new system, which is the one I open sourced, internalizes the "miniz" lib to allow my asset collections to be actual zip files - my previous system used a custom tool to just merge all files and write a header. But it is much more convenient to just use zip tools to manage these archives. Plus, it gives me compression as well.

Another addition in the new system, is to be able to "mount" several zip archives, and having a well defined order in which files are searched for. This would allow me to mount my "data.dat", and later I could update only some files and put them in an "update.dat" which I mount after "data.dat". Since I use virtual paths, I would still just load my "data/title_screen.png", only now it would be read from the "update.dat" archive, and the original one in "data.dat" would be ignored.

A nice thing is that when I am making a game, I can even mount files that doesn't exist yet - it will give me an error, which I can ignore, but once the file exists, it will get used. So I could mount the "update.dat" even in the original release, and later when update.dat is present, only then will it be in use.

Since the paths are virtual and you can define the root when mounting, its possible to have separate data files for different subfolders. You could mount a "data.dat" as the path "/assets/...", and a "sprites.dat" as "/assets/sprites", and to the game it would all look like just one big data folder.

It also supports mounting a folder rather than a zip file. I use this mainly during development, so I can have a "data" folder containing all my assets, making it easy to update them, and when I make a release, I zip it up to a "data.dat" file. I usually mount both the folder and the file from the start, so I don't even have to change the code when releasing - I just zip up the "data" folder, ad then remove the folder, having the game only use the zip file.

But overall, using something like assetsys is not a necessity - it just make some things a bit more convenient, and distribution a little more tidy

And then said some more later

When it comes to memory use, all my libs, including assetsys.h, supports the user specifying their own allocation functions. You can #define ASSETSYS_MALLOC to re-route all of its internal allocations - this would allow you to track the amount allocated before forwarding it to standard malloc.

The way assetsys.h works, is when you mount a zip file, it loads only the index part and keeps that in memory. This includes the filename and size of each entry, and also the offset into the archive where the data is. But only the index is loaded, not any actual data.

When you want to access an asset, you can call assetsys_file_size to get the size of the file - the size if will be when loaded and decompressed. This allows you to allocate the right amount of memory (the assetsys will not allocate it for you) and then call assetsys_file_load, which will load compressed data from file and uncompress it into the memory you have passed it. So there are no duplicates held of any files - the only thing held in memory is the zip file index.

You can mount both folders and zip files in any combination and order you want. When mounting a folder, it will parse the folder structure and store the name and size of every file. But same as for mounted zip files, it will not actually load a file until it is requested - and then it is loaded directly into the provided memory area.

I am very much still actively using the system, and plan to do so for all my future games :)re games

I've started using assetsys.h for my own project, and think it totally rocks

Actually, all of his headers totally rock. Headers I'm inclined to use of his:

• assetsys.h - virtual directing mounting and paths abstraction
• strpool.h - high performance string pool
• hashtable.h - very cleverly written hash table with a very good API
• ini.h - well written ini parser, doesn't go overboard with features, easy to use
• thread.h - a sane thread wrapper for posix and win32 APIs

Very likely I'll use all of the libs I listed here in my project.

[JWki]

Mattias Gustavsson wrote some high quality single file C headers. I've adopted his assetsys.h. It's a really well written piece of software! It can be a little hard to figure out why such a system is useful for a game -- at least for me it was. I went ahead and asked Mattias directly on Twitter why it was useful and why someone would want to use it. He said:

The main thing it does for me, and which my previous system also did (but in a more limited and messy way), is to allow me to put all my data files in one single "data.dat", and access it without having to extract the files somewhere. I find it a bit messy when a game has an exe and a million files in lots of subfolders, when I can just have the exe and a single file with assets. Also, the process of opening a file on windows is actually kind of slow - there's all sorts of kernel stuff involved like looking up user rights etc. I think I read somewhere that these days, that bit takes more time than the actual harddrive IO. So having a single file which is only opened once makes a lot of sense.

The new system, which is the one I open sourced, internalizes the "miniz" lib to allow my asset collections to be actual zip files - my previous system used a custom tool to just merge all files and write a header. But it is much more convenient to just use zip tools to manage these archives. Plus, it gives me compression as well.

Another addition in the new system, is to be able to "mount" several zip archives, and having a well defined order in which files are searched for. This would allow me to mount my "data.dat", and later I could update only some files and put them in an "update.dat" which I mount after "data.dat". Since I use virtual paths, I would still just load my "data/title_screen.png", only now it would be read from the "update.dat" archive, and the original one in "data.dat" would be ignored.

A nice thing is that when I am making a game, I can even mount files that doesn't exist yet - it will give me an error, which I can ignore, but once the file exists, it will get used. So I could mount the "update.dat" even in the original release, and later when update.dat is present, only then will it be in use.

Since the paths are virtual and you can define the root when mounting, its possible to have separate data files for different subfolders. You could mount a "data.dat" as the path "/assets/...", and a "sprites.dat" as "/assets/sprites", and to the game it would all look like just one big data folder.

It also supports mounting a folder rather than a zip file. I use this mainly during development, so I can have a "data" folder containing all my assets, making it easy to update them, and when I make a release, I zip it up to a "data.dat" file. I usually mount both the folder and the file from the start, so I don't even have to change the code when releasing - I just zip up the "data" folder, ad then remove the folder, having the game only use the zip file.

But overall, using something like assetsys is not a necessity - it just make some things a bit more convenient, and distribution a little more tidy

And then said some more later

When it comes to memory use, all my libs, including assetsys.h, supports the user specifying their own allocation functions. You can #define ASSETSYS_MALLOC to re-route all of its internal allocations - this would allow you to track the amount allocated before forwarding it to standard malloc.

The way assetsys.h works, is when you mount a zip file, it loads only the index part and keeps that in memory. This includes the filename and size of each entry, and also the offset into the archive where the data is. But only the index is loaded, not any actual data.

When you want to access an asset, you can call assetsys_file_size to get the size of the file - the size if will be when loaded and decompressed. This allows you to allocate the right amount of memory (the assetsys will not allocate it for you) and then call assetsys_file_load, which will load compressed data from file and uncompress it into the memory you have passed it. So there are no duplicates held of any files - the only thing held in memory is the zip file index.

You can mount both folders and zip files in any combination and order you want. When mounting a folder, it will parse the folder structure and store the name and size of every file. But same as for mounted zip files, it will not actually load a file until it is requested - and then it is loaded directly into the provided memory area.

I am very much still actively using the system, and plan to do so for all my future games :)re games

I've started using assetsys.h for my own project, and think it totally rocks

Actually, all of his headers totally rock. Headers I'm inclined to use of his:

• assetsys.h - virtual directing mounting and paths abstraction
• strpool.h - high performance string pool
• hashtable.h - very cleverly written hash table with a very good API
• ini.h - well written ini parser, doesn't go overboard with features, easy to use
• thread.h - a sane thread wrapper for posix and win32 APIs

Very likely I'll use all of the libs I listed here in my project.

That sounds pretty useful actually. Asset management is something I'm currently investigating so looking at this is very helpful.

[ferreiradaselva]

Lol, I had a system exactly like that. I was using Minizip (which allows to use password) instead of Miniz (afik, it doesn't have password support). Even the folder/zip abstraction :D It's a very useful system. I just removed because right now I have games that will use little assets, so I'm just generating an array header. If I go to games with bigger requirements, it's a system I'm going back to.

One problem with Minizip is the dependency with zlib (which Miniz doesn't have).

[AlexRamallo]

Public domain single-file C/C++ libraries https://github.com/nothings/stb

stb_image in particular is very useful