Multiple Threads in Script?
by Thomas Pereira · in Torque Game Builder · 08/04/2011 (10:47 am) · 6 replies
I did a forum search and couldn't find anything specific to this topic. What I'd like to know is if there are multiple thread support in the scripting aspect of TGB.
Without getting too specific, I'd like to do things like load levels and data asynchronously. Since all the scripting execution appears to be done on a single thread, that makes loading assets on the fly result in a slight delay time.
Any knowledge on this would be helpful! Thanks a bunch.
Without getting too specific, I'd like to do things like load levels and data asynchronously. Since all the scripting execution appears to be done on a single thread, that makes loading assets on the fly result in a slight delay time.
Any knowledge on this would be helpful! Thanks a bunch.
About the author
#2
08/04/2011 (5:17 pm)
From what I read elsewhere, torque is not built to handle parallel execution. I believe it had something to do with openGL, but I am not sure. 
#3
08/05/2011 (12:27 pm)
To provide a simple answer, no. Parallel code execution is not something you can perform from TorqueScript.
#4
08/06/2011 (5:38 pm)
Alright, thanks for that answer. Any pointers on the best way to tackle this in C++? As in, does the engine have some classes behind the scenes I can utilize, or will I need to create something from scratch...
#5
I can tell that it is imageMaps who take actual time when loading levels, so if you manage to have these loaded by the time they are needed you can load everything else on the fly with no significant delay.
08/07/2011 (2:37 am)
@Thomas I think there is no easy way to add async loading to the TGB. Pretty much entire engine behaves in assumption that all required assets already presented in memory. I can tell that it is imageMaps who take actual time when loading levels, so if you manage to have these loaded by the time they are needed you can load everything else on the fly with no significant delay.
#6
Here's where it gets tricky. The tilelayers are 100x75 tiles -- 7,500 tiles EACH. That means at each loading interval, I am loading 15,000 tiles. Now, that isn't much of a problem once loaded into the engine...now, I could load giant junks at once upon game initialization. Each layer, when filled with tiles, is around 2 MB loaded in memory, but if I have a world with, say, 50,000x50,000 layers, or 2500000000 layer files, times 2 MB...well it's obvious memory can't handle that, nor can any hard drive storage, so loading all the assets in memory is out of the question.
The issue isn't even so much in storing this data on the hard drive, the access time is slow but feasible to deal with, it in the loop actually processing the tile data. Sorting through 15,000 tiles is an expensive loop...I've devised methods to reduce that number drastically by doing it line by line per update frame, but I feel like if a 3d engine can process thousands of vertices, a 2d engine should be able to process thousands of tiles on the fly...
Anyway, I guess an explanation wasn't very necessary. It looks like I'll be needing to code this myself since no functionality for parallel execution is implemented. I'll just create an isolated library for the heavy computations that the engine relies on as a dependency.
08/07/2011 (10:27 am)
@Rpahut the thing is, in my experiments, I am using very small imageMaps that take very little memory or effort to load. I created an intuitive little level streaming system and file naming convention, but my experiments include loading 2 tilelayers at each stream interval. Here's where it gets tricky. The tilelayers are 100x75 tiles -- 7,500 tiles EACH. That means at each loading interval, I am loading 15,000 tiles. Now, that isn't much of a problem once loaded into the engine...now, I could load giant junks at once upon game initialization. Each layer, when filled with tiles, is around 2 MB loaded in memory, but if I have a world with, say, 50,000x50,000 layers, or 2500000000 layer files, times 2 MB...well it's obvious memory can't handle that, nor can any hard drive storage, so loading all the assets in memory is out of the question.
The issue isn't even so much in storing this data on the hard drive, the access time is slow but feasible to deal with, it in the loop actually processing the tile data. Sorting through 15,000 tiles is an expensive loop...I've devised methods to reduce that number drastically by doing it line by line per update frame, but I feel like if a 3d engine can process thousands of vertices, a 2d engine should be able to process thousands of tiles on the fly...
Anyway, I guess an explanation wasn't very necessary. It looks like I'll be needing to code this myself since no functionality for parallel execution is implemented. I'll just create an isolated library for the heavy computations that the engine relies on as a dependency.
Torque 3D Owner William Trevino
Novel