Threads in TGB

#1 If you have things happening in TorqueScript, which I'm guessing you do since you're in the TGB public forums, you can have concurrent operations. The specific thread management is handled by the engine, unless there's something I didn't know about TGB.

For clarification, what is this "looooong operation" doing? Is it severely impacting performance?

#2

Quote:
If you have things happening in TorqueScript, which I'm guessing you do since you're in the TGB public forums, you can have concurrent operations. The specific thread management is handled by the engine, unless there's something I didn't know about TGB.

This is a misconception--there is no thread processing in TGB for TorqueScript by default (in stock). You cannot have "concurrent operations" in TorqueScript, although the event/event handler driven nature of how TorqueScript works may make it seem like you do--in fact, things are just done in very small chunks, in a single threaded (blocking) manner.

#3 Oh, then things run well enough for my purposes that it hasn't even been an issue. Thanks for the clarification!

#4 Thanks for response.
Ok. if there is no multithreading at all. Could you plz give me an advise what is the best solution for my problem. I’m newbie in TGB and my English is… is not quite good… So sorry at first:).
The problem is – I’ve got simple game with some pieces on the board. When the user is finished his turn I have to do some calculations. It takes 0.5-1 seconds but during this period user cant see the mouse cursor moving. So it’s very uncomfortable. I think that I don’t need anything else to do while calculation – just the possibility of mouse cursor moving.
Seems that the solution is pretty simple but… but I cant find it.
If you know some workaround of the same problem it would be great help for me.

Thanks.

#5 So nobody know how to help me?! I was going to buy TGB but now... if script has such performance problems...

#6 It's not really my job to sell you on TGB, I'm just sharing my experience with it. This seems to be an occasional problem with the public forums. Even fans of GarageGames realize their engines are not perfect, nor are the best solution for every problem. Still, at the end of the day, the decision as to whether or not one chooses to develop with a GG product is the the developer evaluating the solution.

For price, I believe TGB to a fantastic product. Sometimes it doesn't do something as well as I'd like, so I have to compromise. Compromise is a requirement when developing anything, whether it's the International Space Station or the composition of pennies. Making video games is very much an exercise in compromise, without a willingness to adjust the design or implementation, your project *will* fail.

I'm really quite curious as to why it would do that to you, is it hammering your CPU at the same time? If it is, what are the specs on the computer(s) used to test this? If something froze on me and I couldn't use the mouse for a second, I would be concerned. Civilization 4 does something a little similar and it has enjoyed at least some commercial success, so giving feedback that it's going to think for a while is a possible way to mitigate the concern that the application has froze.

#7 Jacon, can I just invoke smth like t2dSceneGraph::onUpdateScene() from my long calculation function?
Have you met somewhere the articles about performance improving in torqueScript? Probably I’m just using some wrong techniques. I saw a lot of games written on T2D without any performance problem! Btw while my game is playing the CPU usage is always 100%.

#8 I'm not exactly sure what you mean about using something like onUpdateScene().

I'm guessing that this is your AI procedure that is taking so long, since strategy game math is generally not so complicated as to take this long. Identify the problem areas in your script and optimize those, if it's completely unsolvable in script, it might be time to move into modifying the source code (which isn't recommended if it can be avoided). If you're really stuck and unable to devise an immediate solution, move to something else in your programming and provide some sort of "thinking" feedback to the player. The issue does not seem insurmountable, but it will need some careful consideration.

#9 I've already done some code modification. So the operation takes only a half of second now. But the delay is still noticeable.
What I mean about onUpdateScene() - Actually I can divide my long calculation into several consecutive steps. So I thought that between steps I can refresh the screen (make alive the mouse pointer and the game animation and so on). What do you think about this? Is it possible?

#10 It's definitely possible to do split it up and process it in pieces in those little time slices. As long as you know how you'll manage it, it's definitely possible. Just make sure that you don't lose track of what's happening in those segments.

#11 Does animation etc still work between the turns? If so you could add in an animated sand timer to the bottom corner while the AI is worked out. This would let the player know the game hasn't crashed. If you hide the mouse cursor as well, and show it again when the AI is finished, it will stop the uncomfortable feeling of not being able to move the mouse.

#12 Jason, if it is definitely possible how can I do this? I mean how to refresh the screen? Or it will happen only if I run each of my steps through the "schedule" function?

Thanks, Tom, seems the idea with hiding mouse cursor is pretty good.

#13 You would basically invoke a manager for your long process, which would track its state as a member variable. It would then run through a trivial amount of processing, record it's value and then exit until it's called again. It is a very inelegant solution, which I readily admit. This solution is so cumbersome, that I wouldn't even try it myself and would merely use a little icon to show that the computer is thinking.

#14 Ok, let it be little icon and hidden mouse cursor. Thanks a lot.

#15 At the end of the day, this minor pause will not be a game-breaker, so don't sweat it so much.

#16 No problem, good luck :)