Rototiller is a growing collection of exclusively software-rendered, real-time graphics demonstrations.
Emphasis has been placed on minimizing external dependencies with no GPU acceleration or their related platform-specific APIs such as DirectX, OpenGL, Vulkan, or Metal.
For parallelism, CPU multi-threading is utilized, with a rendering architecture resembling that of modern GPU fragment shaders, where conventional threads serve conceptually analogous to programmable shader execution units and C functions as fragment shader programs.
The intention is to accumulate an interesting and educational corpus of small, isolated, easy to comprehend and experiment with graphics algorithms ranging from very simple introductory effects like starfields and sprite drawing to 3D particle systems and ray tracers.
Rototiller at its core provides a reusable foundation eliminating the need for writing framebuffer intialization and fragmenting, threaded rendering, commandline parsing, and runtime settings. New modules may be added by writing as little code as a single C function.
Rototiller uses SDL2 for cross-platform graphics support, in addition to Linux's libdrm/KMS for minimal full-screen graphics without the need for X or Wayland.
By not utilizing GPUs and their ever-changing, platform-specific APIs, the potential for encountering unsupported hardware or incompatibilities today or in the future is largely eliminated. Additionally, the barriers to understanding and implementing the modules are no greater than those required for generic C programs.
The list of modules and their variants is always changing, it's best to just grab the source, build, and run rototiller to see what's current. The default "rtv" module provides an automatic random tour of what's available.
Here are some stills taken from some of the existing modules at the time of writing this, note these are normally animated, stills don't do them justice:
Creating new modules in rototiller is relatively easy.
A minimal, non-threaded stub module is provided on the stub branch of the git repo for convenience. Feel free to build upon this branch with your own rendering algorithm, name, and license.
For concurrent rendering, a prepare_frame function must be implemented. This function supplies the fragmenter to be used in dividing frames into subfragments dispatched to render_fragment on the various per-CPU threads. Some generic fragmenters are provided as a convenience, but modules must still wire these up as desired from their prepare_frame. See existing modules for guidance.
Modules are not required to be threaded. If a module only provides a render_fragment function, and nothing else, it is perfectly valid but will be executed serially with its render_fragment function called just once per frame using a single, frame-sized fragment. This is the simplest form of module, but cannot take advantage of multiple CPUs, severely limiting the real-time possibilities.
If you've made a module you'd like to share, email it to me in the form of a
patch generated with `git format-patch`. Provided it's stable and unique
relative to the existing modules, odds are good I'll merge it into the
upstream rototiller collection.
You can find my @pengaru.com email address in the commit history.
`git clone git://git.pengaru.com/rototiller`
Browse on web