summaryrefslogtreecommitdiff
path: root/src/rototiller.c
AgeCommit message (Collapse)Author
2019-11-16rototiller: make rtv the default moduleVito Caputo
Also sort the modules alphabetically. Now that the major memory leaks are addressed (sparkler), make the rtv module the default since it gives the user an automated tour of all the modules. Explicit module use is more aimed at tinkerers playing with a specific module's code either creating their own or modifying an existing one, but isn't really desirable as the default flow.
2019-11-15rototiller: print setup error causeVito Caputo
This area needs more work, but this helps a little.
2019-11-15rototiller: s/defaults/use_defaults/gVito Caputo
More accurate name, this variable doesn't contain defaults, it controls the use of defaults.
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-14rototiller: add some public module interfacesVito Caputo
Adds: rototiller_lookup_module() rototiller_get_modules() rototiller_module_render() there should probably be more helpers for dealing with context create and destroy, but this is enough for some experimentation.
2019-11-10roto: drop roto64, turning roto32 back into rotoVito Caputo
Initially I was going to make 32 vs. 64 be a setting, but decided now that SDL is supported it's fairly likely there will be odd fb dimensions (arbitrary window sizes). Since this never really brought anything of significant value, just drop the version that mostly just demonstrated how to pack multiple pixels into a single u64 write to the framebuffer more than anything else.
2019-11-10submit: replace submit-softly with bilerp settingVito Caputo
This removes the submit-softly module, instead using a runtime setting to toggle bilinear interpolation on the submit module.
2019-11-10rototiller: wire up contributed pixbounce moduleVito Caputo
2019-11-10rototiller: add rototiller_module_t.setup()Vito Caputo
Wire up support for module settings, yes it's that small a change. I've forward-declared the settings related types in rototiller.h, if a module wants to actually wire up the .setup() method they'll need to include settings.h.
2019-11-10settings: s/setting_desc_new/setting_desc_clone/Vito Caputo
Slight refactor to make call sites less annoying. Now takes a (setting_desc_t *) instead of the members as discrete parameters, and returns an errno on error so callers can simply propagate error codes out rather than having to get access to errno defines, check for NULL and return -ENOMEM etc. It also makes the call sites self documenting by employing designated initializers in compound literals for the supplied setting_desc_t. This is in prep for runtime-configurable module settings.
2019-11-10rototiller: setup_from_args() has defaults alreadyVito Caputo
I think passing this separately is vestigial from before there was an args struct encapsulating everything. In the future there might be some defaults discretion supported to say use defaults for module settings but not video, or vice versa. So get rid of this pointless parameter in prep for that, just use the args struct.
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-31modules/submit: add bilinearly-interpolated variantVito Caputo
This substantially reworks the cell sampling in submit. As a result, it's now threaded in the rendering phase which now resembles a texture mapper sans transformations. This produces a full-screen rendering rather than a potentially smaller one when the resolution wasn't cleanly divisable by the grid size. A new module, named submit-softly has also been added to expose the bilinearly interpolated variant. The transition between cells is also employing a smoothstep so it's not actually linear. The original non-interpolated version is retained as well, at the same submit module name. Some minor cleanups happened as well, nothing worth mentioning, except perhaps that the cells are now a uint8_t which is fine unless someone tries to redefine NUM_PLAYERS > 255.
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-12-06rototiller: make some local helpers staticVito Caputo
2018-02-27build: make drm optionalChristian Hergert
2018-02-26rototiller,fb: swap dispatch with page flippingVito Caputo
For the sake of sdl_fb, move page flipping into the main thread and run module render dispatch from another thread instead. This eliminates the fb flipper thread, moving its functionality into fb_flip() which synchronously consumes and performs a single flip from the same queue as before - the function is verbatim the loop body of the flipper thread. Now main() calls fb_flip() in a loop where it previously dispatched pages for rendering. Rendering dispatch is now performed in a created thread. See the comment in fb.c for more explanation of this shuffle.
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-23rototiller: drop vestigial drm includesVito Caputo
2018-02-22rototiller: make the sdl video backend the defaultVito Caputo
Since people are more likely to first run this from a GUI environment, default to SDL which should work in most situations. Then if they want they can switch to a linux console and explicitly use the drm video backend.
2018-02-22rototiller: wire up sdl video backendVito Caputo
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-20rototiller: rudimentary argv parsing scaffoldingVito Caputo
Nothing wired up yet.
2018-01-01fb: switch over to fb_ops_t abstractionVito Caputo
Remove everything drm-related from fb.c, utilizing the implementation in drm_fb.c instead.
2017-12-10rototiller: introduce module.finish_frame()Vito Caputo
Add a hook for post-render serialized frame completion, some of the renderers may have state to cleanup after rendering a frame. A future commit may change add a return value to control flow for features like multi-pass rendering within a given module. The raytracer for example may want to add concurrently executed post filters, and having a non-void return from finish_frame() would be a tidy way to tell rototiller "go back to prepare->render for this context" as many times as necessary, keeping the pass state in the context. For now its return is void however, as I just need a cleanup hook as the raytracer becomes more stateful per frame with a BIH spatial index in the works.
2017-09-14*: use fragment generatorVito Caputo
Rather than laying out all fragments in a frame up-front in ray_module_t.prepare_frame(), return a fragment generator (rototiller_fragmenter_t) which produces the numbered fragment as needed. This removes complexity from the serially-executed prepare_frame() and allows the individual fragments to be computed in parallel by the different threads. It also eliminates the need for a fragments array in the rototiller_frame_t, indeed rototiller_frame_t is eliminated altogether.
2017-08-07rototiller: remove unused variableVito Caputo
2017-04-22*: add module context machineryVito Caputo
introduces create_context() and destroy_context() methods, and adds a 'void *context' first parameter to the module methods. If a module doesn't supply create_context() then NULL is simply passed around as the context, so trivial modules can continue to only implement render_fragment(). A subsequent commit will update the modules to encapsulate their global state in module-specific contexts.
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-04-22*: /render/render_fragment/ in rototiller_module_tVito Caputo
Adding more context to the name in anticipation of adding a prepare_frame() method to the module struct.
2017-04-21*: s/renderer/module/gVito Caputo
Make consistent with the source directory structure naming.
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