I made a small little library to do effects on SDL_Surfaces. The main ones are inverting colors, grayscaling, flipping , recoloring and making circles.
I will like to expand the functionality more to make cooler effects for using RAW SDL based projects.
I added the source and example to Github:
I opted to go the route of C++, but maybe I will make a c version with just functions. But one of the functions used std::min, but probably is a c alternative available.
Please give it a look and all feedback is welcome.
Hello!
Thanks for sharing.
If your only need for C++ is using std::min, you could simply define your own function: int imin(int a, int b) { return a < b ? a : b; } for integers, and for float you can use the standard fmin.
Moreover, there is dead code in your .cpp (code that is commented). Because you are using git (or any other versioning tool), you should simply delete the code you no longer need. If later you want to get it back, you can use git to see previous version of your code where this code appeared.
Finally, you are not consistent on variables declarations, sometimes int x is inside the for-loop parenthesis, and sometimes outside (guideline : there should be inside the for-loop parenthesis if you donât need x outside the loop).
Iâve updated the github to reflect snake_case_lower and also am now using SDL_min and SDL_max for less includes needed. Also Iâve ran into a bug in which the prerendered circles are not removing from memory when calling SDL_FreeSurface, would anyone be able to assist with this goal?
Well first of all, let me say this is an excellent idea! I can think of lots of uses for these sorts of renderings. I actually tried putting together something similar once, to draw triangles, for a minigame I wanted to make. I only abandoned that effort because it was too slow to work (well) in real time.
I took a look through your code, and while I can totally see myself using this, I did have a few comments.
I think you could really set yourself apart if you find a way to optimize for real-time rendering. The intuitive solution you have here (pixel by pixel in one thread) is great for pre-rendering, but wonât be fast enough to do very much with in real time. This probably means using GPGPU, using something like OpenCL or OpenACC. Of course, you will also need to consider the compilation process and maybe provide binaries if it requires less common builds of gcc or something.
I am the king of microoptimizations, so if it were me, I would try a few different approaches and see which is most efficient. I see youâre using SDLâs built-in surface manipulation. Keep in mind you can load pixel data from RWops, which means you can easily generate an array in plain old C that has four chars for each pixel, render in that space and then import through RWops functions. I donât actually know if it would be faster, though, and there may be other possible solutions too.
Some other useful effects and renderings I can think of (if youâre interested) include diagonal lines, triangles, and bloom/glow. I know a little bit about bloom effects, so just ask if youâre interested.
On the topic of C vs C++, the advantage to using plain C is that itâs the lingua franca of the software world. Virtually every language that has an FFI at all can interface with C, and it also means that any developers who are writing their game (or what have you) in C will be able to use your library with ease, using the same compiler they use for everything else.
Thanks for the upload! I really think this is a great project!
I might add another good reason to use C instead of C++ for libraries, is that you gain not only greater portability(via FFIâs) but also simplicity. Since C is lower-level than C++, there arenât any âbig ideasâ mixed in with it(e.g. OO). Which makes it a perfect fit for other language FFIâs, kind of like how a brick is a perfect object to build a house with! Since C is so simple, it is ultimately more versatile as a low-level language than C++ can be. A real world example might be how Emacs is build! Emacs Lisp was implemented in C. Lisp has a lot of big ideas, that make it suitable for AI development(e.g. reflection), Since C is so basic, the developers of Emacs were able to implement all of the features of that higher level language themselves in C first, thus making it possible in Emacs Lisp!
Hereâs where I learned what I know about the glow effect:
The short version is, for each pixel, you take the nearby pixels and scale a part of their data by distance, so it looks like itâs glowing. The part of the data (RGB or Alpha) depends on your specific implementation; in this case, I would think you should probably retain RGB and scale Alpha but you can always play with it some. You give it a radius, in pixels, and this controls how pronounced the effect is.
Thanks to the nature of these kinds of effects, you can usually scale before calculation and then scale back once itâs done. This speeds the calculation up dramatically. But the best performance boost you can get is by utilizing a Gaussian function for the blur. Two Gaussians add to form another Gaussian, so you can bloom first on one axis and then on the other. This means that rather than running 4 * radius^2 calculations for every pixel, youâre running 2 * radius calculations for every pixel instead.
Now, this is the kind of calculation that really needs to be hardware accelerated, which is where I got stuck when I tried to make my own. I could probably have figured it out eventually, but support for GPU calculations just wasnât there for Windows yet (and I develop on a Windows machine), so I was looking at doing some pretty crazy tricks trying to get it to work. The situation may be improved by now; Iâm not sure. I just know that if somebody can pull this off in SDL, I would absolutely LOVE to have this kind of thing available.
Best of luck, if you decide to look into this! Like I mentioned before, I think this is a great library already.