summaryrefslogtreecommitdiff
path: root/src/Makefile.am
AgeCommit message (Collapse)Author
2021-02-14*: split rototiller.[ch] into lib and mainVito Caputo
This is a first approximation of separating the core modules and threaded rendering from the cli-centric rototiller program and its sdl+drm video backends. Unfortunately this seemed to require switching over to libtool archives (.la) to permit consolidating the per-lib and per-module .a files into the librototiller.a and linking just with librototiller.a to depend on the aggregate of libs+modules+librototiller-glue in a simple fashion. If an alternative to .la comes up I will switch over to it, using libtool really slows down the build process. Those are implementation/build system details though. What's important in these changes is establishing something resembling a librototiller API boundary, enabling creating alternative frontends which vendor this tree as a submodule and link just to librototiller.{la,a} for all the modules+threaded rendering of them, while providing their own fb_ops_t for outputting into, and their own settings applicators for driving the modules setup.
2021-02-08modules/swarm: implement a particles swarm moduleVito Caputo
Just a fun little swarm based loosely on 80s-era boids It would be interesting to make stuff like the # of particles and the weights runtime configurable, or exposed as knobs. Using a Z-buffer for occlusions and perhaps shading by depth might make a significant improvement on the visual quality. It might also be interesting to draw the particles as lines connecting their current position with their previous, instead as pixels. Or fat pixels like stars...
2021-01-17plato: regular convex polyhedrons in 3DVito Caputo
plato implements very simple software-rendered 3D models of the five convex regular polyhedra / Platonic solids Some TODO items: - procedurally generate vertices at runtime - add hidden surface removal setting (Z-buffer?) - add flat shaded rendering setting - add gouraud shading, maybe phong too? - show dual polyhedra This was more about slapping together a minimal 3D wireframe software renderer than anything to do with polyhedra, convex regular polyhedra just seemed like an excellent substrate since they're so simple to model.
2020-09-25modules/compose: add a rudimentary compositing moduleVito Caputo
--module=compose,layers=first:second:third:... this draws the named modules in the order listed, overdrawing the output of the previous layers in a cumulative fashion.
2020-02-03libs/sig: introduce a signal generator abstractionVito Caputo
This adds a small framework of sorts for creating and composing signal generators. Two generators are implemented at this time; sig_ops_sin and sig_ops_mult sig_ops_sin accepts a hz variable and will produce a sine wave of that frequency. sig_ops_mult accepts two sig_t generators and multiplies their outputs Callers may construct their own sig_ops_t ops structs and supply them to sig_new(), but it's expected that libs/sig will grow a collection of commonly used generators which can then be used by simply passing their sig_ops_$foo to sig_new(). See the test code at the bottom of libs/sig/sig.c for some contrived sample usage. Note by composing multiple sig_ops_sin generators with a sig_ops_mult generator, one can already easily construct a synth-like LFO generator. Some obvious todos are to add triangle/sawtooth/square wave generators. More compositional generators may be interesting as well, like additive and subtractive for example. Those will need to implement clipping, as it's expected that the generators *always* stay within unity (0-1). No modules use this yet, but I expect to wire this up to rtv for driving knobs.
2020-01-26knobs: add experimental rudimentary knobs APIVito Caputo
This is intended for modules to expose bindings for floats affecting rendering output that may be varied at runtime frame-to-frame. See the comment in knobs.h for more information. This commit only introduces the concept, no modules utilize it yet.
2020-01-08modules/drizzle: add a classic 2D raindrops visVito Caputo
Using the new puddle lib throw some raindrops on the framebuffer
2020-01-08libs/puddle: add a classic 2D raindrop sim libVito Caputo
These were commonish in the 90s demo days, done as a library to encourage use by different modules. You can simply render this directly onto a frame buffer like the old days, or sample it as a height map or density field for more complex compositions.
2020-01-06spiro: spirograph emulatorPhilip J Freeman
This commit adds a module that emulates a spirograph
2019-11-25meta2d: add a classic 2D metaballs moduleVito Caputo
2019-11-24montage: add montage moduleVito Caputo
This is somewhat unfinished as it uses the generic tiled fragmenter that's not interested in appearances but prioritizes total coverage and simplicity. Montage should have its own tiler that can produce non-square and even non-uniform tile dimensions, prioritizing filling the screen with mostly-uniform tiles. But that's a TODO item, this is good enough for now and exercises some fragment details previously irrelevant and often ignored/broken in modules. The pixbounce module in particular seems completely broken with small fragment sizes.
2019-11-18swab: add a perlin noise visualizationVito Caputo
This maps a different Z-slice through the noise field to each color channel. The slices are moved up and down through the field over time, and the size of the area each color samples is tweaked a bit to make them less coherent with the noise field cells. It could be improved, but I think the output is already neat enough to be worth sharing.
2019-11-18libs/din: add a perlin noise implementationVito Caputo
This is a 3D noise field addressed as a unit cube. The caller supplies the resolution of the noise field in three dimensions. I've just pulled in my v3f.h here, but it probably makes sense to later on move vector headers into libs/ and share them. Later. It's called din as in noise, because it's shorter than perlin and noise.
2019-11-16libs/txt: add minimal ascii text rendererVito Caputo
This is as basic as it gets, the only fanciness is it recognizes newlines and supports horizontal and vertical justification. As this is intended to be run from potentially threaded fragmenter renderers, it receives a fragment and *frame* coordinates for the text to be rendered. If the text doesn't land in the given fragment, nothing gets drawn. Currently this is not optimized at all. There's a stubbed out rect overlap test function which could be used to avoid entering the text rendering loop for fragments with zero overlap, that's an obvious low-hanging fruit optimization. After that, skipping characters that don't overlap would be another obvious thing. As-is the text render loop is always entered and the bounds-checked put pixel helper is used. So every fragment will incur the cost of rendering the full string, even when it's not visible. For the rtv captions this isn't a particularly huge deal, but stuff to improve upon in the future.
2019-11-16libs/ascii: add a basic mono bitmap ascii charsetVito Caputo
The rtv module needs to show some captions, so I'm adding a minimal bitmap ascii text renderer.
2019-11-14snow: add a simple tv snow / white noise moduleVito Caputo
I wanted to add some noise to the rtv module and figured why not just add a snow module and make rtv pass through it briefly when switching modules. It's not interesting by itself, but as more composite/meta modules like rtv get made it might be handy beyond rtv.
2019-11-14rtv: implement "Rototiller TV" rendererVito Caputo
This is sort of a meta renderer, as it simply renders other modules in its prepare_frame() stage. They're still threaded as the newly public rototiller_module_render() utilizes the threading machinery, it just needs to be called from the serial phase @ prepare_frame(). I'm pretty sure this module will leak memory every time it changes modules, since the existing cleanup paths for the modules hasn't needed to be thorough in the least. So that's something to fix in a later commit, go through all the modules and make sure their destroy_context() entrypoints actually cleans everything up. See the source for some rtv-specific TODOs.
2019-11-10build: build contributed pixbounce moduleVito Caputo
2019-10-14modules/flui2d: add 2D fluid dynamics simulationVito Caputo
This implements near verbatim the code found in the paper titled: Real-Time Fluid Dynamics for Games By Jos Stam It sometimes has the filename GDC03.PDF, or Stam_fluids_GDC03.pdf The density field is rendered using simple linear interpolation of the samples, in a grayscale palette. No gamma correction is being performed. There are three configurable defines of interest: VISCOSITY, DIFFUSION, and ROOT. This module is only threaded in the drawing stage, so basically the linear interpolation uses multiple cores. The simulation itself is not threaded, the implementation from the paper made no such considerations. It would be nice to reimplement this in a threaded fashion with a good generalized API, then move it into libs. Something where a unit square can be sampled for interpolated densities would be nice. Then extend it into 3 dimensions for volumetric effects...
2018-12-30modules/submit: add cellular automata game moduleVito Caputo
This module displays realtime battle for domination simulated as 2D cellular automata. This is just a test of the backend piece for a work-in-progress multiplayer game idea. The visuals were kind of interesting to watch so I figured may as well merge it as a module to share. Enjoy! PS: the results can vary a lot by tweaking the defines in submit.c
2018-03-19ray: libize raytracer core, introduces src/libsVito Caputo
This is the first step of breaking out all the core rendering stuffs into reusable libraries and making modules purely compositional, consumers of various included rendering/effects libraries. Expect multiple modules leveraging libray for a variety of scenes and such. Also expect compositions mixing the various libraries for more interesting visuals.
2018-02-27build: make drm optionalChristian Hergert
2018-02-27autotools: remove vestigial ROTOTILLER_* varsVito Caputo
Fixes silly cosmetic error in configure output for checking libdrm...
2018-02-23drm_fb,sdl_fb: drop vestigial headersVito Caputo
With fb backends entirely abstracted behind fb_ops_t, this is no longer necessary.
2018-02-22sdl_fb: implement rudimentary sdl fb backendVito Caputo
This uses a simple fixed 640x480 windowed mode (for now). The SDL2 Renderer & Texture API is used for vsync-synchronized presents. There's probably excessive copying going on because the rototiller fb code manages pages and flips but SDL2 doesn't really expose low-level control of such things. This backend is quite useful for development purposes, allowing quick iteration in a windowed environment. Note this is just the backend implementation, it's dormant code but trivially activated.
2018-02-22*: embrace new generic settings paradigmVito Caputo
This should probably be split into multiple commits, but for simplicity sake it's all cut over at once. drm_fb.c sees major changes, migrating the remaining drm-specific bits from drmsetup into it, behind the settings API. rototiller.c sees a bunch of scaffolding surrounding the settings API and wiring it up into the commandline handling and renderers and video backends. fb.[ch] see minor changes as settings get plumbed to the backend drmsetup.[ch] goes bye bye
2018-02-20setup: add simple stdio setup_interactively()Vito Caputo
Preliminary means for interactively configuring settings and defaults
2018-02-20settings: introduce abstract settingsVito Caputo
Settings will be used to express configurable parameters in the rendering modules and fb backends. The goal is to address both commandline argument setting of parameters, automatic use of defaults, as well as interactive configuration including the outputting of the resulting settings in a form usable as a commandline for future reuse. Since settings can be numerous and highly varied from one module or backend to another, a form similar to the Linux kernel's cmdline or QEMU's approach has been adopted. For example, a complete DRM backend, card selection and config would be: rototiller --video=drm,dev=/dev/dri/card0,connector=LVDS-1,mode=1024x768@60 If any of the above were omitted, then the missing settings would be interactively configured. If you added --defaults, then any omissions would be automatically filled in with the defaults. i.e. rototiller --video=drm,dev=/dev/dri/card4 --defaults would use the preferred connector and mode for that card. rototiller --video=drm --defaults would do the same but also default to the /dev/dri/card0 path. for brevity, I omitted rendering modules from above, but the same approach applies simply to --module=: rototiller --module=sparkler --video=drm --defaults If you ran rototiller without any arguments, then a fully interactive setup would ensue for module and video. If you ran rototiller with just --defaults, then everything is defaulted for you. A default rendering module will be used (the original roto renderer, probably). Note that this commit only adds scaffolding to make this possible, none of this is wired up yet.
2018-01-01drm_fb: implement drm fb backendVito Caputo
Largely mechanical copying of the drm code into the new fb_ops_t abstraction. Dormant for now.
2017-04-22rototiller: add threaded renderingVito Caputo
This is a simple worker thread implementation derived from the ray_threads code in the ray module. The ray_threads code should be discarded in a future commit now that rototiller can render fragments using threads. If a module supplies a prepare_frame() method, then it is called per-frame to prepare a rototiller_frame_t which specifies how to divvy up the page into fragments. Those fragments are then dispatched to a thread per CPU which call the module's rendering function in parallel. There is no coupling of the number of fragments in a frame to the number of threads/CPUs. Some modules may benefit from the locality of tile-based rendering, so the fragments are simply dispatched across the available CPUs in a striped fashion. Helpers will be added later to the fb interface for tiling fragments, which modules desiring tiled rendering may utilize in their prepare_frame() methods. This commit does not modify any modules to become threaded, it only adds the scaffolding.
2017-02-12julia: add a morphing Julia set rendererVito Caputo
This is unoptimized, with a palette slapped together in vim, but still pretty neat!
2017-02-07plasma: add a plasma rendererVito Caputo
2017-01-18*: move source into src/ subdirVito Caputo
Restoring some organizational sanity since adopting autotools.
© All Rights Reserved