I know this may be a bit early, but I've just started a new game in silverlight, and thought it would be neat to start it in Silverlight 5. The only problem is, I can not find -anything- online about drawing 2D. The very limited info out there is only for 3D. Does anyone have any links to examples, tutorials, or even just documentation that would help me with this? Would perhaps waiting a few weeks/months do me any good with google results?
Or am I totally wrong in my thinking, is silverlight 5 actually no more efficient at drawing 2D than Version 4? (or the slight benefit is not worth the complexity of drawing polygons in 3D space, and painting sprites on them)
If you want SpriteBatch in Silverlight 3 (or newer), use ExEn. It uses an elegant hack to get hardware accelerated immediate-mode sprite rendering using Silverlight's retained-mode graphics system.
(You could also use the retained-mode graphics system directly - but that is kind of painful for game development.)
If you want SpriteBatch in Silverlight 5, try the Silverlight Toolkit, which adds an implementation of XNA's SpriteBatch (and other handy things) on top of the subset of the XNA API that Silverlight 5 provides.
Check out this question and answer for a few tips on using it.
The major advantage of using the XNA stuff in Silverlight 5 is performance. It's hardware accelerated and it's immediate-mode rather than retained-mode. Ideal for game development. (And it can handle 3D.)
The two disadvantages are that there's a smaller install base of Silverlight 5, and not everyone has a video card capable of providing the hardware acceleration that its 3D stuff requires (whereas the retained-mode stuff can at least fall-back to software rendering).
By the way: Drawing in 2D using the 3D API is really pretty simple: Just set up an orthographic matrix, disable Z-buffering, and don't worry about the Z-coordinate.
(Disclaimer: I wrote ExEn, and I'm yet to actually try the Silverlight Toolkit for myself.)
Related
Im writing an application for embedded device that can display 3d coverflow like ui.
Requirements
1. High performance (60fps, preferably GPU accelerated)
2. Run in browser.
3. Supported in linux(android if possible).
Im not familiar with web/browser technology, but im familiar with .net/wpf and little silverlight. Ive tested multiple silverlight coverflow and perspective correct transformation is a bit laggy. the best implementation imho can be seen here http://coverflow.darickcarpenter.net/. it has virtualization, perspective correct. performance could be improve by disabling transparency altogether. im not sure if its gpu accelerated. im not sure how much performance can be squeeze from silverlight.
What platform/technology has the best 3d rendering performance in browser?
Edit. I just found a guy implement 2 similar coverflow in silverlight and javascript(webkit). Performance wise, javascript is extremely fluid. I thought since silverlight is created by microsoft, running silverlight in ie provides best performance. I thought silverlight 5 have gpu rendering support. Any opinion?
I would choice WebGL/HTML5 for near future browser technologies with attention to high performance.. It's also usable for most mobile devices with android right now..
So you might start with this pretty implementation in WebGL (also contains code) http://www.coconnut.com/blog/2012/07/25/html5-javascript-webgl-ejemplo-de-galeria-con-menu-tipo-coverflow/ .
I have an application that has some controls that use GDI+, mostly simple stuff with low graphics rendering requirements although I do have a couple of animated GDI+ windows that are borederline usable because of poor GDI+ performance.
Moving forward I would like to start using WPF (for performance and to learn WPF) but I also like to keep code compatible with Mono. As such I was wondering if I should or could develop using Silverlight (Moonlight in Mono). That way I get some WPF skills (I undertand silverlight is a subset of WPF?) and good performance.
Silverlight/Moonlight is a far better choice for any type of graphics and animations. GDI+ is old, and the Mono implementation exists mainly to support Winforms, which means it's not going to get any better. OTOH, while on the surface both use Cairo (as the previous poster mentions), that's like saying both render text - yes they do, but that's pretty much where the comparison stops. Moonlight is targeted for fast rendering, you get vectorial animations, you get hardware support whenever possible for graphics chips, because it really needs to be fast, it needs to support video with realtime render effects, 2D and 3D, etc. It might be that it's not yet up to par with the latest Silverlight version, but that doesn't mean it doesn't do what you need already. If you have the choice, go with new technology that's being actively worked on, not old stale tech.
Silverlight is indeed a subset of WPF allthough there are quite some details that work differently. Moonlight is currently compatible to Silverlight 2.0 but Microsoft is at 4.0 now with Silverlight. Moonlight will probably be always far behind Silverlight and even farer behind WPF. But if you can live with that, Moonlight might be a good choice. However if you will probably not see any perfomance improvements because Mono is using Cairo for rendering both GDI+ and Moonlight.
I also expect Mono's GDI+ implementation to be much more mature that the low level rendering APIs of Moonlight.
C# code that uses GDI+ instructions provided by System.Drawing currently are not compatible on Linux using Mono.
A null reference or invalid value was found [GDI+ status: InvalidParameter]
AFAIK no one was able to solve this error.
I am beginning to heavily invest in WPF and was wondering what those more knowledgeable than myself thought as to the wisdom of this decision. Is WPF the way forward?
Yes, it is the way forward.
WPF and using XAML for interfaces has completely revolutionised the way in which we develop said interfaces for our customers. The possibilities are endless, the learning curve is large, but with merit.
We can now do things in XAML that we couldn't dream of doing 3 years ago with WinForms - or things that take a few lines of code and an hour of logic that would have previously taken a full week of logic and four class files.
It's definitely the way forward for MS development, however there will always be people using WinForms.
They even developed VS2010 with WPF, that must give it something, right? ;)
Microsoft itself has begun developing its enterprise applications in WPF. They are invested in keeping it going for themselves, no reason to believe that the rug will just get pulled. Also, WPF has the Silverlight subset, which doesn't seem to be losing steam.
XAML is a nice, declarative method of setting up your interfaces with a lot of slick value conversion done for you and the opportunity to add more behind the scenes. It's possible to separate it from WPF, however (although they generally go hand in hand).
I understand that .Net 4 has made some progress toward using the XAML declarative language in Workflow Foundation and in Windows Communication Foundation, which will be interesting, given that those two are already fairly heavily declarative XML driven.
So, XAML is definitely the way forward for MS, especially given that at the core it's nothing more than a way to construct an object graph - any object graph.
WPF is also going to take some strides - for instance, inclusion of the much missed DataGrid (there are excellent commercial alternatives already), and more complex pixel shaders which should push more work to the hardware and increase rendering and startup speed of WPF apps.
As to whether WPF is THE future? Yes, for people who are tied to Windows, who value stylus input and handwriting recognition and who can find space in their development budgets for attractive UI development.
Against Flash, Flex, DHTML in general? I don't know. I'm inclined to think not - most applications don't need the full power of fat client development and don't care that much about pixel shaders et al, happily trading it against the accessibility of web.
Silverlight and XAML are not seamlessly cross compatible, and WPF doesn't transfer automatically to the web. (Yet?) Nevertheless I took the gamble on skilling up, and have found it to be time well spent. If nothing else, it's fantastic for prototyping.
I’m working on creating a full-screen 3-D app (based on Johnny Lee's Wii head tracking app) with some augmented reality features, and it seems that WPF is too slow to render even the simple models I’m using at a reasonable frame rate. I think the problem is that I need to change both the view and projection of the camera on just about every frame, because of the nature of the app (it uses a web cam to track your face, and uses that data to move the camera around and change its perspective).
I've spent a lot of time trying to narrow down the problem, and it's definitely related to the graphics, and not the speed of the head-tracking API that I'm using. Also, I recreated the app in XNA, and it seems to work fine there (28 FPS versus 9 in WPF). Finally, when I remove the "walls" or make the window much smaller (say, 800 x 600), WPF's performance greatly improves, which makes me think that the bottleneck is the graphics calculations.
As a result, I need to either find a new graphics back-end to work with, or find a way to make WPF much faster for this app. I’m mostly looking at DirectX and XNA, and possibly OpenGL. Any recommendations on which of these APIs would be best to use for this app in .NET? Or alternatively, any idea what I'm doing wrong in WPF that's slowing things down?
I've not done enough with 3D in WPF to be able to say what could be causing the slowness, but I did notice that it's model datastructure isn't very efficient. While this might not be the cause it could be symptomatic of general slowness to the whole pipeline.
One thing that does spring to mind is that WPF is rendering the scene in software rather than using the hardware acceleration on the graphics card. The fact that you get better performance (though you don't say how much better) with a smaller window.
If you remove any textures from your model do you get better performance too?
I don't think it really matters whether you go for Direct3D or OpenGL - virtually all modern cards support them equally well. XNA is the obvious choice if you're sticking with .NET as it's integrated into Visual Studio - even the Express edition.
I would check out SlimDX, a much thinner DirectX wrapper than XNA or WPF
The problem with changing the projection on every frame is that API's like XNA/WPF werent designed with this in mind, so were optimized to have projection set once in the initialization phase, then not again.
I would suggest a hybrid choice here: use WPF for what its good at (Windows UI, composition, etc) and use XNA to render the 3D. There are samples out there that demonstrates combining XNA with WinForms. It should be possible to do the same "trick" to render XNA onto surfaces in WPF.
Update: there are supposedly issues with using XNA directly with WPF. This thread indicates that using XNA with WinForms and then hosting the WinForms control in WPF is a workaround to these issues. I've not tested this myself though (yet).
Requirements:
Retained graphics mode API
For 2D objects only (though 3D transforms of these 2D objects is of interest)
Cross-platform
Vector graphics drawing
Raster compositing + support for opacity masks - hardware accelerated of course...
Animation API
Package size - can it run in an embedded environment?
This is not for a game, but I am not opposed to using a game type API.
Some thoughts:
Qt is probably too heavy-weight, but I am not familiar enough with the API to know if it would meet the requirements. I am not interested in Qts window management (there are no windows) or widget / control set as it is not for a desktop type application. Also, I am not sure if Qt has an animation framework? Thoughts here?
Most likely what this would be is a framework built on top of OpenGL. I just don't know if such a thing exists. Also, I am unclear about 2D graphics in OpenGL. Are 2D graphics truly 2D or are they simply 3D objects drawn on a plane oriented to look 2D?
WPF is to DirectX as _____________ is to OpenGL
If the blank can be filled that is what I am looking for.
Update #2
I spent some time this weekend with Qt and have discovered QGraphicsScene class - which seems to be the fundamental class for Qt's 2D retained type graphics mode - and QGraphicsWidget which allows some auto-layout functionality of the QWidget class.
Qt is close to passing my litmus test. One final thing to figure out is a good designer to developer workflow when dealing with Vector images, i.e., how do I take an icon created in Illustrator and turn that into a QGraphicsItem - this might be a good candidate for a new (more focused) question.
You might want to check out Cairo, it has an OpenGL backend. I don't think it has an animation API though.
As to using Qt.
It's not heavy-weight in any meaningful sense. The dynamic library is a few megs and the graphic operations are quite optimized I believe.
It does not have a stable version using OpenGL acceleration -- this is coming in Qt4.5.
It does use XRender or something, for 2D accel
Also it has a great drawing API, and an animation API (QTimeLine for simple things and recently the more powerful QtAnimation)
While OpenGL is a great tool for 3D rendering it is important to understand that at the end of the day the output medium is inherently 2D. Perceptions of the 3rd dimension is achieved through visual clues such as lighting, far object appearing smaller then near objects, and near objects occluding far objects.
These visual clues are implemented as computations at various stages of the graphics pipeline. Lighting and shading, viewport transforms, and depth queries are some of the operations used to create the illusion of 3D.
When using OpenGL for 2D, many of the pipeline operations typically used for 3D rendering can be ignored. This can result in performance improvements due to reduced computation and has the added benefit of simplifying the source code. There are also a number of operations that work specifically on a 2d raster such as drawing sprites.
Instead of thinking about 2D rendering as a reduced set of 3D rendering, I would encourage you to consider 3D rendering as the result of carefully constructed 2D elements.
WPF is also 3D. The library is tuned and designed to make 2D easy, but it has all the 3D transformations in there as well.