I have some huge saves and when reloading them (including respawning and relooking many actors) it takes forever, meanwhile the game is stuck on one frame, sometimes for several minutes, so there must be a better way.
So i thought it would be a good idea to give my loading function its own thread.
The thread mechanism itself works very well, but as soon as i call my function, i get a crash telling me that some “IsInGameThread()” condition is not satisfied.
Essentially what i try to do is some spawning, calling server functions (i forgot to say it’s a networked game), accessing some GameState arrays from the PC (which seems to trigger this crash, among other things), things like that.
Any one knows the logic behind this condition ? Like what type of operation am i allowed to do in a separated thread and what type must be in the game thread ?
Just to know if i should spend some time trying to make this work or if it’s already a lost battle.
I’m not positive but my understanding is that anything involving the engine itself needs to be done in the main game thread. So if you want to spin off loading/saving to a new thread (something I wish every game would do!), then you can do that but you can’t interact with the engine in that thread. Basically just handle the serialization of the data, then pass it back to the main thread.
I was afraid of something like that. My problem is that serialization is not what takes time, what i need to parallelize is all the spawning stuff.
If i can’t do that through a thread, maybe i’ll expore the tick/timers leads, see if at least i can do one actor at a time and let the game breath in between, so i don’t have a 2 minutes loop becoming a 2 minutes frame.
Thanks anyway !
Cheers
Cedric
I’m interested on what the ‘best practices’ are regarding this as well. I wanted to create and destroy instanced static mesh instances on a separate thread and so ended up modifying the IsInGameThread() function so that it would accept the thread id of my thread. I had to change a bit of the ISM code but ended up getting the instance creation working, it was the removing of the instances that caused issues (something to do with physics if I remember correctly).
Spawning Actors CAN be ok on a separate thread (I had to initially disable ticking) but it will probably depend on what components etc the Actor contains. I suspect it’s probably not a good idea though unfortunately.
What i ended up having to do was implement some kind of time slicing functionality. Basically i work how much time i’m willing to allocate to spawning objects per frame (based off a minimum acceptable frame rate) and spawn while I haven’t exceeded that allocated amount. It seems to be working quite well but will depend on whether or not you NEED all objects spawned straight away as it can take a couple of seconds to spawn all objects.
EDIT: modifying IsInGameThread() probably isn’t a great idea unless you really know what you’re doing or can be sure the thread wont stuff up something else
We’ve had similar constraints, and the way you mention at the end there is how we did it - by spawning until we overshoot some goal, then waiting until the next frame. If your spawning requires any complicated calculations, you can do those in a fork/join thread model, and use their results in the frame-by-frame spawning code.
(By fork/join, I don’t actually mean creating/destroying threads. Just have a few on standby and wake/sleep them as required.