Code ► Patapom
Originaly designed to create 64KB intros for the demoscene.
After some time, it became a bit more than a 64K intro framework and really became the core framework for all my experiments...
NOTE: ALL the parts described below have been thoroughly tested in real use condition! That means the code should be robust enough and you shouldn't encounter bugs very often (hopefully)...
Various libraries, including:
An image library that supports all formats the FreeImage library is supporting, plus the DDS format. It also offers a simple and efficient plotting service as well as a HDR=>LDR conversion service. It supports various color profiles and can be used as a very simple Profile Connection Space (CIE XYZ) to ensure a full control over your import/export pipeline as it attempts to apply the principles explained in my blog about colorimetry that you can find here and there.
A very simple yet efficient DirectX 11 rendering library. Don't expect a super optimized renderer here: the main goal is to quickly and easily prototype some tools and experiments! Nevertheless, all the necessary heavy-duty structures for creating powerful GPGPU softwares are there. Most of the tools I wrote are heavily using compute shaders by the way.
A multi-tier math library that is very simple to use as it mimics the vectors found in HLSL (i.e. float2, float3, float4, float4x4, etc.).
The second tier of the library contains more involved tools like quaternions, pseudo- & quasi-random-number generators, spherical harmonics support, complex numbers suppport, noise generation algorithms, etc.
The last tier of the library contains high-level "solver" tools like Levenberg-Marquardt, BFGS, simulated annealing or other linear regression tools.
It also offers a GPU-accelerated 1D and 2D FFT library, but also the CPU version of the FFT and DFT.
Various generators, namely:
Various tests:
More precisely:
Any meta-templated-convoluted shitty code that is abominable to read and debug (i.e. anything like the STL or boost, if you like those and desperately need to explain why, please just go away).
=► My main concerns are ► useability, ► readability, ► maintanability and most of all, ► simplicity (and God knows it's awfully hard to make something simple!)
This framework is written for the Microsoft Windows platform using Microsoft Visual Studio 64-bits C++ for the low-level part, it is (usually) wrapped in CLR Managed C++ to make the native low-level part easily accessible by the high-level tools and applications that are written in C# (if you're one of those guys who like to advocate why open-source software and linux is so much better than windows and desperately need to explain why, please just go away too).
You end up with tools that you can write very easily and very quickly thanks to C#, but that are also fast as lightning thanks to optimized native C++ and/or hardware acceleration offered by DirectX.
Best of both worlds, right?