Abandoning Torque after six months of development
by Nir Ziso · in Torque Game Builder · 01/25/2007 (3:20 am) · 34 replies
Hello all,
Our company has been developing a card game with Torque for the last six months. Everything was going well until in QA on Pentium 4 machines something very disturbing happened. Torque is taking all available CPU in order to achieve maximum FPS and the PC comes to 100% CPU. Furthermore all animations become jittery or stuck and the mouse becomes jumpy or non responsive.
We tried the forums for answers or hints to no avail. We even have the C++ sources but discovering such a problem late in the development and shortly before the release is not quite possible.
Graphics quality is not the issue either. We run the TGB editor on this P4 without any animations or the game without rendering anything but the background and still the same problems occur. We also downloaded other games like "Puzzle Poker" or "Saints and Sinners Bowling" from Large Animal (By the way great job guys your art and concept rocks!) but the CPU results where the same.
Moreover OpenGL issues are a headache when you get to the end user. Telling users to update the drivers of their graphics card is inconceivable, especially when our competitors who wrote their games in pure MFC don't ask that of them. We can't go full screen either. Again our competitors don't ask that from their users and neither can we.
When you bring a product to the end user if you want him to buy it, giving answers such as "Play in full screen" or "Update your graphics card drivers" are unacceptable.
Finally I must point out that while compiling the C++ sources we discovered that the warning level on the Visual Studio compiler was set to 1. This means "Don't bother me with your warnings" (more or less). When changing it to level 3 we got 1500 warnings. After 3 days we are down to 300 and stopping the effort. Again the answers to questions posted to the developers where unacceptable. Cleaning up your code from warnings is not "obsessive compulsive" or "tedious". It is best practice.
So for now we abandon Torque and plan to rewrite the whole game in Flash or Director.
When the product becomes mature enough and the "obsessive compulsive" and "tedious" tasks of warnings cleanup are done with in the "nearish" future (GG developers who answered to me as such know what I am talking about) we may reconsider trying our luck again with Torque.
We are all here are C++ developers but we BOUGHT a game engine not an open source product. We want to extend the engine not fix it or change it and especially not getting into the task of having to "adjust the engine's amount of CPU usage" (again GG developers answer) and have to merge it again in the next engine version and try to tackle any new CPU killers in the engine. After all we want to develop a game not a game engine.
Oh and by the way you can flame me all you want for this post but facts are facts and unprofessional answers were the last drop.
Best Regards and good luck with your games everybody.
New Reign R&D team.
Our company has been developing a card game with Torque for the last six months. Everything was going well until in QA on Pentium 4 machines something very disturbing happened. Torque is taking all available CPU in order to achieve maximum FPS and the PC comes to 100% CPU. Furthermore all animations become jittery or stuck and the mouse becomes jumpy or non responsive.
We tried the forums for answers or hints to no avail. We even have the C++ sources but discovering such a problem late in the development and shortly before the release is not quite possible.
Graphics quality is not the issue either. We run the TGB editor on this P4 without any animations or the game without rendering anything but the background and still the same problems occur. We also downloaded other games like "Puzzle Poker" or "Saints and Sinners Bowling" from Large Animal (By the way great job guys your art and concept rocks!) but the CPU results where the same.
Moreover OpenGL issues are a headache when you get to the end user. Telling users to update the drivers of their graphics card is inconceivable, especially when our competitors who wrote their games in pure MFC don't ask that of them. We can't go full screen either. Again our competitors don't ask that from their users and neither can we.
When you bring a product to the end user if you want him to buy it, giving answers such as "Play in full screen" or "Update your graphics card drivers" are unacceptable.
Finally I must point out that while compiling the C++ sources we discovered that the warning level on the Visual Studio compiler was set to 1. This means "Don't bother me with your warnings" (more or less). When changing it to level 3 we got 1500 warnings. After 3 days we are down to 300 and stopping the effort. Again the answers to questions posted to the developers where unacceptable. Cleaning up your code from warnings is not "obsessive compulsive" or "tedious". It is best practice.
So for now we abandon Torque and plan to rewrite the whole game in Flash or Director.
When the product becomes mature enough and the "obsessive compulsive" and "tedious" tasks of warnings cleanup are done with in the "nearish" future (GG developers who answered to me as such know what I am talking about) we may reconsider trying our luck again with Torque.
We are all here are C++ developers but we BOUGHT a game engine not an open source product. We want to extend the engine not fix it or change it and especially not getting into the task of having to "adjust the engine's amount of CPU usage" (again GG developers answer) and have to merge it again in the next engine version and try to tackle any new CPU killers in the engine. After all we want to develop a game not a game engine.
Oh and by the way you can flame me all you want for this post but facts are facts and unprofessional answers were the last drop.
Best Regards and good luck with your games everybody.
New Reign R&D team.
#23
01/29/2007 (12:52 pm)
I was wondering because I don't know what compiler optimizations you are working with. I haven't seen what you're dealing with and I've been playing with TGB (and TGE) for some time, so I'm grasping at straws.
#25
01/29/2007 (1:00 pm)
@Nir - If profiler didn't help, then maybe (and I don't mean this to be a stab, but serious advice) your team should get some instruction on how to use it properly.
#26
It worked better on my single core at home a 3.2GH Prescott (it is 23:00 here) and what I got is that the MainLoop taks most of the time followed by PlatformProcessMain and ProcessTimeEvent, which is what we suspected in any case.
What can ou do? Cancel the mail loop? We even went as far as putting sleep(10) or even less there and of course felt the impact on the animations
01/29/2007 (1:03 pm)
@DavidIt worked better on my single core at home a 3.2GH Prescott (it is 23:00 here) and what I got is that the MainLoop taks most of the time followed by PlatformProcessMain and ProcessTimeEvent, which is what we suspected in any case.
What can ou do? Cancel the mail loop? We even went as far as putting sleep(10) or even less there and of course felt the impact on the animations
#27
The profiler didn't behave well for some reason on our dual cores. I don't know why. After all the TDN article on the subject is clear. profilerEnable(true), profilerdump, profilerEnable(false). I just made it on a single core. Read my previous post for the results.
01/29/2007 (1:06 pm)
@Jonathon The profiler didn't behave well for some reason on our dual cores. I don't know why. After all the TDN article on the subject is clear. profilerEnable(true), profilerdump, profilerEnable(false). I just made it on a single core. Read my previous post for the results.
#28
01/29/2007 (1:16 pm)
The profiler dump is a hierarchical output. MainLoop takes up, not most, but all of the CPU time that the game gets, because every other function is called from within the main loop of the game.
#29
Torque. Main Loops do take all the CPU they need. Otherwise they woudln't be Main Loops would they?
Although as far as MFC goes we can make a very academic argument to the contrary on the subject. In this hierarchy MainLoop of course gets 99.9% and GameProcessEvents 79%, PlatformProcessMain sometimes 19% and sometimes 67% instead of GameProcessEvents but by the name of them I think they are almost the same thing and ProcessTimeEvent is a close competitor at 30%+.
If some Gui control or sprite was as such maybe there was something to do but alas I don't see any solution here.
01/29/2007 (1:27 pm)
I know Pat. It can't be any other way. I have coded in MFC, COM/DCOM, SWING, SWT, .NET, WIN32, FLASH and Torque. Main Loops do take all the CPU they need. Otherwise they woudln't be Main Loops would they?
Although as far as MFC goes we can make a very academic argument to the contrary on the subject. In this hierarchy MainLoop of course gets 99.9% and GameProcessEvents 79%, PlatformProcessMain sometimes 19% and sometimes 67% instead of GameProcessEvents but by the name of them I think they are almost the same thing and ProcessTimeEvent is a close competitor at 30%+.
If some Gui control or sprite was as such maybe there was something to do but alas I don't see any solution here.
#30
01/29/2007 (1:31 pm)
Well I am calling it a night. Please do not get offended if I don't respond to any other posts. It's 23:30 and I am going to count sheep. Good night/day to all.
#31
01/29/2007 (1:35 pm)
I would run the game, get to a clear case of where the game is, or would slow down, start profiling, perform actions which would cause the game to slow down, stop profiling, and dump. Then post that profiler dump. 
#32
It seems as if you've been having an awful lot of trouble creating a Card game in over six months with TGB, and that concerns me.
I've attached a card game created with TGB 1.1.3 by a single developer in a week below in hopes that it might help you. I've also tried this game's card dealing animations with a time interval of 10 and the animations seem fine with really low CPU usage on my single-core and dual-core machines that I've used to test it.
SolitaireGame.zip
Best of luck to you and yours on this project!
-Justin
01/31/2007 (1:05 am)
Nir,It seems as if you've been having an awful lot of trouble creating a Card game in over six months with TGB, and that concerns me.
I've attached a card game created with TGB 1.1.3 by a single developer in a week below in hopes that it might help you. I've also tried this game's card dealing animations with a time interval of 10 and the animations seem fine with really low CPU usage on my single-core and dual-core machines that I've used to test it.
SolitaireGame.zip
Best of luck to you and yours on this project!
-Justin
#33
I got the same problem than Nir with dual core processors and debug/profiler on: my computer hangs on. However, i tend to think it is more related to OS (WinXP SP2) problem than TGEA (TSE) as I got this typical 'computer freeze problem' with other applications (like FireFox or others). But for sure, everytime I tried to debug/profile TGEA, it just freezes my computer... I'm still investigating on this and as soon as I got a hint I will let you know.
Concerning the speed, I just want to add that Torque (TGE 1.3 and TSE first milestone, did not try the latest releases on my low-end computer) works fine on a laptop PentiumM / 512 Mb (did not try TGB).
01/31/2007 (2:29 am)
Just to add few remarks,I got the same problem than Nir with dual core processors and debug/profiler on: my computer hangs on. However, i tend to think it is more related to OS (WinXP SP2) problem than TGEA (TSE) as I got this typical 'computer freeze problem' with other applications (like FireFox or others). But for sure, everytime I tried to debug/profile TGEA, it just freezes my computer... I'm still investigating on this and as soon as I got a hint I will let you know.
Concerning the speed, I just want to add that Torque (TGE 1.3 and TSE first milestone, did not try the latest releases on my low-end computer) works fine on a laptop PentiumM / 512 Mb (did not try TGB).
#34
One thing I noticed concerns function sceneWindow2D::onMouseUp() in file mouseInputs.cs. This callback will receive a call when the user switches from the game back to Level Editor, but at a time when the Scene Window no longer has a Scene Graph. An error message appears in the console as a consequence
I realized that a callback like sceneWindow2D::onMouseUp() had better not assume that the scenegraph is still defined. Inserting the following code at the beginning of the function prevents problems:
Yes, my comment is a bit off topic, but I decided starting a new thread was probably not warranted.
Cheers, Art
02/08/2007 (2:38 am)
Justin DuJardin wrote:Quote:I've attached a card game...SolitaireGame.zipExamining this code taught me a lot, so thanks for posting it.
One thing I noticed concerns function sceneWindow2D::onMouseUp() in file mouseInputs.cs. This callback will receive a call when the user switches from the game back to Level Editor, but at a time when the Scene Window no longer has a Scene Graph. An error message appears in the console as a consequence
Solitaire/gameScripts/solitaireGUI.cs (267): Unable to find object: '' attempting to call function 'pickPoint'
I realized that a callback like sceneWindow2D::onMouseUp() had better not assume that the scenegraph is still defined. Inserting the following code at the beginning of the function prevents problems:
if ( !isObject( %this.getSceneGraph() ) ) { return ; }Yes, my comment is a bit off topic, but I decided starting a new thread was probably not warranted.
Cheers, Art
Torque Owner Nir Ziso
Default Studio Name
Bottom line Pat we are stuck, frustrated and disappointed.