Game Development Community

TorqueX and Windows Forms

by Takuan Daikon · in Torque X 2D · 12/11/2008 (6:08 am) · 10 replies

I've frequently wanted to take advantage of the richer UI capabilities of WinForms while developing with TorqueX, to be able to quickly create a UI for setting in-game parameters for things like Sky, Terrain, etc, etc. Nothing beats being able to quickly iterate through several settings in-game in order to view their effects, without having to edit/compile/run each time.

I had assumed that because 'official' WinForms support didn't make it into XNA 2.0, and previous methods I've used to embed XNA applications in a WinForm were cumbersome and fragile, that I wouldn't be able to easily do this with TorqueX.

Turns out I was wrong:

images.daikonforge.com/torque/torquex-winforms.jpg
It was as easy as could be, and took less than five minutes to get running by following these directions on CodeProject.

As you can see from the above snapshot, it works great, and I've yet to notice any real problems other than the fact that other WinForms controls in the application with focus can react to arrow keys. That's easily solved, though, so I'm quite pleased so far and wanted to share :)

#1
12/11/2008 (7:20 am)
Cool! yes, it's possible becuase TX and WF lives in different "air space".
Now the interesting question is how do you mix TX(XNA) and WPF? It's certainly possible with an advent of D3DImage in .net 3.5 sp1. It doesn't work as is since XNA doesn't expose backbuffer, however with some clever hack, it's doable. At PDC 2008, MS officially announced that XNA will support WPF in the next version..

Now even more interesting question, WPF won't be supported on XBox360 in foreseeable future, yet it will be supported on XNA for PC. How is this possible? This will break cross-platform promise by XNA (was that really an absolute requirement? Zune doens't have 3D so it's not really cross-platform anymore), however, it doesn't hurt the XNA community but only helps. I asked GG about having independent network layer even though it won't be cross-platform as an option to PC commnunity, just like WPF support for XNA PC platform only. The simple answer I got from GG is "no" and I ask why not? How many users are working on PC only project compared to cross-platform projects? And we were to have such requirement forever, it will hinder TX development. Is it still the policy GG has on TX?
#2
12/11/2008 (8:03 am)
Interesting article. Thanks! I really liked the section showing XNA running in a web page. I think I shall bookmark and study that page for a good while :)
#3
12/11/2008 (8:04 am)
I do not believe there is a current change in the networking setup for TX3.0, though I am not part of the TX development team. There are already several .Net networking components that are extremely mature and have been used to good effect with XNA projects under Windows.

I'm not sure that splitting our market, which consists largely of people who are using the free TX binary version, is a very sound business decision. Especially when 360 support is one of the keys that many people looking at TX for game development are excited about.

I've often thought that it would be a good idea to be able to create community projects such as this, though the response is usually small and people get bored with the project when it turns from fun to work. But that might be an interesting idea for Pro version users who desire Windows-only functionality.
#4
12/11/2008 (8:22 am)
For what it's worth (probably not a lot), there aren't many of us who speak up so our numbers are largely uncounted, and I want to add my voice to the issue : Count me in with the group of folks who couldn't care less about XBox360 support.

I may care eventually, but I've been working with XNA since before it was even a public Beta (for that matter, I've been playing with TX sporadically since 2006), and MDX before that, and have never in that time felt a need or desire to target a console.

I understand that GG has to make the business decisions that seem best for them, and I do agree for the most part that TX should not have 'Windows-only' functionality, though I am also bummed by the fact that this could potentially limit what I can afford to do with my limited free time without more robust support.

I'd love to see successful community projects which enhance PC/Windows functionality of TorqueX, but David's right that most similar projects run out of steam early and just stagnate.

But sharing info is a Good Thing(tm), so I'll be sure to do so whenever I come across anything that might be interesting to others, and I hope that others will do the same.
#5
12/11/2008 (8:44 am)
Thansk Takuan, I have one other comradery who feels the same.
Having PC only feature does not necesarily break TX cross-platform policy. It is an add-on feature and on Xbox, it will simply be disabled. There will be TX just like right now and add-on components. I believe TX is designed such that components are easily added. This way, we can explore many different features such as physics(PhysX, ODE..), network independent from Live and so on. Being stuck with Live network leave very bad taste in my mouth. PC only feature for Pro users are really great idea if possible.
#6
12/12/2008 (8:03 pm)
I am in that camp too Chris!
#7
12/13/2008 (8:31 am)
Honestly, I've never understood the level of hype over XNA/XBOX360... I guess at a hobbyist/enthusiast level it's kind of neat that you can make games for the 360, but it's such a crippled system that I don't know why it seems to be the predominant focus.

