mansim Posted July 15, 2016 Share Posted July 15, 2016 I have a project with armies on HTML5 canvas. There can be 10.000 army units on screen and all are moving. But not at the same time. Every frame there is about 20-1000 units moving on random places, others are waiting for free way to move forward. I am redrawing the whole page, 1500x1200 screen canvas at 20 fps. I have readed many tips on how to increase performance - that i need to draw only changed content, and now brainstorming on how to increase performance and draw only the moved units. But - maybe you know any source, link or book where i could find the answer? I can find out how to do this alone, but it can take very long, I believe in every game needs this performance increase by drawing only changed content, where random places are changed, so maybe you know it or already implemented it. Quote Link to comment Share on other sites More sharing options...
Fatalist Posted July 15, 2016 Share Posted July 15, 2016 7 hours ago, mansim said: that i need to draw only changed content, You will also have to redraw every sprite that touches the bounds of the changed sprites. I don't think it's going to be very effective in your case... Try using WebGL, there is a massive difference between WebGL and canvas when it comes to drawing lots of small sprites. I recommend PIXI.js library, for just drawing sprites it's really easy. Quote Link to comment Share on other sites More sharing options...
mansim Posted July 15, 2016 Author Share Posted July 15, 2016 wow thx for a clear answer. THat really is, i would need to redraw every sprite that touches bounds of changed sprites and that was unclear for me how to reach it. I will try out this pixi.js and wegl Quote Link to comment Share on other sites More sharing options...
mattstyles Posted July 16, 2016 Share Posted July 16, 2016 Are you sure the rendering is the performance bottleneck? Have you used tooling to try and find where the choke points are? Rendering lots of sprites is an issue but even on my work MacBook Air with its turd GPU the Pixi bunnymark can hit nearly 100k sprites without really struggling so maybe your optimisations might be better made elsewhere? Its only another point of view. Do your 10k units perform AI calcs every tick? Do they do pathfinding? This stuff gets expensive quick. WebGL would surely help though, keep an eye on your textures and stuff for even more performance (if all your sprites are from a single texture there is a significant boost, consider ^2 textures). Quote Link to comment Share on other sites More sharing options...
mansim Posted July 16, 2016 Author Share Posted July 16, 2016 Well if i don't draw unit sprites, it has really much faster perfromance. Yes, my 10k units perform AI calcs every tick. There is no pathfinding. Every unit is looking at 3 positions [0, 1, -1] every frame. But yea, i plan to improve my javascript performance in future. Just trough maybe easier and faster job first would be to improve rendering. I am drawing whole big screen of units. One caveat is that i resize my sprites. I have many multiply functions. I plan to make for every multiplying - an unique spritesheet. But i trough that the biggest bottleneck is that i redraw all sprites on whole screen. On other hand, it would be hard to find a function how to draw only changed screen, when after 30s of action whole screen is moving if there are so many army units - they all are moving and doing something. 10k is an example, actually there is no limitation and before a year with smaller size of project i handled easy 100k units on screen(there were only cubes drawed). But now more calculations, much better unit graphics and a lot more done. So you say that i should ignore the screen redraw performance problem and concentrate on my javascript/images? That should be faster reached performance? Quote Link to comment Share on other sites More sharing options...
mattstyles Posted July 18, 2016 Share Posted July 18, 2016 No, not necessarily, drawing is expensive but if you use a lib like Pixi its mature and optimised to the hilt, you can see from the bunnymark that it can handle larger numbers of sprites with movement (and rotation? scale? not sure thats in the mark but I think under the hood it provides the transforms so shouldn't be too much difference, scale will make a difference though) without too much trouble, even on fairly cruddy hardware. Like you say, if all your sprites are moving most of the time you'll end up redrawing most of the screen each tick anyway so its not worth the hassle of trying to work out dirty regions. I guess the point is that if Pixi can handle 10k moving sprites with ease, but you're struggling to keep the frames up so either your rendering implementation (are you using something like Pixi or another lib?) is flawed or something else is chewing up CPU. It would be good if your rendering stuff is flawed because you could swap in a more performant lib and get boosts with very little effort. The scaling I think does get expensive, I'm not sure exactly why though, but have you tried to render without scaling and seeing if you get an immediate boost in perf? Might pave the way for knowing where to stick your optimisation efforts. Kyros2000GameDev 1 Quote Link to comment Share on other sites More sharing options...
mansim Posted July 20, 2016 Author Share Posted July 20, 2016 Thanks a lot for explaining about pixi and other things. I will take my time improving performance, there are so many ways to increase performance. Quote Link to comment Share on other sites More sharing options...
Firenibbler Posted August 13, 2016 Share Posted August 13, 2016 Check out this post on html5 performance. It might provide a new perspective. http://www.firenibbler.com/2016/05/best-performance-tips-and-tricks-for-your-html5-canvas-games/ Kyros2000GameDev 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.