I have found that SurfaceImageSource can be used to create an 'island of DirectX' (i.e. DirectX inside WinRT alongside other XAML controls). Considering that SDL has recently been ported to WinRT, can I create an SDL game (not fullscreen) which can have other XAML controls at it's side ?
There doesn't seem to be adequate documentation yet on WinRT. Also, if it's not possible with SDL can I achieve this (a simple arcade-style game) with some other graphics library/game engine ?
XAML support for SDL/WinRT is planned, but not yet implemented beyond a barely-functional (and largely non-functional), proof-of-concept phase. Much of the work on SDL/WinRT has, so far, been geared towards getting non-XAML/Direct3D apps running well.
Initial support for XAML will, to note, probably be geared around SwapChainPanel and/or SwapChainBackgroundPanel, as the APIs for these map a bit more closely to SDL's own APIs. (At least, these are my own plans, development-wise.)
Related
I have a *.rive file and I want to use that in my WPF app like a loading spinner.
There is any way to use rive file in WPF using Image, Media Element etc.
Do I need to convert it as gif?
Short answer: You cannot
Rive is not just an animation tool, but an animation framework that requires a specially written runtime for different kinds of hosts.
Rive's documentation says they only have first-party support for:
The web (and a first-party React wrapper).
iOS, Android, Flutter, Tizen
React Native
"C++"
Note the lack of WPF, XAML, WinUI, UWP, Jupiter, Silverlight, WinForms, etc.
Microsoft's desktop developer story in 2021 sure is fun, isn't it?
MS hasn't had a clear and consistent desktop story since Windows 7, it's depressing, and still awful.
I note that "C++" isn't a platform, just a language, so it's odd that they describe it like that. Anyway, their C++ runtime ships with a renderer for Skia, which isn't of much use
Long answer: You can, if you want to put the effort in
Clone and build their C++ runtime.
Replace the Skia renderer with a new renderer of your own creation that renders to WPF somehow.
You can host Skia within WPF, but it's an opaque surface: the structure and contents of the Rive animation wouldn't be rendered directly by WPF which would introduce inefficiencies.
Also, I think WPF is still stuck on DirectX 9, and there might be functionality in Rive that would benefit from being on DX12.
And the rest is an exercise for the reader.
I haven't tested it but
here is a runtime for rive in C# + UWP
https://github.com/rive-app/rive-sharp
here is a way how to display UWP in WPF
In WPF control - display a UWP app
guys.
I have a opengl library written in c++. I know that I can use Angle but because of this I will need to code in C++ my whole app. Is there a way to use c++ opengl in UWP and still use C# as a main language?
Is there a way to use c++ opengl in UWP and still use C# as a main language?
ANGLE is currently the only way to get the OpenGL API to run in UWP. For more details please reference this thread.
You can write your own via interop if you want to use ANGLE from c#. You can also write your low level OpenGL stuff in C++ and wrapper it. Then invoke it by C# in your logic level.
Fortunately, people who have the same requirements as you created an issue on the GitHub a few days ago, and got samples from #mattleibow. #mattleibow shared his code in this thread. For more details, please reference OpenGL surface from SwapChainPanel declared in XAML in C#.
Additionally, ANGLE is actually for translating OpenGL ES to DirectX. So I recommend you to use Win2D instead. Win2D is a new, immediate mode 2D drawing framework for XAML applications on Windows 8.1 and Windows 10. It is built on the high performance foundation of DirectX, but is designed to provide the convenience and ease of use expected by C# and .NET developers. More details you can reference this video.
I realize it's been a long time since you posed this question, but I needed to do this also, so put together a small C# project that shows how to use ANGLE from C#. It includes minimal bindings to GL from C# (since OpenTK does not yet target UWP), and a part of the template application from ANGLE itself, which has all the SwapChainPanel, etc, setup. You can check it out here.
I had this issue, so I created my own library.
You could use my new library (https://github.com/hamarb123/hamarb123.SharpGLES) which runs OpenGL ES on UWP (and .NET Framework), it even has a GLESSwapChainPanel class for ease of use.
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.
Windows API
So i know that the WinForms touches on the Windows API a little, but frankly its horrible. ESPECIALLY with the layered windows and flickering. So i was wondering if anyone has wrote partial, or full wrappers for the Windows API.Im particularly interested in the Layered Window aspect, but really any part of the API is a good place to start.
Update: I found the Windows API Code Pack here: http://code.msdn.microsoft.com/WindowsAPICodePack but it seems that it doesnt wrap Layered Windows? Am i correct in assuming this?
Native API (Windows)
Ive heard a little bit about the Native API, but im not quite sure what it is for? what features does it provide? would it be a good idea to look into?
Summary (Questions in a nutshell)
Does anyone know of an existing (partial or full) wrapper of the Windows API?
If the answer is no to question one, where would be a good resource to learn about it myself, and potentially write my own?
An explanation of the Native API? What does it do? Can I use it to make applications better? Can I even USE it at all?
An answer to any of those is highly appreciated :) thanks
You could start at PInvoke.NET.
The LayeredWindows actually work better in WinForms than windows.
The native windows controls don't even have the alpha channel support of the WinForms analogues, so native windows flicker, and require massive amounts of subclassing to override the painting to use alpha compatible routines.
You would be better off going to WPF. The windows team has not treated the native control's well at all, going so far as to remove support for a style (WS_EX_COMPOSITED) if aero glass is enabled which, given the way that windows controls paint, effectivly made it impossible for any application to paint flicker free if it uses child window's as controls.
WPF "draws" windows controls, but does not use discrete (native) child windows to represent individual controls. This gives it control over when and how its window surface is rendered.
The Windows API is huge. There is a ton of stuff in it. Windows Forms is a wrapper of parts of it. WPF is a wrapper of parts of it. Parts of the Base Class Libraries (eg System.IO.*) are wrappers of parts of it. The Code Pack is a wrapper specifically of things that were new in Vista and Windows 7 and not in Windows Forms or WPF.
Have you looked into WPF? Combined with P/Invoke of specific API functions, it might take you a long way towards where you want to be.
After toying a little with the new Silverlight 4 camera features, and being really disappointed that these were not included in WPF, I looked at the Silverlight assemblies and found that they more or less delegate all work to agcore.dll.
Do you think it is a good idea to package agcore.dll with my WPF application, and copy/paste or rewrite all classes concerning cameras to WPF, to get these nice features there?
That particular approach isn't likely to work, unfortunately. There's a lot more to getting C# code to work with Silverlight than just referencing the appropriate DLL. Silverlight is actually a completely different implementation of the CLR, so you can't just call into agcore.dll from a WPF app and have it run.
If you need Silverlight features in your app, I can think of two ways to get them: (1) you could conceivably host a completely separate instance of Silverlight inside a browser control in your WPF app, though communication with that Silverlight instance becomes complicated (though not impossible); or (2) you could write your entire app in Silverlight OOB (Out-of-browser)/trusted mode.
You can try VideoCaptureElement in my WPF MediaKit. It will show a webcam in WPF. It does have a different API than the Silverlight webcam API, but it should have just as many features.