How to make a monkey game running smooth ?
Community Forums/Monkey Talk/How to make a monkey game running smooth ?
| ||
| Hey blitzers, I've tryed Atomic Blaster ( http://ava.feuerware.com/Monkey/projects/crossfire.build/flash/Crossfire.html ) by Mangoo (at monkey forum) and I'm impressed how smooth it runs - using Firefox. Question: is a Flash version always smoother than the HTML5 counterpart ? Or are there 'tricks' to smooth also an HTML5 version ? Or maybe depends only on the browser ? Regards, Sergio. Last edited 2011 |
| ||
| Depends on the browser at the moment. But, it will undoubtedly get better accross the board. FF3 and Safari are the two slowest i have seen because they have no hardware rendering (afaik) |
| ||
| Safari are the two slowest i have seen because they have no hardware rendering (afaik) Strange. Safari uses the very same backend as Chrome - WebKit - so there shouldn't be any difference in the performance. Question: is a Flash version always smoother than the HTML5 counterpart ? That depends on the browser AND the platform. Flash sucks on Mac OS X and it sucks even more on Linux. Try playing Zombie Trailer Park on those three desktop platforms and see the performance difference for yourself. HTML5 is not even an official standard yet, and thus far not even the newest browsers on the market fully implement and support it. Not to mention that, as always, they don't even interpret it in the same way. Firefox does things differently than Chrome or IE9. So I'm afraid that even HTML5 will not be a true multi-platform standard like Flash has been one for YEARS now. |
| ||
| Problem is, with a canvas of 1024 X 768 for example, I experience stuttering in the sprite movements. It may also depends on the size of the canvas then.. Anyway, on a Windows browser like FF, would the same game be smoother when compiled as Flash ? Sergio. |
| ||
| ->Strange. Safari uses the very same backend as Chrome I have both on my i7 mac and unless i have an old version (possible as i do not bother with safari) chrome is much faster than safari where html5 is concerned. Safari runs it little better than ff3. Edit: ok i take it back, safari seems to ave suddenly improved. i must have gotten an update or something. When i tried it when i first got this machine it ran crap.. like ff3 crap. Last edited 2011 |
| ||
| Strange. Safari uses the very same backend as Chrome Not quite... they use the same rendering engine (WebKit ), but Chrome has a different javascript engine (called V8). |
| ||
| Flash is smoother than html5 at the moment, even though with ie9, it gives it a run for it's money. With that said, Atomic Blaster is not smooth all the time, like other flash games you're still limited in the browser. |
| ||
| You try looking at this: http://www.monkeycoder.co.nz/Community/posts.php?topic=548 L8r, |
| ||
| Thanks Richard for the link - interesting code, may be a bit tricky to integrate in an app though. I'll take a deeper look later. Regards, Sergio. |
| ||
| Flash is smoother than html5 at the moment, even though with ie9, it gives it a run for it's money. With that said, Atomic Blaster is not smooth all the time, like other flash games you're still limited in the browser. As mentioned, its terrible in OSX... Both Chrome and Safari... I was gonna release a Flash version of my app until I seen it run, I couldnt look at it! :) Dabz |
| ||
| Initially I was getting pretty poor performance with HTML5 (except with IE9, which renders about 10x faster than Firefox 4). Then I got the full version and found that I could get about double the performance when compiling to Flash... but using v37 the HTML5 had also improved by a similar amount (compared to the demo which is still at v32 I believe). But with the exception of HTML5 under IE9, performance, particularly with large numbers of sprites, is still not that great. This is mostly of concern when constructing a tilemap, which obviously involves drawing a large number of individual tiles per update, perhaps a couple of hundred or more depending on the resolution of your canvas (and your tiles). When I run something like Cannabalt, even on my lowly MacBook, it appears to be getting a much greater tilemap performance than I can squeeze out of Monkey right now, so I wonder if there is some relevant optimisation trick I am neglecting, with regards to drawing up a grid of tiles... |
| ||
| some relevant optimisation trick I am neglecting, with regards to drawing up a grid of tiles... Ensure you only draw the tiles/sprites that are currently in the viewport... its an old trick, but found that it really helps with Monkey. |
| ||
| Hehe, naturally! (although I noticed that drawing large images partly off-screen does increase rendering speed proportional to the amount of the graphic that is not being rendered, so there are clearly some basic optimisations in place). But even a single screenful (say 20x15) is quite a big ask for Monkey in Flash. It doesn't seem to be an issue of texture page switching, a screenful of identical tiles performs similarly to a screenful of images from multiple sources. It does seem to be strongly tied to the number of sprites being drawn; fill rate for a single, large image is at least 3-4x faster than for a grid of 32x32 tiles - although the logic portion of the render is insignificant, time-wise. There seems to be quite a large per-sprite penalty when rendering. Last edited 2011 |
   |