I have an assignment which, if I could implement it any way I wanted, would be relatively easy. Alas, there are a number of restrictions on the implementation. I need to create a Visual Studio project which uses C#.Net Windows Presentation Form (WPF) for the GUI and Visualization Toolkit (VTK) with C++ for 3D rendering. If you look that up on-line, you'll soon find something specifically designed for this--ActiViz.Net. Unfortunately, using ActiViz.Net is specifically forbidden.
I've been able to build VTK and the example projects in Visual Studio. I'm still not entirely comfortable with it, but I at least know how to do some basic rendering. WPF doesn't seem too bad on its own. But how do I combine these into a single project, with the GUI influencing the rendering? So for example, I'd use WPF to make a button that said "enlarge sphere". I'd use VTK to render a sphere, either in the same window that had the button, or in a separate window. When the user clicks the button, it will run an event method in C#. And that method will somehow tell the C++ code using VTK to make the sphere larger.
At the moment, I'm not even sure how to make a single project with both of these parts, let alone how to communicate between them. Really, the best I can think of right now is two separate programs, with the GUI program launching the 3D program, and influencing the rendering by writing out a file that the rendering program reads. Not very elegant, I know. Any better ideas?
Related
I have written a DX11 renderer using c++. I am now looking for a way to implement an Editor/GUI for it.
Since im pretty used to Windows Forms and WPF C# Applications im thinking about putting my renderer inside a dll, load the dll from a c# application and use it to draw into a defined section of the form. Does this even work with a window handle passed by a managed c# appication and how is the performance if it does?
From my understanding, since the actual communication with the DX11 API would still be directly in c++ and the c# part would only tell the dll what to do the performance loss should be almost nothing. Or is this generally a bad idea and implementing the GUI directly in c++ using a library or D2D is the better approach.
In WPF you can use D3DImage which is just like a simple Image in your xaml. The general principle is as follows:
Allocate a Direct3D 9 texture, this will be your rendering target.
Hand it over to the D3DImage.SetBackBuffer.
Put your rendering code inside CompositionTarget.Rendering event handler.
RenderStuffToTexture();
d3dImage.Lock();
d3dImage.AddDirtyRect(new Int32Rect()
{
X = 0,
Y = 0,
Height = d3dImage.PixelHeight,
Width = d3dImage.PixelWidth
});
d3dImage.Unlock();
Since you are using Direct3D 11, you have to use DXGI surface sharing to share the D3D9 textute with D3D11. There are 2 examples I know of that illustrate how to do just that. Microsoft D3D11Image and D3DImageEx (my personal preference, can be found in multiple places online).
Regarding performance, once you use WPF you no longer doing the presentation yourself. You literally write a small render-to-texture logic inside a WPF D3D9-based renderer. So not everything can be controlled including presentation time. From my personal experience, you can definitly render simple scenes at a nice framerate. For a really graphics intensive app and strict FPS requirements I would use a more lightweight (and less intrusive) UI solution.
Note that you can also use WinformHost control to get a HWND and render to it. This has a serious disadvantage if you want to overlay UI controls over the rendered frame - AFAIK you simply can't.
I'm working on a small personal project where I'd like to port some amateur game project of mine from Java to C#.
I've run into a problem with C# when it comes to pragmatically creating a window.
Research and some experimentation led me to find the System.Windows.Forms.Form class, but that's meant for a typical UI (buttons, controls etc.) and not rendering. (I was going to just add a bitmap element to the container within the form but I think it'll be far too slow as it wasn't designed for this.)
The next thing I found was the System.Windows.Window class, which is simpler than the Form class above, I could append a XAML canvas to it and draw to that. The problem I'm running into is requiring a thread of type STA to run the window which makes things more complicated.
I there any straightforward window creation in C# for 2d graphical applications?
I'm purposely avoiding XNA and OpenGL/DirectX as I want to learn as much as possible and try and do most of the heavy lifting myself.
I'm about to start porting my WP8.1 app to W10, and looks like I'll have to make it a Universal Windows App. Now, I'm fine as for the back-end code, as I'll be able to reuse 90% of my classes (Models, ViewModels, and most of my helper classes, extension methods and converters).
The problem is for the UI: I understand I'll have to design the app for different screens and aspect rations, and I don't know how to actually implement that in code.
I mean, as for the UI scaling, I know I can use the VisualStateManager and AdaptiveTriggers to manually set the properties of the UI elements I want to adapt on any screen resolution, or I can use some converters, and that's fine.
Whan I mean is: what's the best method to have the whole UI adapt to different resolutions?
This is an example:
As you can see: the whole navigation pattern changes along the UI when on different screens. On phones, we have the contact page that covers the whole UI, while on tablets and PCs we have the contact page that's just a fraction of the UI, and the pivot pages are moved into another panel on the right. Also, many of the UI elements are completely rearranged.
And of course, some view-level back-end code will change as well.
Now, I'm wondering what's the best approach to do this whole thing.
Should I:
• Have a single XAML file (for every page) with a lot of VisualStates and stuff, and try to rearrange the UI for every screen resolution
• Have different projects with a shared project (like with W8.1 universal apps), so that I can focus on the UI on every specific device? This is the approach I'd be more comfortable with, as I'd be able to design platform specific UI elements without problems. Still, I didn't understand how to actually create a shared project and different projects for each device type in VS2015.
• Use that approach with different XAML pages that share the same code-behind file (even I'm not sure how to implement this, and how to implement platform-specific code-behind parts).
• Some other method
I mean, I'm sure I'm not the only W8.1/WP8.1 developer in trouble here, is there some kind of advice I can use? I already watched all the MVA videos about W10 development, but they didn't get into the implementation details there.
Thank you for your help
Sergio
It really depends on your project. If a UI isn't changing too drastically, I would definitely use AdaptiveTriggers. You can do a lot with very little XAML. Check out Microsoft's sample code if you haven't already: https://github.com/Microsoft/Windows-universal-samples/tree/master/xaml_responsivetechniques
If it is changing drastically, you can do it with AdaptiveTriggers, but it's probably easier to have multiple XAML files. A new way to do this in Win10 is to use DeviceFamily. Essentially, just create a folder called "DeviceFamily-Mobile", and stick a XAML view with the same file name in there. More info: http://sharpgis.net/post/2015/04/01/Creating-DeviceFamily-specific-layouts-in-a-Universal-App
Those two screenshots aren't necessarily that different, if you look at using the SplitView Control and the RelativePanel Control.
See this //build talk for more info.
Would it be practical to create WPF applications without ever touching Visual Studio (or any other IDEs)? As in, coding and compiling completely within Vim and the command-line? What resources would you recommend for someone trying to do so?
It would be possible, since basically WPF is based on XAML - a variant of XML - and C# or VB.NET or another .NET language as its backend language.
The question really is whether that's practical and if it makes sense - I highly doubt it. WPF is all about visual design, e.g. totally without a visual designer (either the built-in one in Visual Studio, preferably the 2010 version; or some other visual designer), it seems a bit silly to want to program WPF....
As for resources - well, a least a text editor is a must, then definitely a few good books on WPF, and you could leverage the C# or VB.NET compiler that comes with the .NET framework.
I have found myself writing XAML in Notepad on a number of occasions where I needed to create a quick UI but couldn't load an IDE. It is really quite trivial, and almost - but not quite - as fast as using an IDE. The main advantages of an IDE such as Blend or VS.NET are in quickly getting things like colors and animations to be "just right."
Another occasion when I frequently write XAML or C# in a text editor is here on Stack Overflow. I only fire up Visual Studio when I need to test something out.
My main recommendations for creating WPF applications without an IDE are:
First you should make proper use of WPF's layout system, using appropriate panels and "Auto" sizing wherever possible. For example, if you want a stack of buttons with some space between them, create a <StackPanel>, and on each button add Margin="4" or whatever. This is good design anyway. Most beginning WPF programmers treat it like WinForms with no layout capability, which is a shame. WPF has a very powerful layout engine and it should be used. If it is, there will never be any need for graph paper or measurements. In addition, your UI will automatically adjust its layout if you change font sizes or objects are larger than expected.
Second you should use msbuild for your project unless it is ultra-simple. msbuild is installed along with NET Framework so it is always available. The file format is very easy to edit with a text editor, and it is much better than a batch file with the appropriate "csc" command because it allows you to use code-behind and is less error-prone when adding new source files.
Third keep a PowerShell command line window open separate from your editor, with a command that runs "msbuild" and then executes your application. To run your app, then just Alt-Tab to this window and hit uparrow, Enter. Some text editors have the ability to execute user-defined commands directly from within the editor and see the output, in which case this second window is not necessary.
Fourth keep a copy of cordbg or mdbg handy. Although an IDE is the ideal place to do your debugging, any debugger is better than none at all. You will find your problems much faster if you stop at breakpoints and examine variables than if you just keep editing code and re-running.
Fifth, use "ColorPad" or a similar application to select your colors for use. Just guessing and entering your best guess in hexadecimal just doesn't work very well.
For resources, I recommend you get the book "WPF Unleashed" and work through the examples. I would also read a lot of other people's XAML, such as can be found on CodePlex.
Possible, Yes. Practical No.
For production work, I would consider Microsoft Expression Blend 3. Then copy the XAML and paste it into the editor of your choice and compile from the command line.
You could download KAXAML . It's a free, lightweight editor. I found it good for learning about XAML and seeing how minor changes and tweaks can impact on an overall design.
XAML is plain old text so find a free editor (KAXAML), use it, and if you must, paste into your editor.
If you really want to go down this route, I'd recommend getting some graph (squared) paper and a sharp pencil.
Draw out your designs on that, read off the positions and type them into your editor of choice.
One benefit of this is that you're going to have a paper prototype to show people ;)
As James Keesey points out in his comment on marc_s's answer, your edit-compile-test cycle is going to be painful.
It's definitely possible. I'd say it's not practical, though.
To be honest, I do professional WPF development and I do it with the visual designer closed. I'm much more comfortable editing the XAML by hand, just like I write HTML. However, the benefits of an IDE go far beyond the visual designer. There's IntelliSense, debugging and a whole host of other invaluable features.
Really, I must question your motives. What are you trying to gain? Visual Studio Express editions fully support WPF development, so it can't, or shouldn't, be a cost issue.
The newest version (3.0) now supports the wpf template.
Just download it from: https://dotnet.microsoft.com/
Just type in console:
dotnet new wpf -o wpfHello
cd wpfHello
code .
Greetings :-)
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.