6

In C# WinForms whenever making a small game here or there, I would write up a quick class that was a subclass to System.Windows.Forms.Panel and in the constructor, setting DoubleBuffered to true. Then you could override the OnPaint method to display game elements. I've done this for 2 or 3 years now, but I'm really trying to embrace WPF and XAML, I really like it for regular application layouts. What equivalent is there to doing this in WPF?

Corey Ogburn
  • 24,072
  • 31
  • 113
  • 188

4 Answers4

4

UIElement.OnRender.

To be used sparingly; it's not as efficient.

It's a bit of a paradigm shift.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Rei Miyasaka
  • 7,007
  • 6
  • 42
  • 69
4

Not the answer you seek, but: you shouldn't use WPF for games. Stick with Forms (which won't be dumped by MS, since WPF isn't superseding Forms) or try XNA if you want to go to the next level.


UPDATE: I answered the question very quickly yesterday, because I was in a hurry and because I also looked into WPF in order to do games, so I didn't wanted to left the OP without the proper answer.

Here is the deal:

WPF goal is to simplify rich UI development. First, MS understood that Forms way of coding mix behavior with presentation. This is bad, both for application design as for maintainability. Besides, in Forms, everything has to be coded; The library itself does very little for the user. For example, if you want a button that has a different look, you have to override its Draw method and then, somehow, draw whatever graphic that represents it.

With WPF, behavior is separated from the presentation. For example, what is a button? In windows, we know it to be a box with rounded corners, but look around... your mouse scroll is also a button, even though it looks nothing like the Windows default button. Being a button means having a specific behavior (clicking, mostly), not looking like a box. With WPF, this is very simple. You define a button and then use, say, an image or a text, to present it to the user.

All this comes at a cost, of course; for example, WPF is slower than Forms. Games need to be quick and try not to waste resources. In games, every behavior tends to be coded (not the UI, of course), every presentation is customized (a 2D graphic or a 3D object), so you will have to do a lot of coding anyway. So you are using an expensive technology but throwing away most of its benefits.

But I'm no specialist. You can check this blog, where an ex-Microsoft employee tried, for almost two years, to use WPF for games. And he concludes:

You've probably noticed that the blog hasn't been updated in a while. WPF performance just doesn't seem to be there for serious games, and I've thrown in the towel and will work on games using XNA. I just don't think it's worth fighting the WPF framework...

From there I've drawn most of my conclusions.

