background: i am developing a real-time multiplayer html5 canvas game using kineticjs which primarily will be played on MOBILE PHONE BROWSERS. There's a lot going on in the game such as socket communication with the server every second, redrawing and animations using kineticjs based on the server response and all this on top of a heavy graphic interface. The game functions well in desktop browsers however is SLUGGISH on mobilephones. So, I need to find all the ways in which the code can be optimized.
My questions,
lets say I need to redraw a particular part of the screen based on a server response that I just received from server, should I keep these need-to-be-redrawn elements in a separate layer, so that I need to redraw fewer elements. As in my case I need to redraw ever second, will this lead to performance improvement?
If the answer to the above is yes, then what is the optimal number of layers in which I should divide my layout. I ask this because I have a lot of different parts on the screen that need to be redrawn based on different server responses (although not all at the same time), if all these need to be put in separate layers, I need to know how far I can stretch the logic above, for example can I have 10 different layers without sacrificing the performance which is the aim of all this exercise anyway.
Eric Rowell (creator of KineticJS) has done some stress tests here: http://www.html5canvastutorials.com/labs/html5-canvas-kineticjs-drag-and-drop-stress-test-with-1000-shapes/
And he says this:
"Create 10 layers each containing 1000 shapes to create 10,000 shapes. This greatly improves performance because only 1,000 shapes will have to be drawn at a time when a circle is removed from a layer rather than all 10,000 shapes."
"Keep in mind that having too many layers can also slow down performance. I found that using 10 layers each made up of 1,000 shapes performs better than 20 layers with 500 shapes or 5 layers with 2,000 shapes."
So your takeaway is that
1.Yes, multiple canvas layers which isolate different groups of redrawables is the way to go.
And,
2.To optimize the tradeoff ( overhead of multiple canvas’s vs simplicity of 1 canvas ), you need to test with your own particular code in the environments they will be operating within.
Good luck with your game :)
Related
I'm currently working on a game using Three.js. I've been studying software engineering for four years and have been working professionally on backends for two, but I've barely touched on graphics aside from some simple Unity experimenting.
I currently have ~22,000 vertices and ~8,000 faces according to renderstats.js, and my desktop (above average) can't run it above 20 FPS. I'm using Lambert material as well as a single ambient light, so I feel like this isn't too much to ask.
With these figures in mind, is this the expected behavior for three.js rendering?
I would be pretty sure that is not end of the line and you are probably missing some possibilities for massive performance-improvements.
But just to give you some numbers first,
if you leave everything fancy away (including three.js) and just render an ultra-simple point-cloud with one fragment rendered per point, you can easily get to rendering 10-20 million (yes, million) points/vertices on an average GPU.
just with simple shapes and material, I already got three.js to render something in the range of 500k triangles (at 1080p-resolution) at 60FPS without problem. You can probably take those numbers times 10 for latest high-end GPUs.
However, these kinds of numbers are not really helpful.
Some hints:
if you want to debug your rendering-performance, you should first add some metrics. Renderstats is good, but I'd recommend integrating http://spite.github.io/rstats/ for this (see the example).
generally the choice of material shouldn't matter too much, the GPU is way more capable than most people think. It's more likely a problem somewhere else in the pipeline. EDIT from comment: In some cases, like hi-resolution displays with slow GPUs (think mobile-devices) this might be less true and complicated shader-code can slow down your site, but it might worth be looking at the other points first. As the rendering itself happens off-thread (so you can't measure it's duration using regular tools like the devtools-profiler), you can use the EXT_disjoint_timer_query-extension to get some information about what is going on on the GPU.
the number of drawcalls shouldn't be too high: three.js needs to do a single drawcall for every Mesh and Points-object rendered in the scene and too many objects are generally a far bigger problem than objects with lots of vertices. Reducing the number of drawcalls can be done by merging multiple geometries into one and making use of multi-materials, vertex-colors and things like that.
if you are doing postprocessing, the GPU needs to render every pixel on screen several times. This might as well massively limit your performance. This can be optimized by merging multiple postprocessing-passes into one (I admit, that'd be a lot of hard work..)
another problem could be on the JS side: you should use the profiler or timeline-view from the chrome devtools to see if maybe it's the javascript that is taking too much time per frame (shouldn't be more than 8-12ms per frame). I've been told there are ways to optimize the javascript-performance as well :)
I'm trying to setup GeoServer to display 2 data stores. Both are full Earth tile sets, 1 for Day and 1 for night. The imagery is 200m which roughly translates to 2x 50 1.2GB GeoTiffs. For context, the application this a museum exhibit that simulates the view from the Space Station. Tiles need to load quickly and often times for large areas if we're going to provide an oblique view (looking over the horizon). We're using CesiumJS for the renderer which has support for most of the imagery provider standards out there.
Steps I've tried already tried:
ImageMosaic. I can't load Zoom Levels 0-4 without the server running out of memory. At the further zoomed out levels I get a stupendously blurry image and it takes minutes for it to return the actual high-resolution tiles. I have caching on and I've even run the seeding process.
ImagePyramid: Using GDAL I built an ImagePyramid with 11 layers for each of the tile sets. This seemed to help a little, but seems to have capped the resolution greatly.
At this point I can only assume I need to do some fancy hybrid configuration of the 2, but I'm at a loss for where to actually start or if there is actually just a defacto way these sorts of configurations are handled.
Got anyone that is interested the solution that worked best is to merge the tiles together and use gdal2tiles to create a TMS server.
I am a video game programmer working on building my own video game. I've decided that in order to build my game, I am going to need a large amount of animation files from 3DS Max.
My question is, what is the best approach to building a huge number of animation files? I'm looking to create 20 movement animations + 4 fighting styles * 18 attack types + 8 shooting animations + 10-20 magic casting animations for an estimated total of 128-138 animations (and probably more that I can't think of now).
I'm personally only planning on creating a small number of these animations myself, but I am trying to design the best workflow for creating a huge number of animations so that once I decide to create these animations, it is a feasible task.
I am familiar with how to create animations manually in 3ds max, but this approach seems slow, and would seem to take too many manhours to complete. I am vaguely familiar with motion capture, but I don't know any approaches for this or tutorials, and I don't know if this would work out at that scale.
Should be only few suggestions to make many animations quickly in low budget:
Avoid 3ds Max bones, use Biped system with Skin modifier, so you don't have to spend much time creating the rig.
Plan your game design adjusted to your possibilities: I mean, simple character models, without complex effects like hair, clothes and face expression morphs.
Since motion capture is expensive you can use reference videos inside your scene putting them in a plane's texture to help you creating animation keys.
Use MaxScript to solve repeating task. MaxScript is easy to learn. And there is lot of free plugins at: http://www.scriptspot.com/
There is lot of work involved you can't avoid if you want to create original content, unless you choose the expensive way:
The really fast quick approach is to use a service like: http://www.mixamo.com/
There you upload your model, auto-rig it and apply animation in less than 3 minutes each one. They have a database of motion captures and also provide custom motions.
Suppose we're making a strategy game (think Civilization) in a web browser. The game has a visible map portion - say 30x30 squares. Each square is 30x30px and has several overlaid images - the terrain, resources, units, roads, etc. The classical way of drawing this would be with a huge <table> where each cell would contain absolutely positioned images. It would probably be rendered in Javascript to reduce traffic. But it's still several thousand images and a huge table.
Can the browser take it? Will the performance not drop below any acceptable limits? Alternatively I could keep a pre-rendered map image with as many overlays as possible, but that would be more work, I think.
You should really look into using the canvas element which does not require the browser to store and compute the whole layout and other DOM stuff.
That being said, a modern browser on a high-performance workstation can display hundreds of images at the same time as demonstrated with the FishIETank. However, many devices - ranging from smart phones to old PCs - can not. Oh, and using a table is probably slower than a div with position:relative; or absolute and absolutely images therein.
Look at online games like grepolis, they already do some sort of a grid like game, and modern browsers can take this easily.
I'm planning on writing a game using javascript / canvas and I just had 1 question: What kind of performance considerations should I think about in regards to loading images vs just drawing using canvas' methods. Because my game will be using very simple geometry for the art (circles, squares, lines), either method will be easy to use. I also plan to implement a simple particle engine in the game, so I want to be able to draw lots of small objects without much of a performance hit.
Thoughts?
If you're drawing simple shapes with solid fills then drawing them procedurally is the best method for you.
If you're drawing more detailed entities with strokes, gradient fills and other performance sensitive make-up you'd be better off using image sprites. Generating graphics procedurally is not always efficient.
It is possible to get away with a mix of both. Draw graphical entities procedurally on the canvas once as your application starts up. After that you can reuse the same sprites by painting copies of them instead of generating the same drop-shadow, gradient and strokes repeatedly.
If you do choose to draw sprites you should read some of the tips and optimization techniques on this thread.
My personal suggestion is to just draw shapes. I've learned that if you're going to use images instead, then the more you use the slower things get, and the more likely you'll end up needing to do off-screen rendering.
This article discusses the subject and has several tests to benchmark the differences.
Conculsions
In brief — Canvas likes small size of canvas and DOM likes working with few elements (although DOM in Firefox is so slow that it's not always true).
And if you are planing to use particles I thought that you might want to take a look to Doodle-js.
Image loading out of the cache is faster than generating it / loading it from the original resource. But then you have to preload the images, so they get into the cache.
It really depends on the type of graphics you'll use, so I suggest you implement the easiest solution and solve the performance problems as they appear.
Generally I would expect copying a bitmap (drawing an image) to get faster compared to recreating it from primitives, as the complexity of the image gets higher.
That is drawing a couple of squares per scene should need about the same time using either method, but a complex image will be faster to copy from a bitmap.
As with most gaming considerations, you may want to look at what you need to do, and use a mixture of both.
For example, if you are using a background image, then loading the bitmap makes sense, especially if you will crop it to fit in the canvas, but if you are making something that is dynamic then you will need to using the drawing API.
If you target IE9 and FF4, for example, then on Windows you should get some good performance from drawing as they are taking advantage of the graphics card, but, for more general browsers you will want to perhaps look at using sprites, which will either be images you draw as part of the initialization and move, or load bitmapped images.
It would help to know what type of game you are looking at, how dynamic the graphics will need to be, how large the bitmapped images would be, what type of framerate you are hoping for.
The landscape is changing with each browser release. I suggest following the HTML5 Games initiative that Facebook has started, and the jsGameBench test suite. They cover a wide range of approaches from Canvas to DOM to CSS transforms, and their performance pros and cons.
http://developers.facebook.com/blog/post/454
http://developers.facebook.com/blog/archive
https://github.com/facebook/jsgamebench
If you are just drawing simple geometry objects you can also use divs. They can be circles, squares and lines in a few CSS lines, you can position them wherever you want and almost all browser support the styles (you may have some problems with mobile devices using Opera Mini or old Android Browser versions and, of course with IE7-) but there wouldn't be almost any performance hit.