| Age | Commit message (Collapse) | Author |
|---|
|
This introduces a stricter coupling and requirement for modules
supplying a fragmenter in their prepare_frame() to only receive
fragments produced by *their* fragmenter at their render_fragment().
When modules don't explicitly perform any fragmenting they can't
really make much use of this number as it will reflect an arbitrary
fragmenting pass's perspective.
But when modules do perform their own frame fragmenting, they can
assume any fragment supplied to their render function will have been
generated by it. This needs to be enforced a bit in the code.
The current use case is montage using a fragmenter for tiling the
montage in a threaded render. The fragment numbers map to the
modules to be rendered in the tiles. As long as modules can assume
their fragmenter will always be what produces their fragments, this
is perfectly fine.
|
|
The put_pixel helpers really needed reworking to properly handle
subframe fragments modules like montage will utilize. I had the
stride present as it's convenient for a number of modules that
maintain a buf pointer as they progress down a row, but the pitch
is more applicable to put_pixel for scaling the y coordinate.
Now there's both pitch and stride so everyone's happy with what's
most convenient for their needs.
|
|
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 makes the visualization more interesting by adding more variety.
|
|
To facilitate random setting of these flexible string-oriented
settings, support a random helper supplied with the description.
This helper would return a valid random string to be used with the
respective setting being described.
Immediate use case is the rtv module, which also gets fixed up to
use it in this commit.
|
|
This is just a quick stab at randomizing settings, only multiple
choice setings are randomized currently.
For modules with settings, a new Settings: field is added to the
caption showing the settings as the arguments one would pass to
rototiller's module argument.
|
|
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.
|
|
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.
|
|
|
|
|
|
Consolidate the time() calls in setup_next_module() by using a now
variable.
|
|
This broke when snow was added.
|
|
The idea is to have captions similar to how MTV did back in the 80s.
It'd be nice to make the text resolution independent, but this is a
good first stab for an afternoon of tooling around.
|
|
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.
|
|
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.
|
|
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.
|
|
Use setting_desc_check() before storing a value.
|
|
This area needs more work, but this helps a little.
|
|
|
|
Rudimentary setting value checking against the description.
For now it just enforces the multiple-choice stuff, I'm undecided
on the regex support for now. It'd just be nice to throw some
more informative errors when cli arguments are incorrect for things
like fullscreen=yes when it only knows fullscreen=on/off.
|
|
More accurate name, this variable doesn't contain defaults, it
controls the use of defaults.
|
|
|
|
This uses the newly added snow module as a transition between modules
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
This removes the submit-softly module, instead using a runtime
setting to toggle bilinear interpolation on the submit module.
|
|
|
|
|
|
|
|
Viscosity and diffusion are supported, it'd be neat to add a
configurable size (the ROOT define) for the flow field in the
future.
I didn't go crazy here, it's just a list of orders of magnitude you
choose from for each. It'd probably be more interesting to change
this into a single knob with descriptive names like "smoke" "goop"
"water" mapping to a LUT.
|
|
Just a convenience thing as settings are all string-centric and
callers like modules will probably have stuff like literal numbers
defined for defaults which need to be stringified for setting_desc_t.
|
|
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.
|
|
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.
|
|
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.
|
|
s/Joe/Jos/, I should wear my glasses more.
|
|
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...
|
|
Missed the sentinel, oops
|
|
|
|
Remove the silly kludge avoiding peripheral cells
|
|
|
|
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.
|
|
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.
|
|
|
