| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Mechanical change removing abbreviation for consistency
|
|
Mostly mechanical change, though threads.c needed some jiggering to
make the logical cpu id available to the worker threads.
Now render_fragment() can easily addresss per-cpu data created by
create_context().
|
|
Back in the day, there was no {create,destroy}_context(), so passing
num_cpus to just prepare_frame made sense. Modules then would
implicitly initialize themselves on the first prepare_frame() call
using a static initialized variable.
Since then things have been decomposed a bit for more sophisticated
(and cleaner) modules. It can be necessary to allocate per-cpu data
structures and the natural place to do that is @ create_context(). So
this commit wires that up.
A later commit will probably have to plumb a "current cpu" identifier
into the render_fragment() function. Because a per-cpu data structure
isn't particularly useful if you can't easily address it from within
your execution context.
|
|
This simplifies the bsp code while addressing cleanup
|
|
This assert prevents using the chunker for efficient freeing,
maybe in the future add a flag for toggling this but for now
it can just be commented out.
|
|
particles_free() didn't do all the necessary cleanup.
bsp_free() remains mostly unimplemented. I think this wasn't done at
the time because I was thinking bsp.c should use the chunker, then
cleanup is just a matter of freeing the chunker instead of traversing
the bsp.
|
|
Fixes silly cosmetic error in configure output for checking libdrm...
|
|
Mechanical cosmetic change
|
|
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.
|
|
Prior to rototiller_module_t these headers were included
and the module-specific render functions called directly.
That's no longer the case, these files are irrelevant today.
|
|
This moves most of the particle system maintenance into the serially
executed sparkler_prepare_frame(), divides the frame into ncpus
fragments, and leaves the draw to occur concurrently.
The drawing must still currently process all particles and simply skips
drawing those falling outside the fragment.
Moving more of the computation out of prepare_frame() and into
render_fragment() is left for future improvements, as it's a bit
complex to do gainfully.
|
|
should_draw_expire_if_oob() assumed the fragment represented the entire
frame. Instead, return 0 if the coordinates are outside the fragment,
but only reset longevity if outside of the frame.
If sparkler goes threaded in the drawing, this would result in threads
simply skipping particles outside the fragment. The longevity reset
occurring in all threads appears suspicious but should be benign since
they all write the same thing - 0.
|
|
|
|
The burst particle abused a zero mass to circumvent the effects of aging.
Instead use an explicit virtual flag to suppress aging, change busrt_cb
to ignore all virtual particles instead of only its center. Previously
burst_cb would thrust other bursts like any other particle, and this was
incorrect. Now burst centers are always stationary, even when they overlap
other bursts.
|
|
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.
|
|
Adding more context to the name in anticipation of adding a prepare_frame()
method to the module struct.
|
|
Make consistent with the source directory structure naming.
|
|
|
|
|
|
|
|
discards draw_pixel(), introduces helpers.h and a convenience
function for bounds checking and oob extermination. Move makergb
to helpers.h, draw.h gets removed in a later commit.
|
|
If a z-buffer is added these checks will need to be done independent from and
prior to drawing. Also it's silly to makergb() pixels which can't be drawn.
|
|
The relative path broke out-of-tree builds.
Previously the following:
$ mkdir /tmp/foo
$ cd /tmp/foo
$ ~/src/rototiller/configure
$ make
Would fail to compile unable to locate the headers in
~/rototiller/src
This fixes it.
|
|
Restoring some organizational sanity since adopting autotools.
|
