Use the facts to talk-silverlight5 has something to do

 

Test page, silverlight5 beta required

Https://crazylights.googlecode.com/svn/clge_publish/s5testTestPage.html

I am most concerned about xNa in silverlight5, And I have used silverlight5 to implement a spritebatch

XNa of silverlight5, I did a 2D test first.

Well, the performance is naturally not as high as the native xna4 performance, and data-intensive operations are the dead points of DOTNET.

But using this to make a few 2D games is naturally nothing.

Prospects:

It seems that sl5 can be used in many occasions to solve the problem, so as long as the investment is large enough to win enough power, sl5 can also form a huge application software ecosystem.

I have already considered using sl5 to build game development tools and server management tools.

Leave all the complex time-consuming operations on the server.

For example, the Visual Studio client can be developed using Silverlight, which makes the compiler a server.

All functions required by the client are available in Silverlight.

Problem:

For some purpose, of course, I don't know much about it. xna4 in sl5 is somewhat different from xna4 released with the WP7 SDK.

The biggest difference is that there is no effect or math library.

1. If no effect is returned, set vertexshader and pixelshader respectively.

2. There is no math library. I can write it myself.

3. Combined with hardware and thread Problems

4. rendertarget is missing

5. inconvenient texture settings

The most serious problem is that the combination of xNa and Silverlight is relatively rigid, and a control is simply bound to it.

In addition, the most serious case is that there is no way to control the painting by yourself. You can only re-paint the control and then process the painting in the xnadraw event of the control.

This is only the premise. The problem is that xnadraw is not in the Silverlight UI thread.

Controls and mouse events that operate on Silverlight are in the UI thread, while rendering is in another thread, which undoubtedly increases complexity.

Of course, this is not a problem for me who are familiar with multi-threaded programming. I just want to remind my friends who are interested in joining silverlight5 to play 3D. The thread process is more complicated than traditional Client development.

 

Problem 2: rendertarget is missing and there is no texture2d loading method. Only setdata or copyfrom (Silverlight's bitmapsource) is not a good choice.

The alternative to RT can be imagined, but I really don't want to mention it.

Copyfrom is a very bad texture initialization method. If you are practical, you must design an asynchronous control mechanism, which is not easy. The problem is the thread.

 

Although xna4 is only mechanically integrated, and the thread troubles are not provided with solutions and tools, you can watch the overall architecture.

It is still a secret.