Game Development

Re: Super Mario, Tile Based Game and Silverlight Performance

Jose Luis Quintero Mendez — Thu, 27 Aug 2009 07:15:57 GMT

Example in Game RPG. http://www.elquintero.net/games/SimonTheLegacy/

Re: Super Mario, Tile Based Game and Silverlight Performance

Grofit — Wed, 08 Jul 2009 11:49:30 GMT

I revisited my tile system to see if there were any immediate issues i could look at updating... and it ends up that i was already translating the canvas, so im not positioning every single one of the tiles... one thing is though im using 32x32 tiles so i would end up having more smaller elements compared to your fewer larger elements... i wont be in my actual game but as im just prototyping everything i thought i would start with them.

Anyway my framerate is awful, its perfect if you are stationary constantly > 60fps with menus and other things going on... but the scrolling kills it. It seems to be marginly slower if i just put all the tiles into the canvas and let SL deal with what to display on the given page. However if i use a quadtree system to enable/disable children as and when are needed it is like 5fps faster.

Im not sure if the bottle neck comes from having lots of things to draw on screen or just having lots of things in the canvas... im hoping to be able to have >30fps consistantly with the scrolling and lots of stuff on screen at once and hopefully some simple particle style effects... although im not sure if it will happen :( as im struggling to get >20 fps when scrolling with more than 1 tile layer at the moment... im still got a few optimizations up my sleave like baking the static things together ad a few other tweaks around...

I also tried testing my app on my other laptop, which is a dedicated gaming one... and it got pretty much the same performance as my crappy little laptop which i found as odd...although it does only have a single core (its >3 years old), and im guessing SL still hammers the CPU more than anything else...

Re: Super Mario, Tile Based Game and Silverlight Performance

HaywireGuy — Tue, 07 Jul 2009 14:45:26 GMT

Well, Ksleung I am not sure if that is going to solve my problem. I was merely doing a WriteableBitmap.Render(m_SourceImage, new TranslateTransform) when the "jump" needs to happen (roughly once per second), and it already causes jittery movement. I can of course lower my frame rate to make the "jump" transition smooth (if each frame takes longer time than what is required for the jump transition, then the jump won’t be noticeable). But I doubt I’d want to go there. I do trust SL team will be improving this "blitting" overtime though.

Gofit, I have 384 tiles in the humungous Content Canvas at one time. Older tiles that scrolled out of view will be recycled and used in position of newer tiles, which then get scrolled into view. The only reason I use humungous canvas is because of the limitations I stated in the original post (to avoid 384 calls to Get/SetValue on 384 Image objects, which was proven to be costly).

The tiles are the "background" actually. 384 isometric tiles made up the map that covers the entire displayable area. I have yet to put static buildings on the map, but I don’t expect that to cause much problem. The frame rate for a scrolling background of this many tiles is quite satisfying on my single core laptop actually.

Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Grofit — Tue, 07 Jul 2009 07:21:35 GMT

I completely agree with you about WritableBitmap being alot better suited for this sort of task, just with the performance bottle neck its a killer...

When you said you were getting around 54 Fps constant with a massive canvas, how many tiles did you have (roughly) in it and how many tiles were on screen at once (roughly), for my game the resolution will be anything between 640x480 to 1280x1024 (or whatever the resolution is around that size). This means i would have a few hundered on screen at once, but also they are layered, so although there may be lets say 200 flat tiles, there may be 3x this many acctually on the screen, and paired with any other moving objects... i think im going to try and test this tonight, i got a bit carried away with writing some of the logic the other day... oh and moving house, so will see if i can bring back any numbers from my example...

At the moment the juddering on translating is killing my game, and if i could get rid of that it would probably be fine and i can do a little dance! OH also while we are on topic...

so far we have been comparing Canvas.Top/Left vs TranslateTransformation.X/Y, for a reason i cant remember off the top of my head i have had to use both. I think the static tiles dont ever change the Canvas.Top/Left but as i have lots of moving entities they require the canvas position to move as well as the render transformations... well i think so off top of my head anyway...

In your game im guessing you will have the goomba equivalent which will be moving around a bit, how have you gone about doing his movement with a scrolling background? Same route as me or some other gem?

Re: Super Mario, Tile Based Game and Silverlight Performance

ksleung — Mon, 06 Jul 2009 17:30:52 GMT

Good to hear that you made some progress.

One comment on WriteableBitmap.

I don't think the SL team will provide access to the WriteableBitmap in background thread. The reason is that SL must have full access to all UI assets whenever it is running the UI thread, so it really cannot afford to let you muck with it in the meantime.

I do hope that the SL team can provide better WriteableBitmap APIs. Currently the only pixel access is the [] operator, which I image has tons of checks (security and bound) on a per-pixel basis. This is highly inefficient especially we all want to use WriteableBitmap in a very heavy way. Why not provide wholesale array copy API? For example,

WriteableBitmap.CopyFrom(int[] Src, int SrcWidth, int SrcHeight, Rect Region, int TranslateX, int TranslateY);

WriteableBitmap.CopyTo(int[] Dest, int DestWidth, int DestHeight, Rect Region, int TranslateX, int TranslateY);

This way, whatever check only needs to be done once.

It is still okay to require that these APIs be called from the UI thead. But at least this approach would allow us to write decent code to perform all the maths in the background thread, and make one async call to push the result to the WriteableBitmap.

I hope the SL team would consider this. Perhaps they already did, but the frustrating thing is that nobody knows!

Re: Super Mario, Tile Based Game and Silverlight Performance

HaywireGuy — Mon, 06 Jul 2009 14:18:22 GMT

Okay folks, I have got some updates regarding the humungous Canvas. The outcome is good; I have created Canvas of size 20480x10240 pixels at no additional cost (both in terms of memory consumption and performance). So Ksleung was right. I am having 384 tiles visible each of which is 64x32 pixels in size. Content Canvas hosting them moves smoothly (it is going at 58fps constantly) since I no longer have to offset these 384 tiles when the “jump” happens.

Thanks for your performance benchmark, Bill. I still use Get/SetValue methods for now as 384 tiles are much lesser than 4000 in your case, so I don’t expect that to cause too much of a problem (also I suspect creating another 384 TranslateTransform will likely to stress .NET runtime in a way that it needs to track these objects’ lifespan).

I am not sure what is going to happen if I have more tile bitmaps in future, I hope Silverlight runtime puts all my bitmaps on one texture in hardware level (imho texture switching in video memory is costly).

While this is not the optimal solution I would personally like to see (I think WriteableBitmap is more “natural” for my purposes), it does solve the problem for now. Ultimate solution I’d like to see is the ability to access Image (in SL3 RTW, even if it is read-only) from a background thread, then the jittery issue can be completely resolved.

Thanks again for your help, guys!

Re: Re: Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Qbus — Mon, 06 Jul 2009 13:09:24 GMT

Man, you have a lot of good stuff coming :) Really looking forward to it. Actually I have just brought Michael Show's "Game development in Silverlight" book (not sure the name is right). Guess I will by yours when it comes out.

