http://thetoolsmiths.org/2009/06/03/communication-issues-improving-turnaround/ Mon, 08 Mar 2010 23:40:21 +0000 http://wordpress.org/?v=2.9.2 hourly 1 http://thetoolsmiths.org/2009/06/03/communication-issues-improving-turnaround/comment-page-1/#comment-486 The Dependency Question « The Toolsmiths Tue, 01 Sep 2009 16:39:56 +0000 http://toolssig.wordpress.com/?p=252#comment-486 [...] during development so that you can protect against mismatched resource bugs, and, lastly, use a robust shared command system to transmit changes to a running game to shorten turn around [...] [...] during development so that you can protect against mismatched resource bugs, and, lastly, use a robust shared command system to transmit changes to a running game to shorten turn around [...]

]]> http://thetoolsmiths.org/2009/06/03/communication-issues-improving-turnaround/comment-page-1/#comment-485 Jay Taoko Thu, 04 Jun 2009 17:14:56 +0000 http://toolssig.wordpress.com/?p=252#comment-485 Excellent article! And very timely... We have a tool that uses some of the principles you mentioned to initiate communication between a program running on a console (or PC) and a tool on a PC. We created it to let programmers expose parameters that can be modified by artists and designers during runtime. No need to modify the code and recompile. At the core, we use a TCP/IP connection to initiate communication between the tool and the instrumented program. The program and the tool exchange XML text packets to communicate. But we are planning binary packets for things like texture data for instance. Just like you said, the instrumented program has a thread running in the background to listen to incoming command from the tool. We have a demo of it here: http://inalogic.com/MainSite/component/content/article/6-dev-tools/29-devtool-demo Excellent article! And very timely… We have a tool that uses some of the principles you mentioned to initiate communication between a program running on a console (or PC) and a tool on a PC. We created it to let programmers expose parameters that can be modified by artists and designers during runtime. No need to modify the code and recompile.
At the core, we use a TCP/IP connection to initiate communication between the tool and the instrumented program. The program and the tool exchange XML text packets to communicate. But we are planning binary packets for things like texture data for instance.
Just like you said, the instrumented program has a thread running in the background to listen to incoming command from the tool.
We have a demo of it here: http://inalogic.com/MainSite/component/content/article/6-dev-tools/29-devtool-demo

]]>