thread-driven changes of input

[Max mtg]

as a method to eliminate that huge stacktraces, i have launched a separate thread to update input for all players.

Thread checks if input needs to be validated for current game state and does set input in a moment.

[myk]

In light of the recent input- and performance-related troubles, it might be better if we rethink this decision. Could we instead use an event queue to reset the stack without resorting to threading?

[Max mtg]

In light of the recent input- and performance-related troubles, it might be better if we rethink this decision. Could we instead use an event queue to reset the stack without resorting to threading?

What other problems except being unable to pay any 'unless' costs exist at the moment?

[myk]

there has been fairly severe performance degradation, as noted by Agetian in the bugs thread. I've noticed it as well. But more than that, by introducing threads, we're playing with fire. Threading is such a can of worms unless the architecture is specifically designed for it, and the forge architecture most certainly is not. If the purpose of the thread is to simplify the stacks, I think we can do that with a queue just as easily without the dangers of threading. In this case, we can use SwingUtililties.invokeLater() as the queue. Game state checking could happen in the passed Runnable.

[Agetian]

It looks like both the significantly slower input ("lag") issue and the "occasional empty card selection window when running on Java 7" issue are related to this change (in r19990).

- Agetian

[myk]

I'm assuming "ищер" means "both" : )

[Agetian]

I'm assuming "ищер" means "both" : )

Yes, yes it does. Fixed the mistype btw.

- Agetian

[Max mtg]

How nice, how many people speak Russian here? or have that keyboard layout at least...

[Agetian]

How nice, how many people speak Russian here? or have that keyboard layout at least...

Hehe I speak Russian, it's my first language, actually.

- Agetian

[Max mtg]

I have disabled the thread and made code synchronous again... per your joined request.


Myk still has not confessed, how he managed to guess the right keyboard layout conversion.

[Max mtg]

Despite of a recent setback, I still want to change how the input works.

Some operations like paying mana or selecting target cards of players requires the routine (that was called to play a certain ability) to set input and return, passing some Command instance to the Input to execute them as soon as player reacts.

To my mind tracking all these continuations in commands and having different branches of code for AI and human (since AI reacts in no time and callers get the required data immediatelly) is making the project harder to mantain and develop.

I would like the routine (that needs some data from user) to wait at all cases, like it does wait when GuiChoose.one() window pops up. All the code ATM is executed from EDT (event dispatch thread) that cannot be just put on hold until we choose some targets from InputPayMana, because that is the same thread that reacts to user input.

So my idea is: as soon as we recieve a command from user, grab a thread (from a special pool, for instance) and have it execute all those spellabilities asynchronously. As that thread realizes it needs any data from human, it creates an object to synchronize on, assigns new Input state to UI and calls wait() method of that object. When the Input is finished, the caller thread awakes (from notify() method over the synchronization object) and continues its execution flow.

In this fashion a thread could wait for any source of data (yes, I hint at network) keeping the code cleaner and with less duplicates.

[moomarc]

It sounds like a great idea and is probably something we'd have to do eventually anyway. But because the scope is so wide, I think it should be developed in a branch because as we saw last time, if something isn't quite right, Forge becomes very unstable. That way you can develop your idea until you're ready for more of us to test it, while the other devs can continue their own development without wondering whether an issue is due to the thread-driven changes or something in their own code.

[Sloth]

An input system that does not delay the inputs is something i've wanted for as long as i've been working on Forge. It would be really great if you can get this to work Max.

I'm willing to help as much as i can, when you need it (I imagine that most of the cost classes and some of the hardcoded cards need to be updated).

[slapshot5]

I'm willing to help with this also. Probably more from a testing and reporting bugs perspective. I synced up the new branch and did a couple quick run-throughs. Not sure if you're ready for crash reports or bugs at this point.

-slapshot5

[Max mtg]

Thanks for the help you offer!
Testing is the most anticipated thing.

Right now I am heavily modifying the input system in a branch. Shall let you know when it's ready for tests.