by date
Torque X - Break through/Break down
Torque X - Break through/Break down
| Name: | Andrew Douglas |  |
|---|---|---|
| Date Posted: | Jan 27, 2007 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Andrew Douglas |
Blog post
I really want to love Torque X. So many things are done right (finally), and yet there are some underlying issues (some of which are XNA related more than Torque related) that worry me.
GUI - Not having a GUI editor is really painful. Not having a fully fleshed out GUI system *still* is even more unacceptable since Avalon/WPF has shipped for the same platforms that support XNA. The really big deal is that XNA and WPF have major "air space" issues where you can't overlap or easily integrate the two. It's taken me a couple of nights and quite a few headaches to even get WPF dialogs to work and play well with XNA. Note: if you want to do this, I've found that letting the xna app be the "host" and simply have it create the WPF dialogs is a lot easier to deal with and resolves the issues of getting the xna app to get the focus when it should. If you need code samples, holler.
Networking - I realize the whole point of moving to Torque X is to give me the 1000% boost I need to get Jabber/XMPP integration in My Bogle, but knowing that it's going to be a custom solution that we're going to have to maintain is troubling.
Abstracting too far - I watched this great video with some compiler architects at Microsoft that were talking about how the were building in Functional programming language features into things like C# and VB. But the way they were doing it was not at the expense of providing low level/imperative programming methodology which meant that you get the best of both worlds - the high level, abstracted interface and the low level, "I just need to reference that handle" kind of code. The thing is, I've already run into issues where Torque X and XNA have abstracted out relevant details. The "Game" class is suppose to make life easier for people, but when I need to tell the game class exactly what device information to use (say, so that I can embed it inside my own hwnd), I can't because it's wrapped up and hidden away. Granted, I'll be buying the source (when it becomes available), but I should haven't to if the abstractions that had been done in a more "tiered" approach where I can work at the high level abstraction when I want to do something quick and easy, but when I need to I can still hook into the low level guts.
Mouse (and to some extent, keyboard) events - I've seen several people working on this here and there, in forums and projects.. and I understand the model that is being used.. but at the same time, if you're going to force me to use your model for tracking things like is my mouse over my sprite - then make the components that I need to easily track it. Certain use cases in a 1.0 product are bound to be more difficult and time consuming then others... but since there's not framework in place that's even half-way decent, it's going to be causing a lot of developers a lot of pain. I think this is one of the best examples that XNA has gotten fairly tightly focused on XBox 360 hobbiest and not at windows indie developers.
But the good news in all of this is that I am moving forward. I have gotten my dialogs, written in WPF to show up and integrate to a workable level and we'll be tightening the integration as we go along. I even have that screenshot I've been talking about - this is just a Programmer Art rendition of the login screen that I'm forcing you to enter before getting into Tank Buster. The great thing is, I can hand the xaml file over to someone who knows better, and they can make it look even better, add animations and effects, etc... without breaking any code. It should be noted, that although it may not be really pretty right now, it is all vector graphics with no bitmaps to be seen. And to think - I was *this* close to giving up on the whole WPF/Torque X thing - but instead of breaking down, I've broken through.. analysis paralysis is over and I can finally get some work done. Yippee!
Enjoy:
-Andrew Douglas
theoreticalgames.com
GUI - Not having a GUI editor is really painful. Not having a fully fleshed out GUI system *still* is even more unacceptable since Avalon/WPF has shipped for the same platforms that support XNA. The really big deal is that XNA and WPF have major "air space" issues where you can't overlap or easily integrate the two. It's taken me a couple of nights and quite a few headaches to even get WPF dialogs to work and play well with XNA. Note: if you want to do this, I've found that letting the xna app be the "host" and simply have it create the WPF dialogs is a lot easier to deal with and resolves the issues of getting the xna app to get the focus when it should. If you need code samples, holler.
Networking - I realize the whole point of moving to Torque X is to give me the 1000% boost I need to get Jabber/XMPP integration in My Bogle, but knowing that it's going to be a custom solution that we're going to have to maintain is troubling.
Abstracting too far - I watched this great video with some compiler architects at Microsoft that were talking about how the were building in Functional programming language features into things like C# and VB. But the way they were doing it was not at the expense of providing low level/imperative programming methodology which meant that you get the best of both worlds - the high level, abstracted interface and the low level, "I just need to reference that handle" kind of code. The thing is, I've already run into issues where Torque X and XNA have abstracted out relevant details. The "Game" class is suppose to make life easier for people, but when I need to tell the game class exactly what device information to use (say, so that I can embed it inside my own hwnd), I can't because it's wrapped up and hidden away. Granted, I'll be buying the source (when it becomes available), but I should haven't to if the abstractions that had been done in a more "tiered" approach where I can work at the high level abstraction when I want to do something quick and easy, but when I need to I can still hook into the low level guts.
Mouse (and to some extent, keyboard) events - I've seen several people working on this here and there, in forums and projects.. and I understand the model that is being used.. but at the same time, if you're going to force me to use your model for tracking things like is my mouse over my sprite - then make the components that I need to easily track it. Certain use cases in a 1.0 product are bound to be more difficult and time consuming then others... but since there's not framework in place that's even half-way decent, it's going to be causing a lot of developers a lot of pain. I think this is one of the best examples that XNA has gotten fairly tightly focused on XBox 360 hobbiest and not at windows indie developers.
But the good news in all of this is that I am moving forward. I have gotten my dialogs, written in WPF to show up and integrate to a workable level and we'll be tightening the integration as we go along. I even have that screenshot I've been talking about - this is just a Programmer Art rendition of the login screen that I'm forcing you to enter before getting into Tank Buster. The great thing is, I can hand the xaml file over to someone who knows better, and they can make it look even better, add animations and effects, etc... without breaking any code. It should be noted, that although it may not be really pretty right now, it is all vector graphics with no bitmaps to be seen. And to think - I was *this* close to giving up on the whole WPF/Torque X thing - but instead of breaking down, I've broken through.. analysis paralysis is over and I can finally get some work done. Yippee!
Enjoy:
-Andrew Douglas
theoreticalgames.com
Recent Blog Posts
| List: | 03/03/07 - Cooperative Control: Hello Whirled! 01/27/07 - Torque X - Break through/Break down 01/20/07 - Online multiplayer on the brain 01/06/07 - My Bogle moving to Torque X 09/06/06 - Alpha and Dragon*Con 08/14/06 - My Bogle Sculpture 07/24/06 - My Bōgle: Rules Rules Rules 07/21/06 - Funniest Game Ever? |
|---|
Submit your own resources!| Jonathon Stevens (Jan 27, 2007 at 14:17 GMT) |
| Andrew Douglas (Jan 27, 2007 at 20:46 GMT) |
1. Create a new StarterGame project
2. go to the game.cs and add this line directly above "Main" because WPF requires STA. You can get around this with threading and setting the thread to STA, but it's a pain in the neck, trust me.. I've tried :)
[System.STAThreadAttribute()]
3. add a new WPF Window to your application. If you don't see this in the list of items to add, then you don't have .net 3.0 and the WPF extensions for visual studio installed. Get them Microsoft :)
4. unfortunately, there are some missing pieces in the project. I add references to system.xml and system.data and then in order to get the InitializeComponent stuff in WPF to be built automagically for you, you have to modify the csproj file in notepad. Right above the closing </Project> tag, add the following:
<Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
5. then all you've gotta do is show your form. For this example, go to your game.cs or maybe inside your gui .cs files, you can add these two lines of code:
StarterGame.Window1 form = new StarterGame.Window1();
form.ShowModal();
6. Run the game.
You can get away with not showing modal, but be aware it's going to be in a separate window. To get it all to work in the same window, you would need to have control over the device creation so you could tell it what window handle to use. There are airspace rules you have to follow when it's in the same window too, but its kinda irrelevant at this point for torquex because as far as I can tell (and I'd loved to be proven wrong), you can't inject yourself into the creation of the device as that's all happening inside the torquegame class.
Enjoy!
You must be a member and be logged in to either append comments or rate this resource.
