Does cocos2d-x use multithreading, like one thread for the game engine and one for user input? Or how are things made as efficient as possible?
Also, have you ever been in a situation where you as the developer had to use multithreading or is that extremely unlikely in cocos2d-x?
Thanks!
I believe the engine is designed as single-threaded, possibly for simplicity and possibly because JavaScript is single-threaded. The engine does have one piece of multithreaded code I can think of, and that’s for loading images. I believe TextureCache has an addImageAsync function, or something like that.
Input is not multithreaded. If I remember correctly, the system sends the input data to the engine and the engine stores it then handles it next game loop.
One issue people have is getting a loading screen with a moving loading bar or animation playing, which can require multithreaded code. I haven’t used multi-threaded code much, but I’m sure there will be times I need to use it.
Rendering is executed in the main thread (single-threaded).
Image loading can be done in background thread (as grimfate mentions).
Screenshots are (or can be) resolved in background thread.
Audio uses background threads.
Console (telnet) uses background thread. (most don’t use)
You can handle multi-threaded for your own non-cocos2d code using c++11/14/17 std::thread
You should execute all Cocos2d functions on the main thread using:
void performFunctionInCocosThread(std::function<void()> function);
With cocos2d it’s usually best to limit your multi-threading to specific long-running tasks: AI, file loading, Pathfinding, etc.
Thanks! But regarding
, how can the input be handled immediately after the input? I mean then how callsbacks be run immediately after a user input, like there must be some delay because of the fact that it is single-threaded, right?
Also regarding
, is the need of multithreading here because of that C++ is sequential and therefore the loading screen had to finish before the next instruction can happen (the moving loading bar)? Am I right? Otherwise, please correct me 
A big thank to you too! But exactly why did the developers of cocos2d-x choose to do it this way:
is this way chosen because it is quicker than if they all were in the same thread? Or is it because of this is the only way to make things happen simultaneously?
The same goes for
Is it because it is quicker or?
One more question:
In Cocos2d-x you can have an update function that runs all the time, but how can that function run all the time if it is not multithreaded and C++ is sequential? I mean since you have to wait for instructions to finish, wouldn’t the update function have a potential of a giant delay and inaccuracy?
It just gets called every frame.
In just one frame a lot of things happen. The input from the last frame as well as all the events are procesed, all the code inside the “update” functions is executed, some other things that I don’t know also happen, and then the drawing is done.
Considering that a game usually execute between 30 to 60 frames per second then a person is not going to notice the “delay” generated while doing all of this.
Also you’re right about the inaccuracy. if the game is running at 60 fps, the delta between each frame should be of 0.0166 however if you print the delta you’ll notice than the delta varies a lot. Some frame could be 0.016, another 0.014 then 0.018 and so on.
As zerodarkzone said, the input is handled each frame, which means there should be no noticeable delay between the input happening and the input being handled. Handling touch immediately would make no noticeable difference, and would make things more difficult because it would be handled in a different thread so you have to make sure anything you do doesn’t interfere with anything in the main thread.
Yes, that is correct. If you do something on the main thread, nothing else on the main thread can happen until it finishes. Changes you make to nodes won’t be visible until the renderer gets to render, so if you load a texture on the main thread then update the progress bar and then immediately load another texture on the main thread, the update to the progress bar won’t be visible until after the second texture is loaded, because the render function won’t be called until after the texture is loaded. If you load all your textures on the main thread like this, then the renderer won’t be called until all the textures have been loaded, which means the progress bar is useless because it won’t move until all the textures have been loaded.