I am new to wxPython, so please be gentle. I am trying to make a game using wxPython. I need to be able to handle events (button clicks) while the game is in progress.
The process is:
Deal the cards
Wait for user input
Continue accordingly
The way I have implemented it is:
app = wx.App()
g = Game() # calls g.Play() which executes the process above
app.Mainloop()
However the application freezes. I think the problem relates to being unable to respond to events while the process is being executed. How can I get around this?
I had a look at threading, but cannot see how to make this work in my case. If I create a new thread to deal with user inputs from within Game(), that will not be able to update the values in Game().
I am sure there is a "correct" way of doing this which I don't know because I am unfamiliar with wxPython. Can anyone help?
Yo do not need a seperate function play() to run the game. Just set up the event handlers to compute the state of the game during every event which results in a move of the game.
A good option would be to define a game state as say the cards in each players hands, and the turns that have been played and the scores, all defined as an object of a state class.
Chalk out an outline of how your game's architecture first. And you might also want to take a look at some examples and documentations on wxPython if you are new to it.
wxPython (and all GUI toolkits) are event driven. What this means is that they all wait for the user to "do something", like press a button, move the mouse, press a key on the keyboard, etc. When the uses does one of these things, wxPython checks to see if any of those events are bound to an event handler. If they aren't, wx will usually ignore the events.
You can learn about how to bind events properly here:
http://wiki.wxpython.org/self.Bind%20vs.%20self.button.Bind
So when you start the program, it should probably deal the cards at the start or possibly prompt the user to see if they want to start a new game or possibly continue a game. After that, the application would wait for the user to "do something". If the user executes a process that takes a long period of time (like a complex calculation, downloading a large file, etc), that process should be put into a thread. If you don't put it into a thread, then that process will block the UI's main loop and your app will freeze. See the following articles for information about wxPython and threads:
http://wiki.wxpython.org/LongRunningTasks
http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/
I hope these links help you on your way.
Related
I am making a an app with 3 main screens: a reminders list, a homescreen, and a chatbot. The chatbot I will integrate in using Dialogflow, and i've completed the todo list. What the homescreen does is display pulse and temp taken from arduino through a bluetooth connection and if either exceeds or falls below a certain threshold then a call should be initiated. I currently did the call initiation and the pulse and temp values are hardcoded in for now. But if I go to another screen, the homescreen obviously doesn't do its job. What is the way I can make the homescreen kind of like the main thread . Basically even if i am on the chatbot screen, the homescreen should be checking if temp and pulse are abnormal and initiating calls if required.
I am not sure what concept this falls under so any help is appreciated.
You can use Isolate class to achieve this.
An isolate has its own memory and a single thread of execution that runs an event loop even in background until you kill Isolate.
Here is the example of how to use Isolate in flutter
There is also flutter package available for Isolate flutter_isolate
I'm developing a game in pyglet, that scheduled by a simple text file like :
0:00:01;event1
0:00:02;event2
0:00:03;event3
The fact is that, among these events, some might be blocking (for instance event2 might consist in displaying instructions until a key is pressed). As a consequence, event3 might not be executed at the proper time (i.e., during the event2). For now, my strategy is to schedule one event after the other :
Execute the first event
Once the first event is finished, compute the remaining duration between the first and the second event (delta_duration)
Schedule the second event with a delay of delta_duration
... and so on
For now, I did not succeed in implementing properly a blocking event with this strategy. It seems that anything blocking the event_loop (like a sleep call during event2) is preventing even the graphical elements of event2 (text instructions) to be displayed. On the other hand, if I do not put any blocking routine (sleep) in the event2, I'm able to see the vertices, but the scheduler keeps on scheduling (!), and so the event3 comes too soon.
My question is : what would be a general strategy, in pyglet, to articulate non-blocking to blocking events ? More precisely, is it possible (desirable) to use multiple clocks for that purpose ? The pyglet documentation mentions that multiple clocks can be used but it is not very well explained.
I don't want a solution that is specific to my events example but, rather, general indications about the way to go.
It's really up to your program on what blocks. If you are using input from Python for the console window, then yes that will block because it's blocking execution of Python in general. If you have a label popup in the window that is waiting for input from an on_key_press window event, then that is completely different as it's not blocking the pyglet loop, it was scheduled within it.
If your event is a 20 second long math calculation, then that should probably be ran in a thread. You will probably have to separate the types of events in order to differentiate how they should be ran. It's hard to say because without a runnable example or sample of code, I am just guessing at your intentions.
Although it sounds more like you are wanting some sort of callback system. When execution of func1 is declared done, go to func2. There is nothing built into pyglet like this, you would have to have a clever use of scheduling. There are examples of this using pure python though. I personally use Twisted Deferred's for this.
I'm using event structure and want to do some like Launchpad.
Numeric keyboard have for each number added a sound.
Problem is, that when I press number example one, the program is waiting when the music stop play and next I can press example number four.
Is it possible, to play sounds from 3 key's at the same time using event structure ?
I put the files online here and added screenshots below. Block diagram:
Front panel:
Working Solution
I think I got this working much more easily than I expected using the Play Sound File VI under the Graphics and Sound -> Sound -> Output palette. That link is the 2011 documentation (couldn't find a more recent link), but it does not look like it has changed. The working result is shown below, with two different events handled by the event structure:
Key Down? event:
Stop Button event:
You may be fine without using the Sound Output Clear VI to the right of the main event loop, but having it there won't hurt.
It turns out that the Play Sound File VI does not block, so you can play multiple overlapping sound files. If you run into blocking on your machine (one sound file plays, then the next, and so on), let me know because I have another solution that might work.
A word on events
An important thing to understand is that events are handled in a queue. When you press keys, those key presses go in order onto the event queue. Each time your event-handling loop executes, it takes the oldest event out of that queue and processes it. The event structure in LabVIEW will only handle one event per iteration of your event-handling loop. On the next iteration, if events are still in the queue that your structure is set up to process, it will take the next-oldest one for that iteration and repeat.
Now, lets say that you want to do some super complicated processing that takes 10 seconds every time you press a key, and you put that processing inside of your main event loop. Your key presses still go onto the event queue as fast as you press them, but LabVIEW has to wait the full 10 seconds before it can dequeue the next keypress and process it, so you end up with an application that seems to hang while it chugs through the queue much slower than you are adding items to the queue.
One way to get around this is to take that complicated processing and put it outside of the queue in another process. If you have the resources, you can actually call a separate instance of a processing sub-VI in its own thread for every one of those key presses. This allows the event handling loop to spawn processes as fast as you can press keys, and then your processes take whatever time they need to simultaneously (resources permitting) perform whatever actions you wanted.
Essentially that is what the Play Sound File VI is doing. It sees that you want to play a file and spawns a process to play that sound over the speakers, allowing the event-handling loop to continue immediately rather than waiting for the sound to finish playing. As you press more keys, more processes get spawn that kill themselves when they are finished. You can do this manually too, which is the other solution that I have for you if Play Sound File does not behave the same way for you as it did for me.
Update:
Thanks to #Engineero for pointing out that Play Sound File vi actually isn't blocking. The updated code shows how to play overlapping sounds. I'll leave it to the user to add the Stop Sound on Key Up code. No timeout is needed because nothing is taking place in the event structure.
Also, note that for me the Play Sound vi needed to be in a while loop to keep playing. Not sure why this is needed, but the NI examples sets it up this way (\examples\Graphics and Sound\Sound\Sound Player.vi).
Finally, you may crash the vi if your sound card gets overwhelmed as mentioned here. If that happens I would go with a better sound library to try and squeeze more performance out of your sound card.
Original:
First, I assume you a referring to this Launchpad?
I was able to press up to 4 keys at once will the following - the important thing is to set the event timeout to 1 ms. If you need more than that it will require a more sophisticated design.
I was no able to easily implement a sound because all the basic LabVIEW beeps are what's considered "blocking I/O" meaning if you call 2 Beeps simultaneously than Windows will play one after another not both at the same time. You will need to implement you instrument notes using non blocking I/O probably in a language other than LabVIEW such as this C++ library.
When I call for the first time to Manager.CreatePlayer() its freezes my application for a split second and it's a problem for me because I'm writing a game and it's noticeable, what can I do to fix it ?
As far as I know, the common logics for game are :
Display loading screen
Here's all heavy operations are prepared/preloaded and cached, so the game can run smoothly later.
Methods that usually called here are Manager.createPlayer and Player.prefetch().
All the image & sound is prepared first, and can be used quickly when game started.
Start the game (loop)
As the resource have been prepared/preloaded, now you can use (draw/play) them here.
Use the Player instances that has been created & prefetched (from loading screen).
You can call Player.start() method here to play the sound.
You can read about the Player state (especially about prefetch) HERE.
Notice that you can reuse the Player instance and call start() method multiple times for playing the same sound. No need to call createPlayer again.
I have simple window in Tcl/Tk which on hitting OK button runs simulation. I am using Linux. The window is destroyed when the simulation finishes. The problem is window lingers on while the simulation is running. I want the window to vanish after I hit OK button.
I tried using wm withdraw .mywindow but it makes the area where the window was displayed (containing OK button) to be white.
I found update while googling but it is said to be harmful.
If you do wm withdraw .mywindow, the window won't actually vanish until the event loop is entered, because it is the event loop that handles redrawing the screen.
You have a couple of choices to solve your problem. For one, you can call update idletasks. That is a variation on update that just handles "idle" tasks such as painting the screen, but not tasks like responding to buttons and other user-generated events. So, solution one is to do:
wm withdraw .mywindow
update idletasks
run_simulation
By the way, the reason update is harmful is because it essentially starts a new event loop -- another infinite loop. If during that event loop an event comes in that causes the same code to run again, you start a third, and a fourth, and so on. As a general rule, nested infinite loops are never a good thing. Remember: tcl is single threaded so those event loops don't run in parallel.
The other solution is to enter the event loop naturally, and schedule your simulation to run once all other events have been processed. Do do this, start your simulation by using the after command. Using after will place an event in the event queue. When the event loop gets to that event your simulation will begin.
For example:
wm withdraw .mywindow
after idle run_simulation
When the above code exits -- assuming it was called as a result of an event such as pressing a button or key -- the event loop will be re-entered, any pending events will be processed, then your run_simulation command will run.
By the way -- if you have a GUI that needs to be responsive while your simulation is running, you should read Keep a GUI alive during a long calculation on the tcler's wiki. There's a lot to read there which makes the problem seem harder than it is, but it's not as complicated as it might first seem.