We are building an experiment with PyGaze using PsychoPy to handle all the screen related stuff and the keyboard input. Since we are using multiple timers to trigger events, we try using threading in order to have the different tasks not blocked by each other. Therefore we are also planning to create an event handler for all the inputs including keyboard input and also input from an eye tracker and other hardware.
But if we try to run the event handler within its own thread, we can't get any keyboard input. Everything runs without any errors, but there is simply no keyboard input coming through to the psychopy.event.getKeys() call.
PsychoPy itself is initialised in the main tread since otherwise it causes problems with OpenGL and pyglet.
Is there any way to get this setup running or is it fundamentally not compatible with PsychoPy?
Related
I plan to hook up a raspberry pi to a 64x64 led matrix, and writing a sort-of boot loader software written in c++. I would like the software to be plug-and-play with custom games I make. That is, I put all the compiled code for the games into a directory and the boot loader will recognize them and, using fork() and execvp() calls, run the selected games. I want there to be different states to the loader such as: start_state, game_selection_state, preview_state, idle_state to name a few. Each state would do their own thing and a transition from state to state based on input from a input device or idle time.
Now I do not know the best way as far as the architecture to set this up. I am not even sure that a state machine is the best way to handle this. But so far, what I have come up with is I would have 2 threads.
Thread 1:
Handles all the functionality and sanity of the states. This would include starting, stopping, and data of each state. It would also include function calls to transition from state to state.
Thread 2:
Parses input from the input Device (game controller) and makes sure a transition is valid. Then using a thread 1's function calls change the state accordingly. I planned on using a message queue to send any input that is not reserved for transitioning to the current state. (E.g A & B signify transitioning, but Y is pressed and would be sent to current state) This way the state can do what ever it wants with these button presses.
Now where this gets a little fuzzy is when the user picks a game a fork() call will be made inside a thread and I have read this can cause issues. If I did do it this way I would need a way to terminate or halt thread 2 until execvp() call ends.
Now what I want to know is this a valid or best way of implementing something like this.
My application's user interface consists of two windows: the console (handled by ncurses) and an X11 window for graphics. I would like to handle key events in a centralized way. That is, no matter which of the two windows is active, the same event loop should handle all the key events. I already have an event loop for X11 events. All that remains to be done is to forward all the console events to the X11 window.
The main building block to achieve this forwarding is found here. The only other thing I need is to be able to translate from the value returned by getch() to X11 keycode. After about four hours of searching the web, I found this code, which is part of qemu. However, when I compare the mapping it provides with the output of xev, the two do not match. For example, for the Home key, xev gives 110, while the mentioned mapping gives 71 | 0x0100, which is 327. Are these two different kinds of keycodes? What am I missing?
Hmm, mixing application frameworks is, almost by definition, difficult.
I think the best way to achieve what you want is to have two separate processes or threads, one for the console and the other for the X11 application. In each you would have the relevant event loop handler. To join them together use an IPC channel, either a pipe or socket. You should be able to make the socket/pipe an input to the X11 event loop handler with its own callback. You can have a select() on the console side waiting on the socket or STDIN; this allows you to call getch() when there's a keypress ready or read from the socket when the X11 has sent something through the socket. If you used something like ZeroMQ in place of the socket, even better.
So, what would you send through the socket? You would have to define your own event structure to pass between the console and the X11 application. Each side would populate and dispatch one of these when it needs to send something to the other. The types of event you'd need to describe would include would be things like quit, keypress (+ keypress data), etc.
Most likely you'd arrange the X11 end so that the socket reading callback read the structure from the socket, interpreted it and decided what callback should then be called directly. If your key presses are only for selecting menu entries, buttons, etc then this might be a not-too-bad (but not brilliant) way of avoiding the mapping problem.
This does mean having two event loop handlers, a socket and two processes/threads. But it does avoid blending the two into a single thing. It also means your console could be on a completely different machine! If you had used zeromq you could easily have multiple consoles connected to the X11 application in a PUSH/PULL configuration; perhaps absurd, but possible.
I am using visual studio 2010 to develop a windows form application using c++.
This program waits for an event like connection request and displays a message
But this program is shown as "not responding" in windows task manager.
Is there any way to make the program appear responsive ??
The standard practice for this situation is to use multi-threading. Create a background thread to wait for the connection request or whatever event you need that might cause the primary thread to block.
This allows the user interface of your application to remain responsive. If you don't use a thread, the primary UI thread will be blocked waiting for the request and can't handle other events such as drawing the form, responding to window events, etc.
In Windows programming, any activity that is going to take a significant amount of time should be threaded. This isn't a hard rule, but a pragmatic amount of threading will make a world of different in giving your application a smooth, responsive feel. The primary thread should be reserved for drawing and handling user interaction.
A Google search will give you plenty of examples, but here is a decent one to get you started.
I'm coming from C and don't have too much programming knowledge, so bear with me if my idea is nonsense.
Right now, I'm trying to write a simple threaded application with double-buffered console output. I've got a thread which resets the cursor position, draws the buffer and then waits n milliseconds:
gotoxy(0, 0);
std::cout << *draw_buffer;
std::this_thread::sleep_for(std::chrono::milliseconds(33));
This works perfectly well. The buffer is filled independently by another thread and also causes no problems.
Now I want the user to be able to feed the application information. However, my drawing thread always puts the cursor back to the start, so the user input and the application output will interfere. I'm aware there are libraries like curses, but I'd prefer to write this myself, if possible. Unfortunately, I haven't found any solution to this. I guess there is no way to have two console cursors moving independently? How else could I approach this problem?
I think what you will need to do two things:
Create a mutex that controls which thread is writing to stdout.
Change the input mode so that when you invoke getchar, it returns immediately (rather than waiting for the user to press enter). You can then wait for the other thread to release the mutex, then move the cursor and echo the character the user pressed at the appropriate part of the screen.
You can change the input mode using tcsetattr, although this is from termios which is for *nix systems. Since you're using windows, this may not work for you unless you're using cygwin.
maybe check this out: What is the Windows equivalent to the capabilities defined in sys/select.h and termios.h
I'm writing a game in c++ using allegro 5. Allegro 5 has events which are stacked in an event queue(like mouse clicked or timer ticked after 1/FSP time). So my question is how should be the logic of the main loop of my game, or since it's event based I can implement it without the main loop??
Any ideas how real games do it? Links will be good.
I have no experience with Allegro, but when using SFML and rendering a game with OpenGL, I myself poll the event queue as part of my main loop. Something like the below pseudo-code (but more abstracted):
while(game_on)
{
auto events = poll_occured_events();
for_each(events, do_somewithng_with_event);
render_game();
}
Seems to work fine so far... I'd guess something similar is possible in Allegro. Event driven games are tricky, since you need to continually update the game.
You could (possibly) have the main loop in another thread and then synchronize between event thread and game thread...
I don't have any experiences with Allegro too but logic would be the same.
(so called) Real games also have game loops but the diference is they use threads which are working parallel but within different time intervals. For instance there are different threads for physic calculations, AI, gameplay, sound, rendering... as user events are usually concers gameplay events are getting collected before it (as Max suggests) and consumed until the next frame (actually some collects it in for instance 5 frames).
As a frame might get too long, all the events coming from OS are getting collected by the game for that reason these inputs are called buffered input. There is also one another method which is called unbuffered input which doesn't work discrete but instead you test it during gameloop at the very instances it is queried.
If the user input is very important and you dont want to loose any inputs at all then you can use buffered otherwise unbuffered. However unbuffered might be tricky especially during debug.
here are some links
book excerpt game engine
Game Loops on IOS