I know you can't do any rendering in separate threads using SDL2, but what about events like leftbutton1down etc?
I don't see how I can continuously draw at lets say, 60fps, while having the event poll in the same thread, so, wondering what's the best structure to use for my game.
Current idea (each separate thread separated by ','):
Main thread with drawing + physics, event polling (inputs)
Related
I am making my first game and I am stuck with one problem. I have a world where you can walk free, but then when you meet the enemy you will switch to battle and when you are switching to battle, I need to load all the models that will be rendered in the battle scene. The loading takes about ~5 seconds and I want to make the loading screen. So, I rendered the loading screen in the main thread, but how can I load 3d models and build different VAO and VBO at the same time? I made a new thread for this loading, but I read online "don't use threads for generating VAOs". What is the best solution to make this loading? Should I just preload all the models in the main thread before the game starts? Personally, for me it seems not right to load all the 3d models in the beginning of the game.
Assuming you have two windows, you can bind each context of the window to separate threads. Problems will arise if you share data between them (proper locking is mandatory).
See glfwMakeContextCurrent:
This function makes the OpenGL or OpenGL ES context of the specified window current on the calling thread. A context must only be made current on a single thread at a time and each thread can have only a single current context at a time.
Thread safety:This function may be called from any thread.
See glfwSwapBuffers:
This function swaps the front and back buffers of the specified window when rendering with OpenGL or OpenGL ES.
Thread safety:This function may be called from any thread.
Some functions in GLFW can only be called from the 'main' thread (nor from callbacks), e.g. glfwPollEvents, but other than that, bind the context to a thread, perform your OpenGl calls and swap the buffers. As said before, as long as you don't share any buffers, there should be no problem.
Im designing a game menu for an arcade machine as a personal project and to get more familiar with IPC. The project runs on a raspberry Pi rendering to a LED matrix using Hzeller's led matrix library. The menu would present the user a list of games rendered on the matrix. When the user selects a game, the main process will fork and spawn the game in a new process. The game will start and render to the matrix. At any point the user can exit the game which will return the user back to the game menu. Presumably there will be communication between processes so each aren't simultaneously rendering to the matrix at the same time.
Now where I am uncertain is how to actually share resources that are needed to render to the matrix. The library has a background updater thread that cannot be running in both process. Im not certain how this is typically done but here are the solutions I came up with:
Resources needed for rendering are cleaned up and reinitialized before switching contexts between parent and child processes
The Child will serialize the underlying framebuffer data and send it to the main process for rendering.
The first solution seems a little hacky and requires me to make small changes to the library. I also want to create an interface to decouple the menu/game processes from where graphics are actually rendered. This way I can make a separate implementation of the interface to render to a GUI on a computer screen. Choosing this option would be synonymous of creating an entirely new window for the child process (not sharing the same window).
The second solution would require copying the framebuffer data twice per frame. Once to shared memory and then again when the parent process copies out of shared memory and rendered. I worry about latency and how to manage frame rate in this solution. Ive looked into initializing the framebuffer in shared memory, but the library handles the initiation of this buffer. In addition, I am utilizing the library's vsync capability and am unsure how the child would utilize this if rendering were done in the parent process
My questions are:
Are there any other solutions? If not which of the two are better
design wise.
If I go option two, how would the child take advantage of the vsync functionality and how would I manage framerate in this scenario?
A game will typically involve real-time rendering to the LED matrix, and will have other requirements for user interaction to that are specific to the game and a lot more demanding than the requirements of your simple menu. It would not be good design practice to delegate these things to the menu process via some IPC mechanism. That mechanism could only get in the way, and you'd be forced to implement many of the game's requirements inside the menu process. The game should be able to control the display directly, while the menu should only have to do its easy menu things.
This should be very simple to arrange. Your menu process should shut down its display loop before it launches the game process, and should then resume its display loop when the game process ends.
The best way to do detect the completion of the child process is usually to pipe stdout on the child process into a parent process file handle. The parent process should read from this handle until it is automatically closed by the child process exiting. This is a universally reliable signal that works on all linux/unix/windows platforms.
I'm currently working on a game where I wanted to create a loading screen that basically shows the process of loading all the resources. To do this, I decided to create a separate thread that handles the window. I'm aware that there could be more efficient solutions, but I wanted to create a special mouse cursor and that way was the only way that allowed me to do that without having a buggy mouse when the application is loading a big file.
I read up on the threads on the SFML tutorial page and I learned that I have to do window.setActive(false) in the main thread and then window.setActive(true) in the separate thread in order to have access to the window in the separate thread without getting any problems. This works fine, it doesn't throw any errors and it displays the loading screen very nicely. However, I can't move the window around or interact with it in any way. The mouse cursor is covered by the blue ring from the mouse when it's loading, and I can neither close nor move nor resize the window even though I used sf::Style::Default, so it should be possible.
Can anyone help me out here?
You have it backwards. You blocked the main thread with loading your resources and created a new thread to keep the UI responsive. Not only is that not going to go well in the long term, but in the short term, your operating system still thinks your app is blocked, because the main thread is unresponsive. The OS does not know you created a second thread to keep the user entertained.
You should instead keep the responsive UI on the main thread and create an extra thread for doing the heavy lifting and blocking work. This way you don't have to struggle with your graphics library all the way (and it does not matter whether that's SFML, because they all do this) plus your operating system will not behave as if you blocked your application.
I am getting started with the wxThread.
I have shown the video in the GUI thread with wxWidgets. And now I want to handle each frame with opencv like drawing one circle in each frame. At the beginning, I have done the processing in the GUI thread. But when I run the program, I find that the image in the GUI isnot shown continuously and some image doesnot include the circle.
I have realized that image processing part is not put into the GUI thread. I should creat a new thread to complete the image processing part.
But I don't know how to how to make GUI thread and worker thread synchronization, it means that it can make the GUI thread non-blocking and the worker thread process the frame with opencv. Although I konw the wxthread tutorial, I couldnot deal with the problem about how to share the data between the two wxThread.
Could anyone have some ideas about it or some reference? Thx.
There is a pretty extensive section on thread synchronization in the wx-wiki
https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_communication
For background-tasks I like to use the "post event to main thread" approach
This might also work for you. - Send an event whenever your work-thread is done with the processing of a single image and display the image in the event-handler method
I'm writing a program in Qt, which runs 10 worker threads which calculate the trajectory of an object in space. They also have to draw the path of the object. I have a "Body" class deriving QGraphicsEllipseItem and it has a QPainterPath in it. The "Simulation" class takes a list of obstacles in the world, and the body to simulate and runs until the body collides with something. Simulation runs in a separate thread ( done with moveToThread, not by subclassing QThread). When the body collides, the Simulation emits a signal saying that it finished. When all threads have finished I'd like to draw the paths (I do it by invoking a method in "Body" which enables path drawing in its draw method).
Unfortunately I get ASSERT errors :
ASSERT: "!unindexedItems.contains(item)" in file graphicsview\qgraphicsscenebsptreeindex.cpp, line 364
They happen seemingly randomly. I've tried different connection types, to no result.
I'm starting the threads in a loop.
I'm using Qt 5.0
Generally speaking, with Qt you can't do any GUI operations outside of the GUI thread (i.e. the thread that is executing QApplication::exec(), which is typically the main() thread).
So if you have multiple threads manipulating QGraphicsItems (especially QGraphicsItems that are currently part of a QGraphicsScene), that is likely the cause of your assertion failures. That is, when the Qt GUI thread is doing its window refresh, it is reading data from the various QGraphicsItem objects as part of its calculations, and it expects the QGraphicsItems to remain constant for the duration of the refresh operation. If a QGraphicsItem is changed (by another thread) while the refresh routine is executing, then the calculations made by the main thread can become wrong/corrupted, and that occasionally causes an assertion failure (and/or other unwanted behaviors).
If you really need to use multiple threads, what you'll probably need to do is have the threads do all their calculations on their own private data structures that the Qt GUI thread has no access to. Then when the threads have computed their results, they should send the results back to the Qt GUI thread (via queued connection or QApplication::postEvent()). The GUI thread can then look at the results and use them to update the QGraphicsItems, etc; this will be "safe" because this update can't happen in the middle of a window update.
If that sounds like too much work, then you might consider just doing everything in the GUI thread; it will be much easier and simpler to make everything work reliably that way.
As mentioned by Jeremy, Qt rendering must be done on the main thread.
While you could move it all to the main thread, you've likely chosen to create separate ones for efficiency, especially as collision detection can be processor intensive. The best way to handle this is to split the modelling of the objects and their physics from their rendering, as you would in a Model / View / Controller pattern.
Create representations of the body instances that are not derived from any QGraphicsItem/Objects. These can then do their calculations on separate threads and have signals to graphics objects that are running in the main thread, which updates each body instance's graphic representation, allowing real-time rendering of the trajectories.