I mean, the .NET Compact Framework that's used for XNA/360 does little to no inlining, has very slow floating point support, has a crippled garbage collector, has incredibly limited video and system memory, and is just generally not performant compared to even a cheap desktop. And insider reports indicate that the .NET CF dev division doesn't consider XNA a priority at all, so it's not even likely that it will be improved at any point in the near future.

And yet, go to any forum where XNA is discussed and it's almost all focused on the 360. Sheesh.

For me, what makes XNA cool is the fact that I can be more productive in general and worry less about low-level issues than I used to 'back in the day'. If I never have to use C++ again, it will be too soon. Even at the novice/hobbyist level where I'm at, XNA makes it possible to make good traction on a game project that will almost certainly never reach any audience but my family and friends, and let's face it, that's going to be the outcome for the vast majority of hobbyist game projects.

I just don't want to have to work three times as hard to mitigate the poor performance on the 360, and there's only so much you can do there without compromising your vision of your game, when I could be spending that time and energy getting **** done.
#8
12/15/2008 (6:44 am)
Okay, so I have found one caveat so far : Anything that relies on the existing Viewport could be thrown off. The method I outlined in the first post doesn't really change the rendering window, but rather renders to the indicated window *also*, so your Viewport and other window-specific objects are still tied to the original (and now hidden) window.

In my case, this meant that the standard Viewport.Unproject() method used for raycasting from mouse coordinates would not work, and had to be replaced with a custom function. Fortunately for me, that's a simple matter of a few lines of code :
public Vector3 Unproject( Vector3 source, Matrix projection, Matrix view, Matrix world )
{

	Vector3 position = new Vector3();
	Matrix matrix = Matrix.Invert( Matrix.Multiply( Matrix.Multiply( world, view ), projection ) );

	position.X = (( source.X / ((float)Width)) * 2f) - 1f;
	position.Y = -((( source.Y / ((float)Height)) * 2f) - 1f);
	position.Z = source.Z / 1f;
	position = Vector3.Transform( position, matrix );
	
	float a = (((source.X * matrix.M14) + (source.Y * matrix.M24)) + (source.Z * matrix.M34)) + matrix.M44;
	if( !WithinEpsilon( a, 1f ) )
	{
		position = (Vector3)(position / a);
	}

	return position;

}

I'm sure other similar situations will crop up now and again, but I'm still of the opinion that these minor annoyances are well worth having the ability to host TorqueX in a WinForm, especially now that I can use the mouse to select in-game objects, etc. :)

images.daikonforge.com/torque/torquex-winforms-groundCursor.jpg
#9
12/15/2008 (4:38 pm)
Hi Takuan, this looks really good, great work! I have to admit that my biggest interest has been XNA/Torque X for Xbox 360. It's interesting to read about others that prefer XNA for Windows projects. Looks like a fun project. The unproject method is a bit of a pain, I think I had to play around with the backbuffer settings to get that working right.

John K.
#10
12/15/2008 (5:47 pm)
Well... I've been a 'line of business' developer since the 90's, so I'm really more of a tools guy I guess. I've never finished a game, I just play around with it because I love learning things, though I'm determined to finish one this time, haha.

My previous rant is really just kind of an exasperated way of trying to get people to recognize that there are some people out there who are totally excited about XNA, but not nearly as excited about the 360, yet to most people doing XNA they seem to be nearly inseparable :)

In any case, I think TorqueX is growing on me quite a bit. At first, I had a lot of enthusiasm because I love component-based design and aggregation as a means of dealing with the evolution of complexity in a project/framework, but then I ran into a lot of problems, but I think I'm coming out the other end and am back to "I'm sure glad I had some experienced and smart people do a lot of the heavy lifting for me!" kind of opinion.

And speaking of heavy lifting... I'm looking forward to seeing how your project is coming along, hint hint.

PS: Thanks for the compliment!!!