The main loop
by Neil Marshall · in Torque Game Engine · 05/05/2005 (1:51 pm) · 8 replies
I'm currently in the process of converting Torque to work as a browser plugin.
I've got the engine compiling as a scriptable plugin and the engine launches in it's own window (Sort of like Think Tanks). The snag that I've run into is the main loop in main.cc.
When the engine runs it enters an infinate loop to process all the frames. But this stops the web page from responding because the browser never gets to process anything.
Does anyone have any ideas on how to allow for other interactivity? Remove the infinate loop and somehow use a timer? Place the whole engine in a second thread? Something else?
I've got the engine compiling as a scriptable plugin and the engine launches in it's own window (Sort of like Think Tanks). The snag that I've run into is the main loop in main.cc.
When the engine runs it enters an infinate loop to process all the frames. But this stops the web page from responding because the browser never gets to process anything.
Does anyone have any ideas on how to allow for other interactivity? Remove the infinate loop and somehow use a timer? Place the whole engine in a second thread? Something else?
#2
(Notice that even the url in the url bar is not displaying when torque is running)
hm. I'm starting to wonder if having 2 sets of events firing is causing the problem. The plugin has a wm_paint and torque has it's own event callback function (Not sure what the proper name for it is. message pump?). I'm wondering, if I stop torque from popping up in it's own window and actually get it to draw in the plugin, if it'll start responding properly.
It's a lot of work just to find out if thats the problem though.
05/07/2005 (9:18 am)
I know think tanks runs in a separate process... I was just saying it LOOKs the same as what TT does. www.eightlines.com/neil/temp/progress1.jpg(Notice that even the url in the url bar is not displaying when torque is running)
hm. I'm starting to wonder if having 2 sets of events firing is causing the problem. The plugin has a wm_paint and torque has it's own event callback function (Not sure what the proper name for it is. message pump?). I'm wondering, if I stop torque from popping up in it's own window and actually get it to draw in the plugin, if it'll start responding properly.
It's a lot of work just to find out if thats the problem though.
#3
05/07/2005 (10:58 pm)
These all sound like scary win32 API problems. I'm no help there. :)
#4
From what you describe I would guess you have something like:
-Browser needs plug-in
-browser calls "Torque plug-in start" and waits for it to init and return so it knows it successfully started.
-"Torque plug-in start" goes right to your main loop and never exits
thus the browser is waiting for ever for a return.
My suggestion is to is what you already suggested, spawn the main loop in a separate thread so that your "Torque plug-in start" launches the main loop in a separate thread then return to the browser. I can help you with some code to do that if you are using Microsoft Visual Studio 6.0 (Not sure how portable the process is to other applications.
Hope that helps.
Edit -PS - The behavior you see sounds identical to what the "Adobe Accrobat" plugin does while its loading. Locks up the browser until its through its init. Upsets me when I accentently click on a link thats goes to a PDF.
05/08/2005 (4:41 am)
I have seen similar behavior before (although I have never tried to make a web plug in) From what you describe I would guess you have something like:
-Browser needs plug-in
-browser calls "Torque plug-in start" and waits for it to init and return so it knows it successfully started.
-"Torque plug-in start" goes right to your main loop and never exits
thus the browser is waiting for ever for a return.
My suggestion is to is what you already suggested, spawn the main loop in a separate thread so that your "Torque plug-in start" launches the main loop in a separate thread then return to the browser. I can help you with some code to do that if you are using Microsoft Visual Studio 6.0 (Not sure how portable the process is to other applications.
Hope that helps.
Edit -PS - The behavior you see sounds identical to what the "Adobe Accrobat" plugin does while its loading. Locks up the browser until its through its init. Upsets me when I accentently click on a link thats goes to a PDF.
#5
I'm using VS7 (.NET 2003) and I'd very much be interested in seeing your threading code.
Right now this is how I have it working.
-I load the web page.
-The plugin loads.
-Click a link which executes a command in the plugin via javascript.
-The plugin activates game->main in winwindow.cc
-The window launches and enters the loop that causes the game to play.
-When you exit the game the plugin goes back to the web page.
PS To fix acrobat, run this. It seriously speeds it up and I've never seen it hinder the rendering of a pdf. http://www.snapfiles.com/get/pdfspeedup.html
05/08/2005 (7:40 am)
Yes that's pretty much what happens.I'm using VS7 (.NET 2003) and I'd very much be interested in seeing your threading code.
Right now this is how I have it working.
-I load the web page.
-The plugin loads.
-Click a link which executes a command in the plugin via javascript.
-The plugin activates game->main in winwindow.cc
-The window launches and enters the loop that causes the game to play.
-When you exit the game the plugin goes back to the web page.
PS To fix acrobat, run this. It seriously speeds it up and I've never seen it hinder the rendering of a pdf. http://www.snapfiles.com/get/pdfspeedup.html
#6
An example of multi-threading using Microsoft Visual Studio can be seen here. It uses the "_beginthread" from the "process.h" lib to spawn a function into a separate thread allowing the spawning code to continue. This is what I have used in my non-torque coding to get an another thread running within my C++ programs.
Disclaimer - The issues, concerns, things to look such as locking of vars are beyond the scope of this thread. Also I have not tried to ever multi-thread Torque. I do know of many an issue with threading certain functions. One might be ok with sending the entire main to its own stand-alone thread such as what the author of this thread is trying to do.
Hope that helps,
Edit - Fixed my disclaimer.
05/16/2005 (10:30 am)
Sorry for the delay in responding.An example of multi-threading using Microsoft Visual Studio can be seen here. It uses the "_beginthread" from the "process.h" lib to spawn a function into a separate thread allowing the spawning code to continue. This is what I have used in my non-torque coding to get an another thread running within my C++ programs.
Disclaimer - The issues, concerns, things to look such as locking of vars are beyond the scope of this thread. Also I have not tried to ever multi-thread Torque. I do know of many an issue with threading certain functions. One might be ok with sending the entire main to its own stand-alone thread such as what the author of this thread is trying to do.
Hope that helps,
Edit - Fixed my disclaimer.
#7
05/16/2005 (11:46 am)
Torque already implements a bunch of thread primitives. You might look into using those...
#8
Instead I split up the main loop function into 3.
Init()
Loop()
and End()
Then in the loop() function, after it draws the screen, I create a windows message which tells the message pump(?) to call loop again. If end() is called, then a member variable that the message pump can read is set and no more frames will be drawn.
It seems to work pretty well. I ran it for 12 hours with no crashes or anything. The only problem is for some reason the mouse isn't too responsive when in 2D dialogs. If anyone has any suggestions as to why that would be, I'm all ears :)
05/25/2005 (9:57 am)
Just in case anyone in the future would like to know how I solved this, I did it by using neither timers nor threads.Instead I split up the main loop function into 3.
Init()
Loop()
and End()
Then in the loop() function, after it draws the screen, I create a windows message which tells the message pump(?) to call loop again. If end() is called, then a member variable that the message pump can read is set and no more frames will be drawn.
It seems to work pretty well. I ran it for 12 hours with no crashes or anything. The only problem is for some reason the mouse isn't too responsive when in 2D dialogs. If anyone has any suggestions as to why that would be, I'm all ears :)
Associate Kyle Carter