pgimeno wrote: ↑Mon Nov 04, 2019 2:24 pm
I have some criticisms though. First. I find the naming scheme confusing. O and G are not descriptive. The prefix "Poll" does not make it clear whether it blocks or not, and I'm not sure but there may not be a blocking and a non-blocking variant of e.g. PollKeyPress.
I agree, honestly I'm regretting releasing it like this now. For some context, this library is the product of an experiment I did trying to wrap the entire program in "timelines" including graphics, a lot of the questionable design decisions come from pretty quickly patching up that code into something more usable as a library, originally timeline objects were completely hidden and used internally. I'm considering rewriting the whole thing from the ground up with better naming, more thorough, etc. There's a lot of old optimization left over that really limits my ability to design the library, a rewrite is probably for the best. My original experiment would have hundreds of timelines being used created and recycled all the time, so optimization was necessary. But now, I don't think it's that important, I'll want to keep some, but not all. I'm using this for my own projects and I'm kind of uncomfortable with some of this too. Consider this version 0.1. I'm going to keep working on it. I *want* to keep working on it!!
As for "Poll" it's a little hard because of how loose events are in TLE. Yes, "Poll" always blocks. Anything considered an "Event" blocks. And any function is an "Event" if it directly or indirectly makes a call to E.Step(). That function is the function that will actually call coroutine.yield(). I'd like to keep this loose behavior, but I'm not sure how to communicate this all better.
I should add, I'm trying to design this library so the user doesn't need to think or care about whether or not it blocks unless it's specifically important. My vision is to think more in terms of the progression of time, i.e. a line of code represents a movement in time. That's my guiding philosophy for this whole thing.
pgimeno wrote: ↑Mon Nov 04, 2019 2:24 pm
There is also the issue that it's using love.keyboard.isDown and only the first parameter of love.keypressed, but that's only useful for cases in which the programmer wants to use a specific letter, as opposed to a letter in a specific position. Case in point: WASD controls are used by many games for many keyboard types, but French keyboards use ZQSD controls, which are in the same position in an AZERTY keyboard as WASD are in a QWERTY or QWERTZ keyboard. Typically, when you want to use specific letters, you use the textinput event.
In general the input events are kind of limited right now (no touch events, gamepad, etc.). But that's interesting. How would I check for a key *position* in love?
pgimeno wrote: ↑Mon Nov 04, 2019 2:24 pm
I would have liked to have a queue of keys per timeline, in order to not miss when multiple keys are pressed in the same frame. I think it can be presumed that if you don't use keys in one frame that aren't pressed now, they can be cleared from the queue, so that it is kept at a reasonable size.
I didn't think about multiple keys being pressed in the same frame. I think this is an easy fix though! I guess this is the silver lining of going public.
pgimeno wrote: ↑Mon Nov 04, 2019 2:24 pm
The scheduling policy for multiple threads (timelines) is not clear from the docs either. I guess it's a simple round-robin policy? i.e. when a thread is interrupted, the next thread immediately executes?
Yeah I could have communicated that better, but it is actually very particular how it happens.
This depends on a few things. Generally, they run in the order they are created until they are interrupted then move on to the next one. These are coroutines and not real threads after all, so it's still singly threaded. However, if you create a timeline with E(...) then you need to manually update it with E.O.Step(id). From there, in the Timeline's execution, the top level executes first, then it starts executing the branches in the order that they were created. Branches are initialized immediately as they are created, but timelines created with E(...) will wait until the first update. If you create a Timeline with E.O.Do(...) then they update in the order they are inserted and will wait for the next love.update() before initializing.
.