| Age | Commit message (Collapse) | Author |
|---|
|
This adds an api for maintaining a list of pre-render module
contexts on-stream which will be rendered via til_stream_render()
before rendering hte main module context on the stream that's
been set via til_stream_set_module_context().
til_stream_add_pre_module_context()
til_stream_del_pre_module_context()
are the new functions, no references are taken for now (but
comments note the possibility of adding that)
This is just a preparatory commit, no real functional difference.
|
|
til_stream_render() bumps the frame counter, so there's no more
need for a discrete frame start mechanism.
|
|
This introduces a concept of a stream's module context, which is
used to render the stream via til_stream_render().
The context is set using til_stream_set_module_context(), but at
this time no reference is taken - it just puts the context into
the stream for use by the render calls. The caller is
responsible for ensuring it persist as long as the stream uses
it.
This is a preparatory commit for implementing pre/post render
module contexts that get hooked into a stream. The impetus for
this is supporting background music via modules like playit,
without requiring stuff like rkt scenes to always include the bgm
context in the scene's module context heirarchy.
Nothing is functionally different here, the commit only adds the
new interfaces for setting the context and rendering via stream
instead of til_module_render() of the context you'd now set on
the stream.
|
|
Until now everything interested in audio just used a plain getter
on the stream to get at the context.
But with how things work currently, audio is always left in a
paused state until explicitly unpaused. This works fine with
modules/rkt, which manages pause/unpause explicitly. When
there's nothing like modules/rkt in charge though, the audio just
sits stuck paused. Meaning if you do some simple thing like
--module=playit, it won't ever get unpaused.
With this commit, something like modules/rkt takes control of the
stream's audio context, in a way that prevents anything else from
taking control of the same context on the same stream. That
enables having main try take control of the audio context after
creating the module contexts, then in the rendering thread ensure
the audio is unpaused if main is in control of the audio context
and something's queueing audio frames.
For now there's no mechanism for releasing control of the audio
context. It doesn't seem appropriate to make this more elaborate
than necessary. There's basically just two use cases WRT audio:
1. Something like rkt, which takes control once for the process
and stays in control until process exit.
2. Something far simpler where nothing's taking control like
rkt, and main just needs to get things unpaused when
needed because something's generating audio frames.
|
|
Preliminary means of making the audio context available to
modules.
|
|
There are no users of this, it can come back if needed.
|
|
This needs the stream pulled in so the signature changed to
accomodate that.
Also modules/rkt was calling this conditionally which won't be
compatible with the per-frame driver race model, so always call
it to maintain the driving position every frame.
|
|
This adds til_stream_start_frame() which advances a per-stream
counter.
Subsequent commits will make use of this for implementing a
pre-frame competition for pipe ownership.
|
|
On shutdown til_stream_untap_owner() will call into the pipe_dtor
hook if set. So until now this was just (harmlessly) leaking the
rkt_pipe_t allocated by the pipe_ctor hook on the road to process
exit.
But in the interests of silencing ASAN about leaks on graceful
exit, I'm tying up these loose ends.
This dtor will also be utilized for performing a FORGET_TRACK via
Rocket once that's a thing.
While here I also got rid of the pipe_dtor return value, as it's
unused with no clear potential purpose (for now).
|
|
Preparatory commit for making til_stream_free() assert on leaked
module contexts.
|
|
trivial change
|
|
rkt needs a way to signal the end of a sequence, this will
probably get more work in the future but something simple is fine
for now
|
|
In order for modules like rkt to be able to do integrated
transitions, there must be a way for discovering existing module
contexts by path and using them for rendering in new
compositions.
This is a first stab at something along those lines. The whole
multiple contexts at the same path pattern has been partially
handled in this implementation, but I think it will just be going
away and checkers::fill_module refactored to not do that.
|
|
When all the stream encapsulated were pipes/taps, naming was less
precise. With module contexts in the process of being registered
in the stream, there's a need to distinguish things more.
This is a largely mechanical naming change...
|
|
This changes til_setup_t* from optional to required for
til_module_context_t creation, while dropping the separate path
parameter construction and passing throughout.
|
|
There needs to be a way for a meta module like rocket to take
ownership of pipes immediately upon instantiation. Since the
pipes are created on demand as they become tapped by the modules
using htem, the simplest way to do this is to register some
callbacks with the ability to intercept the pipe creation in
terms of ownership and driving tap control etc.
This commit forms a minimal implementation of that, with the
ability to have a single intercepter hooked into a given stream.
It's a first-come-first-served situation, but that should suffice
for now since the rocket meta module would be the entrypoint for
such constructions. It then calls into another module to produce
on the stream, after it'll already have its hooks registered.
There might be a need for stacking hooks to let multiple modules
control pipes. GNU Rocket for instance only deals with
floats/doubles, and doesn't make it particularly easy to work on
higher order concepts like say orbiting a vector around a point
spatially. It might make sense to allow compositing of editors
where there's rocket controlling the simple floats, and another
doing dimensional/spatial stuff, with separate stacked meta
modules accomodating those editors. But that's putting the cart
before the horse, let's do the stupid simple thing for now and
see what this is like.
|
|
Some clarifications
|
|
|
|
In order to implement something like a rocket module there needs
to be a way to iterate the pipes in the stream, and take
owernship of them when not already owned by rocket.
The way rocket's API works is you lookup tracks by name at
runtime. The rocket module will be a meta module that calls into
another module for rendering, arbitrarily configured via a rocket
setting a la checkers::fill_module.
So it won't be until the underlying modules do some rendering
that their taps get their respective pipes established in the
stream. Then the rocket module can look at all the pipes and for
any it doesn't own yet, it can get the tracks for those names and
take ownership while stowing the track handle in owner_foo for
the pipe.
While iterating all the pipes, the pipes already owned will have
the tracks readily available which can produce the values to
stick in the tap.
Something like that anyways, the til_stream_t api changes in this
commit are all preparatory for a rocket module.
|
|
It seems likely that pipe owners will need not only a way to
differentiate themselves via the owner pointer, but also
somewhere to register a pipe-specific reference.
There probably needs to be a result pointer added for storing the
owner_foo when the owner taps, so the owner can make use of it.
|
|
Just some banal paperwork...
|
|
Until now there's just been a forward declared type for
til_fb_fragment_t.stream's type, and it's been completely unused.
The purpose of the stream is to provide a continous inter-frame
object where information can be stored pertaining to the stream
of frames.
Right now, that information is limited to emergent "pipes" formed
by using taps against a given stream. Taps at new paths in the
stream become added as pipes for those paths, with the
responsible tap hooked in as the driving tap. Taps at existing
paths become diverted to the driving taps, enabling potential for
external drivers for tapped variables.
This commit only adds the implementation, nothing is actually
using it yet.
|