Re: Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Bill Reiss — Mon, 06 Jul 2009 13:06:35 GMT

I also have a solution to the inheritance problem that I'll be blogging about soon and is covered in the updated game chapter in my book, available soon electronically.

Re: Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Qbus — Mon, 06 Jul 2009 12:59:12 GMT

Ok great, I would like to read that post, as you can see I have asked my self the same question, about using one over they other. A big difference between Canvas and Grid, is the ease of implementation if you ask me. It's much easier to implement the Canvas approach. When using the Grid you need to set up all these transforms in the load event of something, and it's pretty much code you need to repeat, as you can't just easially inherit stuff like this in Silverlight. :)

Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Bill Reiss — Mon, 06 Jul 2009 11:33:50 GMT

For my tests, both used a Canvas, since the Grid has some overhead even if you're just using TranslateTransform and you're not using any of its features anyway, and I was using SL3 with GPU acceleration and about 4000 moving elements. I was getting about 40 FPS with Canvas.Left and Canvas.Top, and 45 FPS with TranslateTransform. With less elements the difference was negligible. I'll blog about my sample once SL3 is released.

Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Qbus — Mon, 06 Jul 2009 09:52:30 GMT

I actually did a test too on this (very simple) and I actually see it performing very equal. But I haven't used any tools for performance testing or anything, just looked at the FPS counter.

http://laumania.net/post/Using-Grid-or-Canvas-as-sprite-container.aspx

Re: Super Mario, Tile Based Game and Silverlight Performance

Bill Reiss — Sun, 05 Jul 2009 13:59:28 GMT

HaywireGuy:
Q: Should I be setting Canvas.LeftProperty, Canvas.TopProperty of each Image object, or should I use Image.RenderTransform property? Which one is faster and lighter to Silverlight runtime?

I did some tests on this recently and saw about a 10% performance gain using TranslateTransform instead of Canvas.Left and Canvas.Top. This is probably because of the extra overhead of setting attached properties using SetValue.

Re: Super Mario, Tile Based Game and Silverlight Performance

ksleung — Sat, 04 Jul 2009 16:50:17 GMT

I am really surprised that the once-in-a-while rendering of primary to secondary WriteableBitmap is causing a lag... A few ideas:

