My goal is to gain a better understanding of the characteristics of C#, and become more comfortable creating simple apps. I am fairly competent with Flash (Actionscript 3), and found an old Tic-Tac-Toe game I'd written. I started wondering about porting this code into a C# application. Not knowing much about C#, I'm wondering how difficult the migration would be.
On the one hand, the underlying game logic is syntactically similar, and therefore would be easy to port.
However, as far as the graphics are concerned, I don't even know where to begin. So far, I've only exposed myself to Windows Forms and Console apps in C#.
I'm wondering if these Flash concepts have similar analogs in C#, or if the procedures and syntax are radically different:
Placing graphic elements on a stage
Rendering lines from start/end coordinates
Event listeners on movie clips
Swapping the image inside a graphic element (or, in my Flash version, nextFrame() in a movie clip)
You may want to try developping your little game using Silverlight. Silverlight applications, coded using C# and Xaml, are pretty similar in form with flash applications, and you should find everything you need without trouble.
So I suggest you download the Silverlight SDK (free) and give it a try.
Firstly, Flash is to WPF (close enough) as ActionScript is to C#.
The WPF/Silverlight model is much more similar to Flex that it is to Flash. Everything is added to the UI tree as a object, even lines.
Likewise, adding event handlers to controls (like a button click) can be done in the "code behind" (the code that lives with the view), but the recommendation is to use the MVVM pattern. If you are new to the concepts of separation of concerns and unit testing, feel free to start with the simpler "code behind" method.
While WPF and Silverlight are very similar, I'd recommend starting with Silverlight as the SDK and available samples are richer. You can easily move onto WPF later on (though porting an application from Silverlight to WPF is not automatic).
Swapping images, as you mentioned, would be done via "Visual States" in Silverlight (or possibly changing the image reference, which is more "hacky").
Have a look at the following links to get started:
Learn # Silverlight.net
Silverlight on MSDN
Shapes and Drawing (Silverlight)
If you're looking specifically to do games and the like, you may wish to look into the free XNA framework. However, there will be differences as Flash gives you far more ability to "set up" things beforehand and modify them.
Placing graphic elements on a stage
If you go the XNA route, you will be drawing sprites using the spritebatch, you tell them where and how to draw and that's where they will go
Rendering lines from start/end coordinates
In windows forms you can do this via a simple System.Drawing call, however if you wish to do this in XNA, you will either have to make a 1 pixel square and stretch/rotate it to what you want, or use 3d primitives (Though this will limit you to a 1 pixel line)
Event listeners on movie clips
Look into delegates, but there isn't really an equivalent for movie clips to my knowledge
Swapping the image inside a graphic element (or, in my Flash version, nextFrame() in a movie clip)
This is fairly simple, depending on what you mean. If you want to, say, animate a sprite. You can do this by moving the source rectangle or changing the texture of the spritesheet. If you mean the screen as a whole, this is mostly handled for you provided you use the spritebatch. In windows forms you'll have to do more of it yourself, but the base concepts are the same.
Overall it's not that bad, but if that doesn't sound appealing check out Silverlight. It's basically C# styled flash so you may find the transition easier.
Good luck and hope this helps.
Related
since this is my very first time trying to make yet simple but useable sidescroller I'd like to ask some questions and hopefully gather ideas to make a good engine that can change the position of an Image in the form depending on X position of the drawn game character. I'd basically like to recreate just few seconds of a Mario game.
The starting Idea (correct me if it's wrong / poorly performance / whatever) would be to create a picture long in width and whit fixed height and upon the press of, for example, A or D keys, the drawn character moves till a certain X point, after that, character gets locked in place and if the key is still pressed, the background image starts moving.
But the problem there would be the fix for collisions, would be possible to check for the X position of the drawn background picture and set "collisions" accordingly for the character?
Other questions : why picturebox should be avoided at all costs and use the form itself instead ? Placing the greater part of the classes methods inside a timer_tick event is the wrong approach ? I read somewhere that the best way to do games of this kind would be relying on infinite loops in the forms main method, but I simply cannot even think how this could possibly works, taking in count all the times we may need to get out of the loop and do different code in different places.
Any other different ideas/approach and direct links to further explanations would be greatly liked
Edit : yes i'd like to improve with windows forms before moving to xna/unity
Assumption: You want to make a little game and its your first time working with moving graphics and you're working with WindowsForms. Suggestion: try using a more advanced framework such as MonoGame or XNA and working your way through introductory documentation and tutorials. Also WPF has a more advanced graphics platform for doing things like drawing and 3D, you may want to give that a shot.
To expand on my comment a bit.
Windows Forms and GDI (the tech behind drawing) aren't meant for this kind of use. When GDI was created its purpose was essentially drawing lines and fonts on the screen. XNA is a really good framework for learning the basics up to professional design. Unfortunately the XNA framework is no longer supported by Microsoft and as such MonoGame is the recommended development route for managed .NET 3D and 2D game development.
The WPF provides basic access to Direct3D and Direct2D, and has 2D and 3D shapes and animations built into the framework and is what WPF is based on.
But you also have the choice, if need be, to create an XNA component and embed it in a Windows Form as demonstrated in these two tutorials.
XNA in Windows Forms I
XNA in Windows Forms II
Also using a Windows Forms Timer isn't recommended because they are unreliable. The .Net Framework provides a 'Server Timer' and a 'Threading timer' that can be used as well.
If you are really keen on using GDI for a game may I recommend reading about the basics of game programming (I think there are a few XNA docs on the subject) that should guide you on things like the basic run time loop, getting input, and simple physics.
If I'm looking to create a game that doesn't necessarily run full screen, but simply needs to feature 2D/3D graphics somewhere in a portion of the screen, what's my best approach?
Some specific questions could be:
What component would the rendered area use?
Are there any game libraries I could leverage for the rendered area?
What would be the most "pure" or "canonical" stack according to Microsoft to use here?
Omega --
Visual Studio 2010 and 2012 are Both WPF apps. WinRT is for Tablets / Mobile. WPF is certainly NOT outdated.
If I were you I wouldn't render everything out the way canvas forces you to, it might be a better approach to have the center item be a UI element named Frame, which is the base element for all UI related content in WPF.
In this way you would be able to leverage all of the possible types of controls in the Frame whether you decided that An ImageSourceType or Canvas is more applicable to a particular features of the game.
Depending on how you want to draw graphics, you could use (but are by no means limited to):
Canvas - which would be totally appropriate for slow moving games. This way you get the benefit of the various WPF layout routines and can define objects inside the scene in XAML/vectors as well.
WPF supports 3D graphics (using Direct3D on the backend) so you could probably set up an orthogonal projection matrix and treat it like a Direct3D context (with the WPF API). I don't have enough experience to know how slow this is compared to D3D, but it's certainly easier (built-in "scene graph" like support from the XAML architecture, for instance).
If you want to go whole-hog with Direct3D you could use SlimDX, which has a WPF shim that I've used in the past, as well as another third party control. There may be other libraries available as well.
Direct blitting to/from a Bitmap using WriteableBitmap (see WriteableBitmapEx for a third-party version with a much friendlier API) or similar.
There are probably a lot of other options too. My preference would be for using Canvas initially if it's a slow-paced game that doesn't need super-fast frame rates (the layout work does incur a fairly substantial overhead, but it's less work and may be easier to get looking exactly the way you want).
If you want absolute control and speed, use D3D through SlimDX, but this is a pretty hefty learning curve if you're new to it.
I'm currently working at a application that helps people understand how to do there job. You can see it as a personal coach that guides them trough all the steps they need to do that no normal person could keep remembering.
In my previous application we had the ability to show the user up to 4 pictures (what proves to be more then enough). The application would load the data and see how many pictures where in every instruction and then sort out the picture in the best fitting way without messing up the scale and resolution of the pictures. This all was done with GDI+ and worked very well.
Ofc, change is something that always happens, my bosses came up with some great ideas. So they want to be able to see movies on the screen, animated gif's, 3D models that can rotate or animate. So I think we had pushed GDI+ to it's limits and it's time to look for something different.
I have heard and readed about WPF but have no experience with it. Is it even possible to do all what I ask in WPF? And what about the old picture-merging thing I wrote, can we also get it done in wpf? I tried to make some things working but I didn't went as smooth as I hoped.
I'm also concerned about the fact that the interface needs to be dynamic, the one moment it should be showing picture with some text above it, the other moment it should be showing another text with a video under it.
I would love to hear some opinions here and if you got some other suggestions I should look into pls tell me. Thnx in advance
PS: If WPF is the choice, should I convince my boss to change to .net 4.0?
Although my answer can be termed subjective, I find WPF better than GDI+ anyday. You can do everything you can in WPF which you have done/could do in GDI+ (apart from pure games/game engines). If you can afford the steep learning curve of WPF, I think it will be better investment as this technology is not going anywhere soon.
As for .Net 4.0, WPF 4.0 does introduces some important functions in 4.0 (specially easing functions for animations) but there is nothing you cannot do without if you are using 3.5. I won't recommend 3.0 though mainly because of performance in animations.
WPF is up to the task, but you could also check other options.
You could go web based, and have either an XBAP (WPF in the browser), or Silverlight/Flash app.
Silverlight/Flash doesn't require that much from the client (to install), and is easily updatable, and both can do the job.
I know WPF is more complex an flexible so could be thought to do more calculations. But since the rendering is done on the GPU, wouldn't it be faster than Winforms for the same application (functionally and visually)?
I mean when you are not running any games or heavy 3d rendering, the GPU isn't doing heavy work, right? Whereas the CPU is always busy.
Is this a valid assumption or is the GPU utilization of WPF a very minor operation in its pipeline?
EDIT: The application that I am interested is a 3d modeling and animation software, where you have 3d viewports to navigate and edit the scene, and objects inside the scene. But I want to use WPF because of its modern architecture, and it's from scratch.
EDIT2: Also for my purposes I will use DirectX hands down for the app itself because of the high end requirements of the software. As for people using lower end or computers without a dedicated GPU, that's OK since they aren't not in my primary customer area. Just like other high end 3d software for film and games, it will be understandable to require a powerful computer to fully benefit from the application.
Provided the machine has a GPU, you'll get better rendering performance in WPF.
We have a large desktop application that we wrote in WinForms, and are now porting to WPF. We've witnessed much better rendering performance, particularly when resizing windows or redrawing controls.
We've also found that WPF "controls" are more lightweight than WinForm controls. If I recall right, WPF controls do not necessarily require an operating system handle, and don't register for Windows window messages via WndProc, at least not independently.
For your case, since you're building a 3d modeling app, which kind of assumes some 3d hardware on the machine, you should absolutely use WPF over WinForms.
For the app scenario you describe, I would expect WPF to outperform WinForms for 3D work on a full featured GPU by a wide margin.
The difference between the application types is more than just the rendering the 3D vector pipeline. WPF's internal architecture is radically different than WinForms, specifically designed to overcome the caveats learned from years of prior experience with the Windows GDI and WinForms apps.
(WinForms is a relatively thin wrapper around Windows GDI and User model that was originally created in the late 1980's. The Windows User control model has evolved over the past 25 years, but the core architectural patterns are largely unchanged.)
For example, WPF always separates UI rendering from application logic. When the WPF window goes to draw something, the actual rendering happens on a background thread. The refreshed visuals are flipped to the display during the video retrace interval, so you don't get partial blits or "tearing" artifacts on screen.
WinForms does none of this. If you render to DirectX or OpenGL surfaces in a WinForms app, you have to do the work of flipping the video page and making sure it happens at the right time to avoid screen tearing artifacts.
Wpf's default controls are GPU aware and can be custom styled with glows and transparency and whatnot all GPU accelerated. WinForms controls do not benefit significantly from GPU features, since about the only things WinForms (Windows User controls) uses for rendering are 2D bitblit and rectangle fill. Glows, transparency, animations are all possible with WinForms, but you have to do all the work to implement them.
In WPF, UI slickness is mostly a matter of designing and styling to get WPF to do it for you. In WinForms, you have to push the pixels yourself.
This is a really tough question to answer.
A huge portion of WPF performance is your GPU. A good GPU works wonders for making WPF perform well. WPF can be very performant. If your requirements are to have a decent GPU, since it's a 3D modeling program, you'll probably find WPF performance to be as good or better than Windows Forms - though this really depends on what you're using.
That being said, it's usually difficult to compare - mostly because WPF allows you to add a lot of visual effects that people tend to never even attempt in Windows Forms. Many WPF applications "seem" faster even though they're actually slower in some instances because of extra visual clues.
That being said, if you have a LOT of controls, WPF can actually outperform Windows Forms by a fair amount. In Windows Forms, each control requires a separate window handle, and receives its own message sets. With a lot of controls, this can actually slow things down pretty dramatically.
The real question here should be is WPF perf. "good enough" for your application. If you're doing a 3D modeling application, chances are WPF will not be your bottleneck- it should be fine.
For 3D modeling, WPF is clearly a lot better choice than WinForms -- but it's still a long ways from ideal. Winforms has no (direct) support for 3D rendering at all, and WPF has some. For a program that's aimed primarily toward 3D rendering, however, you might be better off with something dedicated more specifically to 3D rendering tasks, such as OpenGL or Direct3D.
On their own, neither of those provides a huge advantage over WPF, but unless what you're doing is fairly specialized, I wouldn't use those directly though. I'd use something like OpenSceneGraph or Ogre3D, that can use either of those for its rendering, but provides a much higher-level interface and does more to manage rendering your scene.
Either or both of these probably could use WPF for the actual drawing -- but I'm pretty sure neither one does, at least currently. I don't know whether they ever will either -- they might, but I doubt it's a real priority, since they already support OpenGL and Direct3D. For their purposes WPF provides little advantage.
Seeing as WPF actually uses DirectX under the hood and the fact that you use XAML to specify DirectX objects, WPF is by far the easiest solution.
Example coding a camera in xaml:
<PerspectiveCamera x:Key="Camera"
Position="0, 0, 4"
LookDirection="0, 0, -4"
UpDirection="0, 1, 0"
FieldOfView="30"/>
I am transitioning from WinForms/XNA to WPF/SlimDX because:
a) all of the benefits of WPF over
WinForms (but learning curve = ouch!)
b) I would like to have multiple
SlimDX viewports attached to Panels.
XNA has 1 "game" screen.
c, last and least) DirectX 10 support
All of my previous XNA code is in C#. I am having trouble figuring out how to port this over to SlimDX and WPF on a high level. I have searched like crazy. The closest I have found are:
1) http://www.gamedev.net/community/forums/topic.asp?topic_id=507941
Many articles point to this discussion, however it is incomplete and I can't figure out the XAML, and I get device errors after attaching all of the _slimDXDevice and Window1 events that were left out.
2) http://www.codeproject.com/KB/WPF/D3DImage.aspx
This article assumes the user is porting C++. I am porting XNA code which is very close to MDX code.
If I could get to the point where I have a WPF form with a custom SlimDX driven viewport that was just a blue box, I could go from there. In XNA I rendered many separate RenderTargets and placed them all over the screen, now I want to attach them to controls. But first, just 1 blue box! :D
Any ideas? I feel that this is either simple or that there's some "cookie cutter" code that I'm missing. Greatly appreciated!
You can look at the sample now. It's just been checked in to our repository, so you'll need to use SVN to get it (or wait until we ship the Feb 2010 release):
http://code.google.com/p/slimdx/source/detail?r=1356
D3DImage is the class you want to use. Even though the codeproject tutorial is C++, it is very applicable to SlimDX and WPF.
All you have to do with your SlimDX, is run your code normally, but DO NOT run a Present(...) on your device or swap chain. At the point where you would put a Present(...), do a D3DImage.SetBackBuffer(...) and send your SlimDX surface's ComPointer property to it. Then do D3DImage.AddDirect(...) and you now have D3D composited in WPF.
Also, make sure you create a IDirect3DDevice9Ex or else your performance will be terrible in anything but XP!
I recently was messing around with D3DImage and SlimDX and didn't find it too difficult to get it working (with DirextX9). I have some code at my home pc that I'll post later, but it's pretty similar to the code in the links provided.
I was never able to get it working with a higher version of directx though. Jeremiah has a nice blog post about using a directx9 device as a link between directx 10/11/d2d and the D3DImage, but I couldn't get it working with Slimdx. I didn't put a whole lot of effort into though as directx9 did what I needed it to do and I kind of wanted it to work on XP.