Bruno Brant
  • 8,226
  • 7
  • 45
  • 90
  • 2
    I don't want to force a technology onto the project. If WPF is not a proper alternative, I can accept that. – Corey Ogburn Jul 27 '10 at 01:52
  • 1
    Why is Forms more appropriate for games than WPF? – Rei Miyasaka Jul 27 '10 at 01:57
  • 2
    The other blogger was obviously comparing WPF to XNA/DirectX, not to Forms. Neither WPF nor Forms are viable for "serious" games, but I don't buy that Forms is slower than WPF. Forms doesn't offer *any* hardware acceleration, and, if you want to do any kind of special rendering, you're going to be drawing your own pixels on the CPU anyway. Unless you're juggling thousands of on-screen objects (which you shouldn't have to do if you use brushes), WPF is generally faster. Plus, WPF offers shaders and ground-up hardware acceleration for virtually everything -- tiling, resizing, you name it. – Rei Miyasaka Jul 31 '10 at 17:27
  • @Rei: Hadn't considered that. Forms are draw using GDI+ API, which takes about none advantage from hardware acceleration. Considering this, maybe WPF is better than Forms for games. I would like to see a performance comparison between the two API. – Bruno Brant Jul 31 '10 at 18:16
  • 10
    -1. `WPF is slower than Forms` - you have no idea what you're talking about. "stick with forms" is the less intelligent advice ever. You may also tell the OP to "stick" to COBOL or any other dinosaur technology from 100 years ago. – Federico Berasategui Jul 06 '14 at 17:13
  • @HighCore it may or may not be. Neither WPF or Forms are suitable for games, all in all. And I would never tell the OP to stick with COBOL, since it's a very limited (inexpressive and imperative) language. But we were talking technology platform (framework) and not language, right? – Bruno Brant Jul 07 '14 at 18:41
  • @BrunoBrant my point is that (games aside) winforms is completely useless and archaic (pretty much the same as COBOL). "stick to forms" is a completely misleading advice. The only case I can think of where it would be wise to choose winforms as opposed to current, decent technology is needing to run it on Mono on non-Windows computers. – Federico Berasategui Jul 07 '14 at 18:45
  • 2
    @BrunoBrant not to mention your answer doesn't really answer the OP's question about how to "draw" in WPF, which is achieved by simply putting some XAML together (as opposed to the horrible procedural code hacks you need in winforms for anything). – Federico Berasategui Jul 07 '14 at 18:50
  • @HighCore Agreed. "Stick to forms" is not a good advice in general. One that I gave about four years ago, when the technology was somewhat different as was computer hardware. Still, I'd be in doubt when suggesting the OP to go with WPF to write a simple 2D game - even more when he affirmed that he was skilled in Forms already. The best option is "neither", but since that's not what he wanted, "Forms" seemed the best choice at the time. – Bruno Brant Jul 07 '14 at 18:51
  • @HighCore I beg to differ - the OP accepted my answer, so I probably did answered his question somehow. About that, you can check Rei answer below - oh, and, he may have disagreed with my answer, but he also says that "OnRender" is slower than "OnPaint" (link). – Bruno Brant Jul 07 '14 at 18:54
  • 1
    @BrunoBrant depending on what you're trying to achieve, it is just plain *wrong* to do `OnRender()` type of stuff in WPF. WPF is about XAML and DataBinding, not procedural code. I have made a couple of **simple** 2D games in WPF and not once have I needed to resort to `OnRender()` or the like. – Federico Berasategui Jul 07 '14 at 18:57
  • @HighCore I don't know how to do that! :) Can you send us a link for sake of history (or maybe even provide your own answer) that would show us how to do so? Future readers certainly would approve. – Bruno Brant Jul 07 '14 at 19:00
  • 1
    @BrunoBrant see [here](http://stackoverflow.com/a/15469477/643085) and [here](http://stackoverflow.com/a/15580293/643085) for samples on how to draw basic stuff in WPF using proper WPF techniques such as DataBinding and DataTemplates. – Federico Berasategui Jul 07 '14 at 19:22
  • _"WPF is slower than Forms"_ - utter nonsense. I can bitblit large offscreen render targets to the screen 30 fps using WPF's DirectX hardware accelerated backend, all colour enhanced; drop shadowed with a "pinch" GPU effect. Try doing that in WinForms. –  Feb 07 '16 at 13:54
  • 1
    Still getting flamed for an answer I gave almost six years ago. @MickyD yes, you are right, the answer sucks. SO doesn't allow me to delete it though. – Bruno Brant Feb 10 '16 at 03:25
0

There are a few Containers to display stuff. That one which you would like to use is a Canvas(the only one with coordinates system) some more details

The key is what kind of game you are up to. Using xaml it could be a some basic app-like game (basic drawings and so on). For something more consider using XNA. The advantage of xaml is that it's easy to interact with user via handlers, f.e it's simple to write a string onto screen which is a bit harder for XNA. Also using xmal u could make a game for IE (XABP), Windows Phone and Silverlight.

What you were doing with form is a bit of loop-style game.

Update(); Paint();

and this fits XNA more. But if you want to use WPF and Xaml use Canvans and LayoutUpdate Handler.

Lukasz Madon
  • 14,664
  • 14
  • 64
  • 108
0

You can try adding a windows forms custom control inside the WPF using a WinForms host and drawing there using OnPaint

//WPF XAML
<WindowsFormsHost x:Name="formsHost" HorizontalAlignment="Left" Visibility="Visible" Grid.Column="0" Grid.Row="0"></WindowsFormsHost>


//WPF CodeBehind
YourCustomWinFormsControls panel = new YourCustomWinFormsControls ();
        panel.Width = XXX;
        panel.Height = XXX;
        formsHost.Child = panel;

//WinForms Custome Control Code

protected override void OnPaint(PaintEventArgs pe)
    {
        //DO STUFF HERE
        base.OnPaint(pe);
    }
JAnton
  • 1,095
  • 8
  • 16