(1) make sure you don't turn on the Bitmap Cache on the WriteableBitmap. I don't think it'll help and in fact may force SL to do more work (keep a separate cached copy of something that takes zero effect to build).

(2) perhaps you can use multiple WriteableBitmaps, like 48x320. So, you avoid the problem of having the blit the entire primary over to the secondary.

(3) i was also wondering about this in the previous reply... can you look ahead and blit to the secondary when it is not as busy? Not sure how to do this though (like an OnIdle)...

(4) yes it sucks that WriteableBitmap can only be touched in the UI thread. I complained about this in the SL4 wishlist as well.

Re: Re: Super Mario, Tile Based Game and Silverlight Performance

Grofit — Sat, 04 Jul 2009 16:40:10 GMT

haha i didnt know there was a built in frame counter, i had my own timer going to track it... i found that using WritableBitmap was brilliant and logical and just like making a game on any other platform until i tried running it and it was slower than a 486 running crysis...

I found the only way to get *reasonable* performance (30fps) is to do the trick you mentioned earlier with 2 layers, one being the viewing canvas, and one being the moving canvas. It still juddered hits about 30fps every time you move, but thats alot better than 10fps it was hitting before... Ive turned GPU acceleration and caching on and noticed no benefit.

In my current game my player is usually at center of the screen unless they are near an edge, ive basically made my own simple translation system, so everything has a game position, then the virtual camera is bound to the players position and everything else is drawn with the offset of the camera. That way i dont have to worry about maintaining local and render transform things all the time (well i do but its abstracted) i just make sure everything has a game position, and then when the camera gets to close to an edge it becomes unbound from the player letting them walk to the edges of the screen... still doesnt work 100% way i want it to but its better than nothing...

My net will be off for a few days while i get it setup at the new place but it would be great to see how you get on as you sound like you are doing same stuff as me, if you can post any reports on FPS you are getting with movement and tiles that would be great!

Re: Super Mario, Tile Based Game and Silverlight Performance

HaywireGuy — Sat, 04 Jul 2009 09:51:31 GMT

First of all, thanks for taking time to answer my questions, guys.

I have omitted some history on this implementation actually. Instead of having individual tiles, I used to have one WriteableBitmap in the Content Canvas. This WriteableBitmap is as big as the Content Canvas and it represents static background data (i.e. those bricks on screen). In DirectX term this is called "primary WriteableBitmap", and there is another "secondary WriteableBitmap" which is not shown on screen.

When the "jump" needs to happen, the unchanged portion of the "primary WriteableBitmap" is blitted to the "secondary WriteableBitmap" through "WriteableBitmap.Render" method. Delta tiles are then rendered on the "secondary WriteableBitmap", followed by a "flip" which displays the "secondary WriteableBitmap" in the Content Canvas. Delta tiles are only a fraction of the entire screen, so blitting them (again, WriteableBitmap.Render) does not take much time, but I found the bottleneck is actually the part where "primary WriteableBitmap" is blitted onto the "secondary WriteableBitmap" (even in Release build with GPU acceleration turned on and bitmap cached them).

If you imagine a smooth scrolling of the Super Mario screen, there will be occasional "pause" happening, for my case, once every second. Though not exactly the same as Super Mario game, my game fixes the player in the middle of the screen, and it is very common for user to say "hey, please walk from (0, 0) to (80, 65)" with a click of the mouse button. Naturally, there will be multiple "jumps" that need to happen, which results in jittery scrolling.

I tried using a BackgroundWorker, but as you may already know, it does not allow access to tile "Image" objects which are required for composing the "secondary WriteableBitmap" in the worker thread. I’d really appreciate if anyone can illustrate how to do "WriteableBitmap.Render" in a non-UI thread.

Then I switched to use independent Image objects on-screen. Currently for the extreme case of my game, I will only have around 500 tiles on screen. It improves the jittery situation significantly, but still the jitter can be felt slightly. So if I am able to eliminate the offsetting of each Image object (by using a humungous Content Canvas), then the problem is likely to be resolved completely. Let me report this back soon as I figure it out (thinking of BitmapCache and the humungous Content Canvas sends a chill down my spine…).

Also, I believe it is right to say single BitmapSource is duplicated for each Image object; that may explain why I saw bigger numbers when I turned on "EnableFrameRateCounter", if there are more Image objects (by the way, can you explain what are the five numbers shown when "EnableFrameRateCounter" is turned on? I know the first one is frame rate).

I welcome more suggestions and possible ways to eliminate jitters entirely.

Thanks,
Ben.

(Marked both these as answers, both helped in some ways.)