summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-02-21settings: fixup win32 strndupVito Caputo
Using strlen on the input string isn't safe; it may be unterminated
2020-02-10libs/sig: triangle wave; sig_ops_tri / sig_new_tri()Vito Caputo
Added a triangle wave
2020-02-04libs/sig: square wave; sig_ops_sqr / sig_new_sqr()Vito Caputo
This builds minimally upon the existing sine wave code, just use the sign to drive the signal high or low. Wikipedia shows a third state for 0 values, but that's for a -1..+1 signal. I'm producing all 0-1 signals as it's more convenient for this application, but it seems like it would be awkward to return .5f for the 0 case. So 0 is being treated as just another positive value; high.
2020-02-04libs/sig: add sig_new_$op wrappersVito Caputo
Provides improved ergonomics when using the bulitin ops, and much appreciated arity and type checking.
2020-02-03libs/sig: add sig_ref()Vito Caputo
Added some rudimentary refcounting so sig_t's can be readily shared by multiple sig_t's.
2020-02-03libs/sig: remove ticks_ms modulo in sig_ops_sinVito Caputo
Seems broken, fix it correctly later.
2020-02-03libs/sig: fix sig_ops_sin hz floor checkVito Caputo
off by one order of magnitude
2020-02-03libs/sig: add sig_ops_invVito Caputo
map 0-1 inputs to their inverse 1-0
2020-02-03libs/sig: s/sig_ops_inv/sig_ops_neg/gVito Caputo
Rename inv->neg, preparation for a new sig_ops_inv for inverting 0..1 to 1..0
2020-02-03libs/sig: add sig_ops_divVito Caputo
Included a little hack to defend against divide by zero, seems reasonable given the intended use cases.
2020-02-03libs/sig: add sig_ops_{add,sub}Vito Caputo
2020-02-03libs/sig: add sig_ops_expand convenienceVito Caputo
This is a specialized version of sig_ops_scale which assumes a min..max range of -1..+1 nvidia register combiners docs describe this operation as "expand normal", and they have several variants, but I don't want to go too crazy here right now. Plain expand it is.
2020-02-03libs/sig: add sig_ops_scale w/test exampleVito Caputo
This assumes the input value is always 0-1, but may be used to produce values in any signed range, mapped linearly to the input.
2020-02-03libs/sig: add sig_ops_inv for additive inverseVito Caputo
aka negation
2020-02-03libs/sig: fixup sig_ops_sin to stay within 0-1Vito Caputo
The whole idea was to produce values 0-1, except of course sig_ops_{mult,const} where one could deliberately get out of these bounds. Everything else should stay within 0-1 as it makes everything much more composable.
2020-02-03libs/sig: add sig_ops_{max,min}Vito Caputo
Supply two sig_t *'s: a, b
2020-02-03libs/sig: add sig_ops_clampVito Caputo
Supply three sig_t *'s: value, min, max
2020-02-03libs/sig: add ops_{abs,ceil,floor,pow,round}Vito Caputo
Added a simple test exercising pow and round
2020-02-03libs/sig: consideration for sig_t.ctxt alignmentVito Caputo
The flexible array of void *'s would just align to a pointer, which may not be safe for all members of whatever gets shoved in here. In an effort to make it more robust, make it an array of a junk drawer union of types.
2020-02-03libs/sig: update comment for ops_lerp_initVito Caputo
Comment was vestigial from ops_mult.c which ops_lerp.c was derived from.
2020-02-03libs/sig: add sig_ops_rand random generatorVito Caputo
(Ab)uses rand_r by feeding ticks_ms as seedp for pseudo-random numbers deterministically derived from ticks_ms.
2020-02-03libs/sig: remove math.h include from ops_const.cVito Caputo
2020-02-03libs/sig: cosmetic rearrangementVito Caputo
Make sig_ops_t.destroy functions consistently after init, no functional changes.
2020-02-03libs/sig: add sig_ops_lerp linear interpoplationVito Caputo
This takes three signals; a, b, and t t controls the weight interpolating between a and b, they all key off the same time ticks_ms.
2020-02-03libs/sig: convert ops_sin_ctxt_t.hz to a sig_t *Vito Caputo
Now hz can vary with time as well...
2020-02-03libs/sig: intrduce sig_ops_constVito Caputo
The simplest of signals: a constant value. The immediate need for this is to convert ops_sin_ctxt_t.hz to another sig_t enabling varying hz with time, while still being able to have a fixed hz as well.
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-26rototiller: move rototiller_module_t.setup()Vito Caputo
Cosmetic change, put setup with the other function pointers.
2020-01-25modules/flui2d: derive r from ticksVito Caputo
Modulo ticks by 2*M_PI to preserve precision by constraining the float to 2*M_PI radians.
2020-01-25rototiller: initialize start_tvVito Caputo
Missed this!
2020-01-25rototiller: s/t_offset/ticks_offset/gVito Caputo
Make naming consistent
2020-01-25rototiller: introduce ticks and wire up to modulesVito Caputo
Most modules find themselves wanting some kind of "t" value increasing with time or frames rendered. It's common for them to create and maintain this variable locally, incrementing it with every frame rendered. It may be interesting to introduce a global notion of ticks since rototiller started, and have all modules derive their "t" value from this instead of having their own private versions of it. In future modules and general innovations it seems likely that playing with time, like jumping it forwards and backwards to achieve some visual effects, will be desirable. This isn't applicable to all modules, but for many their entire visible state is derived from their "t" value, making them entirely reversible. This commit doesn't change any modules functionally, it only adds the plumbing to pull a ticks value down to the modules from the core. A ticks offset has also been introduced in preparation for supporting dynamic shifting of the ticks value, though no API is added for doing so yet. It also seems likely an API will be needed for disabling the time-based ticks advancement, with functions for explicitly setting its value. If modules are created for incorporating external sequencers and music coordination, they will almost certainly need to manage the ticks value explicitly. When a sequencer jumps forwards/backwards in the creative process, the module glue responsible will need to keep ticks synchronized with the sequencer/editor tool. Before any of this can happen, we need ticks as a first-class core thing shared by all modules. Future commits will have to modify existing modules to use the ticks appropriately, replacing their bespoke variants.
2020-01-23stars: mess with the starfieldPhilip J Freeman
This commit adds some fun features to the starfield: - normalize aspect ratio to fragment size - rolling viewport - rotating viewport (with rate option)
2020-01-12libs/ray: decouple film and frame dimensionsVito Caputo
The existing code conflated the rendered frame dimensions with what's essentially the virtual camera's film dimensions. That resulted in a viewing frustum depending on the rendered frame dimensions. Smaller frames (like in the montage module) would show a smaller viewport into the same scene. Now the view into the scene always shows the same viewport in terms of the frustum dimensions for a given combination of focal_length and film_{width,height}. The rendered frame is essentially a sampling of the 2D plane (the virtual film) intersecting the frustum. Nothing is done to try enforce a specific aspect ratio or any such magic. The caller is expected to manage this for now, or just ignore it and let the output be stretched when the aspect ratio of the output doesn't match the virtual film's aspect ratio. In the future it might be interesting to support letter boxing or such things for preserving the film's aspect ratio. For now the ray module just lets things be stretched, with hard-coded film dimensions of something approximately consistent with the past viewport. The ray module could make some effort to fit the hard-coded film dimensions to the runtime aspect ratio for the frame to be rendered, tweaking things as needed but generally preserving the general hard-coded dimensions. Allowing the frustum to be minimally adjusted to fit the circumstances... that might also be worth shoving into libray. Something of a automatic fitting mode for the camera.
2020-01-08modules/flui2d: static-ify flui2d_setup()Vito Caputo
2020-01-08README: add drizzle to modules listVito Caputo
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-06rtv: rework randomized module selectionVito Caputo
Switch to working through the set of modules in a random order, randomizing the order once per cycle. This way no modules get starved for display, which was pretty common in the old method.
2020-01-06README: add spiro to modules listVito Caputo
2020-01-06stars: fat starsPhilip J Freeman
draw stars as circles that get larger as the approach the camera
2020-01-06spiro: spirograph emulatorPhilip J Freeman
This commit adds a module that emulates a spirograph
2020-01-03montage: bump Y tiles when root has large fractionVito Caputo
Ideally the number of modules can tile without leaving gaps, but as rototiller evolves over time modules are added piecemeal so try accomodate those awkward layouts.
2019-12-30montage: re-enable stars and pixbouncePhilip J Freeman
2019-12-30pixbounce: fix bugs, refactor for resizingPhilip J Freeman
- fix bug for square fragments - use create and destroy context hooks instead of globals - refactor to allow fragment resizing - handle extremely small fragments gracefully
2019-12-30stars: fix bugs, big refactor for resizingPhilip J Freeman
- use a context not globals - use floats and a "unit cube" to simulate the starfield
2019-12-18modules/rtv: remove stale random settings commentVito Caputo
Since 7a77cc1a landed this is no longer true, the .random member will be used to support randomizing non multiple-choice settings.
2019-12-18libs/din: fix scaling overflow, add assertsVito Caputo
Phil reported a crash in swab, illuminating an overflow in how the unit cube was being scaled to the noise field dimensions. Added some asserts enforcing critical assumptions as well, though it will probably cost some FPS in din-heavy modules like swab.
2019-11-26montage: add (threaded) to descriptionVito Caputo
While the montage doesn't deeply thread the per-tile/module rendering, the per-frame rendering is threaded with a work unit granularity of every module's tile. Meaning every module renders its tile in a single thread, but the tiles are all rendered in parallel. For the most part this works, and will only work better as more modules are added to rototiller increasing the granularity. In the mean time it's a bit coarse and some modules can be a lot more costly to render than others, and there can be a shortage of modules to schedule on idle CPUs. It would be an interesting task to try make each module's tile get subfragmented elastically. I didn't make any attempt to do that, but it might even be worthwhile on hidpi screens where even those small tiles may have a whole lot of pixels, especially on manycore CPUs.
© All Rights Reserved