fumieval
Time abstraction
It is very unreasonable to put input events and window refreshing and an audio output into the tick-based timeline.
I like to make it possible to implement rhythm games, or digital audio workstations.
I'm actually implementing a rhythm game (without sound for now) so this would be great. Is this planned for version 1.2?
The implementation of this idea has moved to call package and free-game is going to be its plugin. I verified that call is capable of creating rhythm games.
Yes, especially if we're writing a rhythm game. For time-insensitive applications, free-game is the still preferred one.
It's sounds like a FRP to me, or, more specifically, netwire. Though the high-level concept of FRP seems fairly clear (event->Push/Pull), I never managed to wrap my head around netwire, and I ran into limitations of reactive-banana fairly soon. It's amazing to be here and find a way to solve it, working through a practical problem.
Also, how would time-abstraction fit into a time-critical concept? As far as I understand, we are talking about an event-driven process here. If we are using a more traditional loop for a frame-driven process, how can time work with both concepts?
call lets us combine event handlers (regarding graphic/audio or even state updates as events), allowing them communicate. Unfortunately it's not FRP I think.
A traditional frame loop will be available by transforming a coroutine into an event handler.
"A traditional frame loop will be available by transforming a coroutine into an event handler." Could you explain that in a bit longer than 1 sentence? It is not immediately clear for me what "transforming a coroutine into an event handler" means.
Thanks