I've been constructing a card game and want to use a good UI framework for my client.
I was leaning towards WPF, since I have VS2010 and good experience with C#, but I'm having doubts about it, since it isn't quite tailored towards games.
I'd like to have something that allows me to do nice (but simple) animations for typical card actions, like drawing/discarding/playing etc. I know WPF has better support for animations that WinForms, but will it be enough for a game like this?
I used to develop games in WPF, and its animation system was a huge timesaver. To get the most out of WPF. I highly recommend using Microsoft Expresion Blend for UI design and animation, going back and forth between Blend, and Visual Studio, I was able to build animated interfaces in hours that would have taken days using a more conventional UI framework. I believe that new versions of blend even let you edit C#, that would be an even bigger time saver.
Have you looked at XNA?
It probably wont be easy to creat the animatons, but the framework itself is geared towards gaming. It's Microsoft tech and all the examples I'v seen are implemented in C#
You could even look at Managed Direct X which itself was the precursor to XNA and is also Microsoft tech.
WPF is certainly capable for something like this. In fact, Adam Nathan has an example in his earlier WPF book, "Windows Presentation Foundation Unleashed."
There is a .NET 4.0 version, but I haven't actually seen it. However, the earlier version of the book was quite well done IMHO.
Related
I'm developing in MonoTouch and I have an issue where a 3D model should be drawn on-screen, making it possible to rotate around and zoom in/out.
Usually, developing things for iOS (apart for the usual weird API kinks) is a breeze. I need an image, I load it and display it with a few lines of code. Same goes for audio, touch events etc. However, when I try to look at 3D stuff, what I get is OpenGL-ES 2.0 which seems unnecessary low-level and far from "plug n play". Weird enough, but what seemed even weirder was that I couldn't find any simple framework to go around it. Am I missing something here? I found Unity3D but that's way more than I need (not to mention the price, and again, learning curve).
Do I really have to invest time in learning the intricacies of 3D rendering when I just want to display a model? Seems OpenGL-ES-1.1 is a bit simpler but may not have the functionality I need (and again, the lack of "1-2-3 this is how it works"-tutorials seems weird to me). Or are my google skills way poorer than I thought?
Sorry if the question implies a vague answer, but summarized I guess my question is "What's the simplest way of displaying/rotating/zooming a 3D model in MonoTouch using OpenGL-ES 1.1/2.0 (preferrably 2.0, but 1.1 is also ok)?"
I got this geat tutorial for OpenGL ES 2.0.
Its not unnecessary low-level IMHO. It enables a broad possible uses, e.g. creating a game and a simple 3D visualization are two different applications which may not need everything the other app has.
Of course it would be great if it would be more like DirectX but you can create the necessary classes by your own in no time.
If you want a non-low-level api, consider using something like Unity3D.
"1-2-3 this is how it works" - http://nehe.gamedev.net/
for mono - http://www.mono-project.com/GtkGLAreaSharp:NeHe (i know not mono touch, but it should help)
OpenGL ES 1.1 should be more than enough.
What kind of effects do you want to add to the models? 1.1 should be fine for texturing and lighting.
I've just recently learned C# and am interested in .net but I don't know where to begin.
I know .net is just a bunch of libraries and can be used for web programming?
I'm not quite sure what areas in .net that I need to learn?
I don't know what I am trying to accomplish with .net? But I want to learn .net.
What other things can be achieved with .net?
Thanks.
Added -
The 2D class that I finished was a C#/Winform/XNA class working with 2d objects. Though there was never once a reference about .net in class. I just learned C# which is comparable to C++ and Java and Winform = just using the tool box and hooking up controls to back end code. XNA portion was being able to use the hardware to draw primitives and manipulate data going through the model->view->project pipeline.
What part of this class was .net? None right?
You can do nearly anything with .net (the same is true for most other platforms).
You can use ASP.NET for web programming, Windows Forms or Windows Presentation Foundation for GUI development.
There are also lots of functionality for networking, database development and XML or Image processing.
But the question is, what do you want to achieve?
I know .net is just a bunch of libraries and can be used for web programming?
.NET is much more than this. It is not restricted to web programming. There are possibilities for doing Windows Applications (WPF), Web Applications (ASP.NET), Network Communication (WCF), Database Access (ADO.NET), ..., you name it. So just pick a language you would like to learn like C# and go ahead and visit MSDN.
.Net is a managed runtime with libraries. It is not exclusive to building "web" applciation or pages.
The .Net Framework is 'the libraries'.
The CLR is the runtime (where the specification thereof, is deposited into a standarization organization)
C#/VB.Net/F# are flavors of different syntaxus (how do you spell this in plural?) used to instruct the runtime, using the libraries, to perform actions in an order you define (AKA programming)
Wanting to learn .Net is akin to learning another language/gammar. If you have no previous knowledge of "language/gammar" itself, you are using this specific language/runtime to learn 'language' in general.
Hope this helps,
Sorry, but if you've just used the toolbox to hook some stuff together you haven't learned C# or programming. You've learned how to hook some stuff together, but you're obviously interested in learning how it works. Seems like you're going to have to learn a lot of stuff from scratch. There's a lot to learn...
I think your best bet to learn .Net and C# (you can't really learn one without the other) apart from following a course specific for that goal is to find yourself a good book that explains the whole picture and run through the examples in the book.
Looking on internet, asking questions, and collecting bits of examples, etc. will give you little pieces of understanding, but I doubt you'll be able to get a comprehensive understanding of programming, .Net and C# that way, simply because you won't find a big picture explanation. I find a good book gives me a deeper understanding even though I've already worked with .Net/C# since it first came out, simply because there is much more explanation of how things work and why.
Personally I really like the Pro series from Apress: have a look at Pro C# 2010 and the .Net 4 Platform
It might be perfect or not depending on your understanding of software development. Otherwise just search for C# and see if other interesting books pop up.
All,
As far as I understand ASP.NET MVC is the framework that implements the MVC pattern released my Microsoft. I wonder why there is no Winforms or WPF MVC implementation ?
The reason I am asking is that I am planning to start on a new big WinForms project and ideally we are looking for a framework that implements some kind of common pattern to improve the testability of our solution.
Thanks,
MK
For WPF, the MVVM pattern is so deeply ingrained in the framework itself that you don't really see it until someone points it out to you. You don't really need a separate framework for that (although certain types, such as Josh Smith's RelayCommand, would be nice to have in the BCL).
Windows Forms isn't really going anywhere anymore, which is why you don't see any new or thriving MVC-style frameworks for that platform. However, patterns & practices' Composite Application Block (CAB) was an attempt at such a framework.
Most people found the CAB to be too complicated to their taste, but I personally found it a valuable effort, even if it could have been simpler to use. It's still out there and available in source code format, so you might want to take a look at it.
However, if at all possible, implement your application as a WPF application instead.
If you want to use WPF you should look into using the MVVM pattern (Model View View-Model).
There's a template you can download for Visual Studio for it. It's part of the WPF Toolkit I think. Look on CodePlex.com.
Hope this helps!
There are a few similar SO Questions here and here.
Just because there is not a strict framework for MVC in webforms/wpf doesn't mean you can't follow the principles and code in an MVC way. I think MVVM for WPF is similar although I have no experience of this.
As Tony said, read up on the Model-View-ViewModel pattern (essentially, this a variation of MVC, but better suited for the WPF programming model
Have a look at the Composite Application Library for WPF and Silverlight (from Microsoft P&P). I can say from experience that this library is a lot easier to use than the Composite Application Block...
The Caliburn Framework is also worth looking at
WinForms are dead. You better look at WPF+MVVM (+Prism)
What an excellent question asked here: Why isn't there an MVC equivalent framework for WPF? I spent 6 years on WPF platform only to find out:
No further development on the WPF toolkit ever occurred since fist release.
Hosting web browsers in WPF still has major air-space issues.
Charting was never fully ported to WPF.
VS2013 never was provided with an WPF MVVM template for new projects.
Prism is confusing.
Learning curve is steep.
The open community hardly developed any open libs. like Javascript folks did.
Running it as an in-browser app. was very difficult to get right.
Compared to Web-Client rendering it is just plain slow.
And perhaps worst of all Microsoft went quiet on us. Until just recently announcing they're back in the game, but if you look at their plans it looks more like a Sunset release than getting back in the game.
The solution for me is to dump WPF in favor of MVC which I've done. MVC has its quirks but it's a much nicer platform than the cantankerous framework that's best suited using the "Relay Command" what a pile of nonsense.
Imagine your boss saying, hey we need that in a web browser and your reply "It'll be ready tomorrow"...
I'm about to start developing a small Windows application using Microsoft Visual C# 2008 (Express edition). I'm very new to C# and .NET, so this is a newbie question. Should I start with WPF or should I stick with the old WinForms?
My application has several screens, all having several text-boxes, check-boxes, combo-boxes, not anything more. The application will retrieve data from several COM objects, and communicate through standard TCP/IP sockets, both of which are unrelated to the UI.
The UI is not fancy in any way (and I don't need it to be). However, the world seems to be moving to WPF. What are the considerations of choosing WPF over WinForms for my case? What's the recommended approach?
Thanks
I have not used Forms enough to say anything about which is better, but I have found WPF to be easy enough to use for minor applications.
I figure that if it's the standard people are moving towards and it's not difficult, then it's good practice to start using it.
WPF = Future + Fancy stuff
WinForms = WYSIWYG greatness
Choose whichever of the above you find the most atractive :)
It depends. Stick with WinForms if you're comfortable with it.
If you want to be able to have a better look-and-feel with more customized controls, and you're willing to spend the time to learn XAML and the differences between WPF and WinForms, then go for it. But expect it to take some time, there is a learning curve.
Interesting, how all answers target the developer: familiarity with a framework, the learning curve, the technical features of a framework etc.
If it's a simple application, none of the technical aspects really matter. You sound like you have some experience programming, in that case the chosen framework doesnt really matter. Focus on your users instead.
Can you guarantee that your users have the latest .net runtime installed? Are they willing/able to install it if they dont?
Will your users be put off by an "outdated" look and feel?
The way you phrased your question, i think you should use WinForms. You seem to imply ("stick with winforms") that you have experience in WinForms and that you dont have any fancy demands for the UI, so i see no reason to put yourself on a steep learning curve that WPF can be.
I personally like alot of the things that WPF provides. It has easy data binding, validation, and customizing UI things is simple. Plus with the new Expression Blend 3.0 that was released yesterday they have sketchflow WPF apps that you can share with others and get feedback files from. It is a pretty interesting little addition to the WPF world.
The nice thing is that if you find a Winform control or something that needs to be WPF and you picked the other way, they seem to work well with each other now.
It's a trade-off.
You will most likely be more productive starting off in Windows Forms because the programming paradigm is closer to most other UI development libraries you might be familiar with. There are also many libraries of UI control available for WinForms (including ActiveX) that make creation of attractive, functional UI easier. Unfortunately, MS has indicated that WinForms will not see any more advancement in the future because their emphasis is on WPF.
WPF, on the other hand, is more more sophisticated and robust and can help you create very attractive, rich interfaces. WPF sometimes requires the use of more sophisticated back-end programming paradigms like MVVM to create effective applications. Also, as a newer technology, there are fewer mature libraries and tools to help you develop WPF apps. For development tools you have VS2008 and Expression Blend (which is quite nice BTW). Advanced graphics features like gradients, color themes, skinning, control customization are all more powerful in WPF. But this power comes at a price - most developers find WPF to have a more significant learning curve that WinForms.
WPF is something completely new if you are used to WinForms, so it'll take quite a while to get used to it. But i prefer WPF not because of the looks, for me it's more the great layout system (once you got used to it), its databinding infrastructure and in combination with patterns like MVVM, the separation of UI and business logic.
I am a long time MFC programmer and know it quite well. Recently we are planning for a large desktop application. In order to beat competition, one requirement is polished UI. We narrow down the choices to three:
WinForms
MFC
QT4
We looked at some big WinForms applications, such as Paint.Net, and feel that it still lacks power of performance. The startup takes a while and some UI parts do not look very nice.
We had great hopes in QT4, but after writing several programs on it, we find that the looks of a QT4 application is not at par with native Windows UI. It still looks differently. Also we worry about about lack of widgets (for example, the color picker and calendar control in the library quite suck).
MFC is a safe bet, especially with components from Codejock.com. The UI interface looks quite polished with codeJock toolkit. And all widgets needed are there. The problem is that its coding style is quite outdated.
What will you choose for your next desktop application?
WinForms is effectively at the end of its life now. You should look at WPF.
See WPF: Any cool UI ideas i can look at? for links to some nice examples.
WinForms is really easy to get into if you know MFC (it's still based on the core Win32 concepts, so you don't need to learn much to get up to speed). Compared to MFC, you can develop much faster, and there is so much more library support for everything in .net that you have to write for yourself or find 3rd party libraries for in MFC. Often I find the .net solution to a big problem is around 3-10 lines of code, whereas the equivalent MFC solution would be hundreds or thousands of lines. I wouldn't even consider MFC a starter now that I've used WinForms in C#.
We're building some very large C# applications and the performance is perfectly fine. If any small part of the program is really performance-critical, it's really easy to plug in a bit of unmanaged C++. I found startup times abysmal in XP in the early days, but with more recent .nets and Vista, startup time is comparable to MFC apps.
So I'd go for WinForms/.net at a minimum.
WPF is also a sensible future-facing approach to consider.
WPF is a good option if you've got design skills or can ask for someone to prettify your UI. I think it's definitely one of the most versatile options.
You could also use components like DevExpress or Telerik, both have an extensive library of WinForms controls and as of recently WPF controls. I've used DevExpress myself and am rather pleased with the looks. Although these library don't come cheap, but they do carry quite a lot of functionality.
I've never worked with QT4 so can't judge that.
For my next desktop app I would use:
on Windows:
Probably the old fashioned Windows API (without MFC) because I am familiar with it.
Maybe Qt, because I'd like to try it out.
on MacOSX: Cocoa
on Linux: Qt
Not that I am very fond of MFC, but if you are comfortable with it, go ahead. It is not going away any time soon, although it surely won't be updated and improved as much as WPF.
Having spent 12+ years developing MFC applications, and now using WPF for less than a year, there is no way I would go back to MFC. At previous employers, we would spend countless hours customizing UI behavior and getting the right graphical look that would take a fraction of the time in WPF. Not to mention the added flexibility of being able to work with the UI as XAML (XML,) as opposed to the rather outdated resource editor.
If your application has to be C++ (as opposed to C#,) then I assume that using WPF would be a little more non-trivial. I haven't done .NET inside of C++, but I remember the overviews presenting it as a fair amount of extra work.
We at my work are currently revamping a GUI app from VB6 to make it look "prettier". We've chosen the .NET winforms platform for our upgrade since most of our coders are familiar with it. .NET has a few libraries dedicated to graphics, and there is a wide range of nice-looking user controls already built into the library. Asside from those, there are many, MANY custom-made controls out there such as the ComponentONE library, and there are a lot of opensource controls for enterprise use that look nice as well (you can search CodeProject.com's articles section for some free, downloadable controls that look very vista/windows 7-esk).
The framework also natively doublebuffers windows, and has bufferedGraphics classes that you can use to manually handle doublebuffering if you so choose.
However, windows forms do still ghost when dealing with high res images as background pictures and the only way to really fix it seems to be to use the DirectX libraries to draw using the graphics hardware on the machine (which is difficult, but atleast its free).
Hopefully that helps your decision on the platform form the windows-forms side.
I would still consider MFC. It's far from dead and especially with the new 2008 feature pack. You get a host of updates and can now create those fancy ribbon UI elements. If you already know MFC then you know the pitfalls (old but some are still there) and can knock out the work quite quickly.
There a ton of UI components you can buy for MFC and it has the benefit of being fairly close to the metal as far as speed goes. There is no need for your end users to install a framework or anything else.
I write C# for my day job, but all my personal projects are MFC/C++ since they don't require my users to have additional frameworks,libraries,etc installed.