| Age | Commit message (Collapse) | Author |
|---|
|
Rename inv->neg, preparation for a new sig_ops_inv for inverting
0..1 to 1..0
|
|
Included a little hack to defend against divide by zero, seems
reasonable given the intended use cases.
|
|
|
|
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.
|
|
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.
|
|
aka negation
|
|
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.
|
|
Supply two sig_t *'s: a, b
|
|
Supply three sig_t *'s: value, min, max
|
|
Added a simple test exercising pow and round
|
|
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.
|
|
Comment was vestigial from ops_mult.c which ops_lerp.c was derived
from.
|
|
(Ab)uses rand_r by feeding ticks_ms as seedp for pseudo-random
numbers deterministically derived from ticks_ms.
|
|
|
|
Make sig_ops_t.destroy functions consistently after init, no
functional changes.
|
|
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.
|
|
Now hz can vary with time as well...
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
I'd like the output to fill the range -1..+1, but it's not doing that and I'm
uncertain on what exactly the scaling factor should be here.
In one reference a factor of 1/sqrt(.75) is specified, but in my tests that
doesn't seem to quite fill the range but it doesn't seem to blow it out so
it seems safe for now.
|
|
|
|
This requires a forward declaration of v3f_t and changing din()
to take a v3f_t *.
The swab module needed updating to supply a pointer type and a
v3f_t definition.
This is being done so din.h users can have their own v3f
implementations. I might consolidate all the duplicated vector
code scattered throughout the libs and modules, but for now I'm
carrying on with the original intention of having modules be
largely self-contained. Though the introduction of libs like
ray and din has certainly violated that a bit already.
|
|
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.
|
|
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.
|
|
The rtv module needs to show some captions, so I'm adding a minimal
bitmap ascii text renderer.
|
|
color banding has been quite visible, and somewhat expected with a
direct conversion from the linear float color space to the 8-bit
integral rgb color components.
A simple lookup table is used here to non-linearly map the values, table
generation is taken from Greg Ward's REAL PIXELS gem in Graphics Gems II.
|
|
Missed the sentinel, oops
|
|
|
|
Just making things consistent, also dropping unnecessary player
assert from submit module. Future libs/grid may explore using
the "unassigned" zero player in taken calls for unassigning
cells like in simultaneously taken collision scenarios.
|
|
Prep for adding a new module displaying a cellular automata
based on the grid component from a multiplayer game I'm working
on.
|
|
Oops! This should have made it into b5bc96, been sitting
in my tree.
|
|
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.
|
