I don't have a MSDN sub, I used to whilst still at university, through MSND-AA, but that's gone now.

Yeah I'll gladly use any existing GUI framework that's skinnable, programming one would take a while.

Nooooo WinForms integration isn't going into XNA 2.0 =( they had to drop a feature to make the release on time. Maybe it'll go into the XNA 2.0 Refresh.

BUT all is not lost, it seems it is already possible to host an XNA game in a WinForm... hmm.

Bastards!
We can only hope .
If you read that in the MSDN forums, that may have been a thread that I started a while back. A couple people responded, but there didn't seem to be a straightforward way to do it at the time.

Form! It's running in a form!





I put the window to the top right corner to simulate how the combat engine looked in BOTF. also put in some buttons and such to fight over airspace, see how they behaved (well).

I'll make it downloadable in a bit, just sorting out some bugs. What's next then? Put it in WPF and experiment more?

Hey cool, I guess the controls can overlap as long as they're not translucent (notice the white background behind the rounded corners of the buttons). It we had black behind the controls, it'd be pretty hard to notice... Nice work !

Unfortunately, I can't run it for some reason--I've had the XNA 1.0 refresh installed for some time now, and I tried repairing it, but no go. My desktop workstation is out of commission for the moment, but I have a Mobility Radeon X1600 256mb card in my laptop, which should be sufficient to run it. I'll try installing XNAGSE and see if that helps.

I attached it to a debugger, and I was able to determine that a FileNotFoundException is getting thrown, but I couldn't get a stack trace or check the internal exception. I'll do some more experimentation.

Okay, I just transferred it to my sister's comp and it ran it fine (better quality than this one actually, it must have had all the anti aliasing and anistropy settings at max) but anyway she hasn't got any of the IDEs/SDKs, just .NET and XNA redistributables. Both machines are using .NET 3.0, but I'll update to 3.5 now and try it.

Edit: It works fine in 3.5

That looks nice!

Quick question... Does that screenshot mean what I think it means? That the 3D combat mode will be a 3rd person flight configuration and not the traditional top-down RTS style of the original BOTF?

I'd be totally in favor of that (ah just remember when I picked up and finished Wing Commander III and IV both in one weekend on hard settings ). no seriously, some sort of "klingon academy"-battle style would totally work for me! If there's a pause button or some tactical timer which causes a pause then to rearrange the other AI-controlled ships of yours, then that'll be it .

Well, the defiant game was just to let me try some techniques out quickly, but I have had a lot of fun with it, and it would be a shame to just let it go. Maybe when you only have one ship, and you are fighting another single ship, then you get the option to both agree to a duel. Which should be fun if both sides are equally matched

But I think the rest of the fights should be done the traditionial BOTF style, with top down and turn based combat, + enhancements that we think of, it should not stray too far, otherwise it's just not BOTF

Good it runs

String's right .

btw. the game runs fine with me!

I don't see why it should be limited to turn based combat though, even if it makes the combat a little more complicated it would be nice.

Regards Wolfe

real-time makes it a bit challenging for the "slower-handed" people, i.e. the clicky-clicky teens got a not-so-slight advantage over the more calm-playing guy so to speak .

Ai? Calm playing guy you say? You will have to speak up sunny. I am a little hard of hearing anymore.

yeah, I fear we should also make the fonts scalable to what 30 or 40 pixel size for better reading purposes ..

no, I just think real-time doesn't fit here well-enough (except for a klingon academy-style combat, where you actually fly and command one single ship and got tactical/strategical stops where you can assign new orders to your team). plus I didn't like games like homeworld or starcraft

respect /= 10;

Strings, have you been able to run it on a Vista PC? Try making sure all your XNA assembly references have "Specific Version" set to 'False'.

