| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
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
|
|
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.
|
|
Rather than require adding -Isrc/libs/$lib to every Makefile.am for
every lib used, just add -Ilibs to those makefiles and prefix the lib
dir in the #include <> header paths.
Later I'll probably just move the -Isrc/libs someplace common so the
per-module Makefile.am doesn't need to bother with this stuff.
|
|
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.
|
|
|
|
|
|
strndup is missing, add trivial implementation
signals are missing so fps counter is disabled for now
|
|
|
|
Fixes silly cosmetic error in configure output for checking libdrm...
|
|
fullscreen takes either "on" or "off"
size expects WxH arguments, defaults still to 640x480
size is optional when fullscreen=on.
Through the setup machinery, when fullscreen has been selected it will
not ask for a size - a "fullscreen desktop" mode is presumed.
However, thorugh the explicit commandline flags, a mixed mode can be
achieved by specifying both "fullscreen=on,size=WxH". This instructs
SDL to attempt a video mode switch to the specified size if needed.
I've found it to be pretty unreliable on my Xorg/linux system, unless I
choose the same video mode as my desktop is already in. Then I get what
looks like rendering into the root window or something, it's weird.
Hence there's no effort made to expose that in the interactive setup, but
it's technically possible and some effort was made to wire it up.
|
|
Since I don't use the SDL event loop, this needs to be done to keep
things happy apparently.
|
|
|
|
Depending on where cancellation was happening, locks were potentially
left held which could result in the next thread being cancelled
deadlocking.
In deferred cancellation, only cancellation points realize the
cancellation.
So one worker thread could realize the cancellation entering say,
pthread_cond_wait, and exit with the associated mutex still held.
The other thread could be in the process of returning from
pthread_cond_wait - past the cancellation point already, and get stuck
in trying to acquire the mutex as pthread_cond_wait does before
returning, because the lock was left held by the other thread.
Instead, use the cleanup handlers to unlock the mutexes, and enable
asynchronous cancellation.
This seems to eliminate the observed occasional deadlocks on destroy.
|
|
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.
|
|
With fb backends entirely abstracted behind fb_ops_t, this is
no longer necessary.
|
|
|
|
With drmsetup.c gone these are no longer used and I don't see
their use returning. Get rid of them.
|
|
The fb_ops entrypoints and their descendants are purely readers
of the settings, so constify their settings_t instances and the
operative functions which only read settings.
|
|
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.
|
|
|
|
This uses a simple fixed 640x480 windowed mode (for now).
The SDL2 Renderer & Texture API is used for vsync-synchronized presents.
There's probably excessive copying going on because the rototiller fb
code manages pages and flips but SDL2 doesn't really expose low-level
control of such things.
This backend is quite useful for development purposes, allowing quick
iteration in a windowed environment.
Note this is just the backend implementation, it's dormant code but
trivially activated.
|
|
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
|
|
Preliminary means for interactively configuring settings and defaults
|
|
Nothing wired up yet.
|
|
Settings will be used to express configurable parameters in the
rendering modules and fb backends.
The goal is to address both commandline argument setting of parameters,
automatic use of defaults, as well as interactive configuration
including the outputting of the resulting settings in a form usable as
a commandline for future reuse.
Since settings can be numerous and highly varied from one module or
backend to another, a form similar to the Linux kernel's cmdline or
QEMU's approach has been adopted.
For example, a complete DRM backend, card selection and config would be:
rototiller --video=drm,dev=/dev/dri/card0,connector=LVDS-1,mode=1024x768@60
If any of the above were omitted, then the missing settings would be
interactively configured.
If you added --defaults, then any omissions would be automatically
filled in with the defaults.
i.e.
rototiller --video=drm,dev=/dev/dri/card4 --defaults
would use the preferred connector and mode for that card.
rototiller --video=drm --defaults
would do the same but also default to the /dev/dri/card0 path.
for brevity, I omitted rendering modules from above, but the same
approach applies simply to --module=:
rototiller --module=sparkler --video=drm --defaults
If you ran rototiller without any arguments, then a fully interactive
setup would ensue for module and video.
If you ran rototiller with just --defaults, then everything is
defaulted for you. A default rendering module will be used (the
original roto renderer, probably).
Note that this commit only adds scaffolding to make this possible,
none of this is wired up yet.
|
|
Remove everything drm-related from fb.c, utilizing the implementation in
drm_fb.c instead.
|
|
Largely mechanical copying of the drm code into the new fb_ops_t
abstraction. Dormant for now.
|
|
Hooks for fb acquire/release, page allocate, free, and flip.
This should encompass everything currently needed for the drm backend,
which will move behind this abstraction in a later commit.
|
|
Tidying this up a bit in preparation of ripping out all drm-specific
stuff from fb.[ch].
Future commits will refactor fb.c to utilize an fb_ops_t for hooks
to allocate, flip, and free pages.
|
|
also const the ray_euler_t basis
|
|
|
|
This moves the per-object _prepared state into ray_render_object_$type
structs with all the rendering-related object methods switched to
operate on the new render structs.
Since the current rendering code just makes all these assumptions
about light objects being point lights, I've just dropped all the
stuff associated with rendering light objects for now. I think it
will be refactored a bit later on when the rendering code stops
hard-coding the point light stuff.
These changes open up the possibility of constifying the scene and
constituent objects, now that rendering doesn't shove the prepared
state into the embedded _prepared object substructs.
|
