summaryrefslogtreecommitdiff
path: root/src/modules/rkt/rkt.h
AgeCommit message (Collapse)Author
2023-08-29modules/rkt: drop ad-hoc last_ticks trackingVito Caputo
Commit 64a5b17 added this to til_module_context_t, so it's already being tracked now making this redundant.
2023-08-05modules/rkt: simplify setup finalizing via setup->creatorVito Caputo
This gets rid of the ad-hoc module lookups previously necessary for finalizing the nested module setups. Now that the til_estup_t.creator tracks the creating module, the rkt_scene_module_setup() wrapper can take care of finalizing.
2023-08-04modules/rkt: utilize til_module_setup_full()Vito Caputo
rkt_setup() and rkt_scener_update() had distinct implementations for scene module setup. This consolidates that where trivial to both use the new til_module_setup_full() with appropriate parameters, wrapped up in rkt_scene_module_setup(). The finalizing phase is still ad-hoc which is mildly annoying, but if finalizing just passed into rkt_scene_module_setup() there wouldn't be the til_module_t onhand for sticking in rkt_scene_t. So the code to extract and lookup the module from the settings would still be needed anyways, as the whole til setup_func api isn't limited to modules so the baked til_setup_t doesn't come back with a til_module_t hanging in there. Maybe in the future this gets changed a bit, there could for instance be a void* in til_setup_t where something usage-specific goes, like the relevant module in the case of a module's setup. Something to consider for the future. Consolidating these in the pre-finalize phase at least ensures consistent behavior in initial rkt::scenes setup vs. scener editing/new scenes.
2023-07-17modules/rkt: limit Rocket reconnect frequency to 2HZVito Caputo
On Linux I don't notice a significant affect on anything letting rkt try connect every frame when offline but in creative mode. On Windows however, Dan reported significant latencies in the Scener prompt responsiveness and visible slowdowns in this condition. I suspect the WIN32 Rocket library's sync_tcp_connect() code is the real problem here. But for now I can ameliorate things a bit by just hammering on that code path less when unconnected.
2023-07-16modules/rkt: track last scene in ctxt->last_sceneVito Caputo
Prepartory commit for pausing playback upon entering 99999 scene It needs to trigger only on the edge of entering the scene to permit RocketEditor to unpause playback even if still in scene 99999, if that's what the user is trying to do. It'd be annoying to have it just keep asserting a paused state until the scene idx leaves 99999... But this also enables triggering anything on scene change edges, for future stuff.
2023-07-13modules/rkt: add 99999 exit scene defineVito Caputo
rkt_scener needs to know this value so define it in rkt.h and switch over all the existing 99999 instances.
2023-07-05modules/rkt: basic support for Rocket reconnectsVito Caputo
This changes things so rkt won't exit with an error @ startup if RocketEditor isn't already listening. It also tolerates RocketEditor going away, and will show a "OFFLINE" overlay status text should that happen w/connect=on. Some status text has also been added to the "EXIT SCENE" 99999 scene for both the RocketEditor connection and the scener enabled/disabled status. No indicator yet for if scener has a connection though, only if it's listening or not via listen=on.
2023-07-05modules/rkt: introduce a rudimentary scenes editorVito Caputo
This adds a BBS-style interface for creating new scenes in a live rkt session. It listens on tcp port 54321 on localhost by default, just use telnet to connect, the rest is fairly self-explanatory. This is still early days, but it's a whole lot more than nothing.
2023-07-05modules/rkt: resolve module_name->til_module_t in setupVito Caputo
With the "ref" builtin module established and seeming to work well enough, it looks unlikely we'll need access to unresolvable module names in the contexts. The thinking originally was that these names might have special syntax making them more generic. E.g something like "@/module/rkt/scenes/[1]/drizzle" for a module_name would have been supported, which would get resolved either at context create or even later (as in the ref builtin) at render time. But the ref builtin is using a path setting, so module names just stay module names. Maybe in the future a special syntax will be added for brevity reasons, but it does make the code more complicated vs. module names just being names and resolving them entirely at setup time. Anyhow, this commit does away with the module_name in the context's scenes. You can still access it via til_module_context_t.module.name anyways... it's basically just a resolution-of-name-to-context time constraint that's being codified now.
2023-07-04modules/rkt: discretize rkt_context_t.scenes[]Vito Caputo
Make this a distinct heap allocation so it can be enlarged when editing the scenes... (preparatory commit for scenes editing)
2023-06-24modules/rkt: move rkt types to a headerVito Caputo
Preparatory commit for adding an interactive scene editing server of sorts. It'll go in a separate listing, but needs these types as it'll operate on rkt_context_t->scenes[].
© All Rights Reserved