strangely however, I liked warcraft 2 (partly because it's like dune2 and also has a restriction on how many units you can move at a time) a lot...

oh man, I used to pwn at Warcraft II, like a decade ago... good times

yep I've run it on this PC which is Vista, and on my sister's it is XP. So still can't get it to work ?

Not yet--I'll try fiddling with it this weekend.

Edit: w00t, I got it working--just had to install a bunch of DirectX updates. Looks pretty damn good .

..and now imagine something like this for fast-paced ground combat (I know it's a bit odd resp. off-the-original "flight path" but why not take it into some loose consideration as a bonus/add-on thing. jig could provide us with unique ground building models for each race for example )..:

Maybe for Supremacy 3: The Search for Supremacy 2 .

As i recall Pax Imperia had something similar, so it isn't a way off idea.

Regards Wolfe

I saved the source on my harddrive for the meantime

@cdr: i believe even gavin babbled something about a c&c ground combat in his interviews. I rather like the idea plus the game is fully workin except for an AI (well, sir p.'s part) and the models (jig and others maybe).

I don't know about Pax Imperia, but Imperium Galactica had it, and MoO2/MoO3 had something much simpler, but still better than nothing (i.e. what BotF had).

I really like the idea of making ground combat more visual and interactive, because having your own army of klingons with batleths killing stuff is well the most awesome thing ever, only dinosaurs with laser turrets is slightly more awesome.
Well, definately an idea to keep in mind then

So mike, shall we try and test the interop of Windows.Form with embedded XNA game + WPF?

Edit: I made cadet woohoo! /salutes

@strings: Well, apparently you can't have WPF controls overlay Windows Form controls (including the XNA control) because they'll get rendered over. However, you can host WPF controls on top of the XNA control inside a Windows.Form, though you get the same opaque background behind them (I set the form background to Black instead of White in this example). Not sure if it's worth the hassle, though.

@mike
sorry for asking so many questions in this post ... take your time, I'm gonna grab some food and go to bed early today. Drove a lot, am tired


Clarify a bit more for me please, I haven't programmed much in Forms before so I am unfamilar with the term "control". I'm more in tune with the Java.Swing terms. Here's a guess, all GUI elements are controls?

So, can't we make sure that we have no overlay between WPF parts and Windows Form parts? Or am I getting the concept of overlay wrong?

Example scenario, when a tactical battle comes up, we start hosting the Winforms with the XNA in WPF, since the galactic map (or even the entire galactic screen) is not in use anyway during a battle, is it any problem if it is rendered over? If we can close the hosted winforms when gameplay returns to the galactic screen then that should be problem solved? ...or am I skipping a lot of the complexity in between?

I just ran WpfInWinforms, runs fine, interesting how you got rid of all that space I put in around the XNA control, how did you do that? :p cool how you can resize on the fly now too, squish goes the defiant.

PS - It wouldn't limit me at all to develop the XNA game in a Winform all the time, so how insane would it be to have Winforms host Supremacy? can we can get seamlessness that way? (ie be able to switch between XNA and WPF at will?)

A 'Control' in WinForms is akin to a JComponent in Swing. A 'Form' in WinForms is akin to a JFrame in Swing, though a 'Form' actually inherits from 'Control'... (I think). WPF is a bit different, but for our purposes a WPF 'Control' is akin to a WinForms 'Control', and a WPF 'Window' is akin to a WinForms 'Form'.


Basically, when you host a WinForms Control inside a WPF Control (like a Window), the WinForms Control gets rendered separately from the rest of the WPF Control, and all the WPF content within the same bounding box as the hosted WinForms control gets rendered over. That means that you can't have a WPF window hosting a WinForms XNA control with a WPF GUI on top of it, because the WPF GUI would always get rendered over by the WinForms XNA renderer. You'd have to ensure that there is no overlap between the WPF GUI and the XNA control, sort of like how you did with your DefiantGame v2.5 (with the game control in the top-right). However, if you host the XNA control in a Windows Form, and host the WPF GUI in the *same* Windows Form (on top of the XNA control), then that would work exactly like the WinForms buttons in your DefiantGame--they can overlay the XNA control, but they will have an opaque bounding-box background.


No, that is not a problem. In fact, I always assumed it would be the case that the XNA control would render on top of the other game screens. That's one reason why all popup dialogs are separate windows. The only issue is that you wouldn't be able to host the XNA control inside a WPF control and have a nice WPF GUI on top of it to provide input for XNA.


I just hosted your Defiant Control in a new Window and set the 'Dock' property to 'Fill'. I didn't use your existing window with the left and bottom margins.

Pretty insane . Fortunately, I don't see any reason why we'd need to do that, as we can get it pretty seamless just hosting the XNA WinForms control inside WPF.

All clear, thanks for the education


Then we wont have a nice WPF GUI on top of it, but around it. As long as the coordinates of the mouse and any mouse left/right click events are passed to a listener in XNA then we're good to go

No problem there .

this could be interesting to read about botf tac combat design principles..: http://www.freeorion.org/forum/viewtopic.php?p=23726