which is faster moving image on canvas or moving whole canvas - performance

Lets say i am making a game in which there is background that is dynamic. Now in a setup where i am using multiple canvas, so one canvas dedicated for background as it doesn't need to update as often, Also Map is not infinite it's big but not that big.
So in should i move redraw the map at every move.
Or move the whole canvas which then would act like a layer.
Any ideas?
Will use css to clip map to size of game.
While it's true i have not tried anything but that is because i dont know what to try. I'd make both but wont know which one is working. Basically i am clueless in bench marking sector.
http://jsperf.com/translate-vs-background-position

Related

How to draw carets for text input controls on double-buffered surface with GPU?

For example, when I have a complex view with the only thing actually changing is the caret, I don't want to redraw the whole scene just to update the caret.
For now the only reasonable way I can finger out to do this is to cache the content without the cursor. This doesn't seems to be a too bad one, but I have to choose between always render to texture or decide whether to render to texture or not all the time.
Maybe this problem can be generalized to "the right way to handle an almost-static complex scene with GPU".
My experience from working on a few games is to generally render the whole scene again. The cases where it is prohibitively expensive to re-render the resource every frame you implement the caching yourself. e.g. You cache a shadow map for a dynamic light until the light moves again.
The caching solution you described is what an automatic cache would have to anyways, so its not unreasonable. What concern do you have with rendering the whole scene again?

Concatenating two images in opengl

I'm developing a little videogame in which I have an infinite background image which moves horizontally. The image obviously is not infinite, it just finishes the same way it starts, so if I concatenate the image with itself, it seems is infinite.
The problem I'm having is that in the place where the two images join, a vertical black line appear. Looks like is not joining them in the exact position and I can see the black background.
I thought it was because the width of the images were not integers, but even if I superimpose one image over the other, the black vertical line still appear.
Any tips please?
What you are trying to do is called tiling. The image should be inherently 'tile-able'. To do this, put two copies of the image side by side, edges flush with each other and see if they are seamless.
Now then, to make things work in OpenGL, the simplest way might to make the quad (i.e. the mesh) holding your background pretty large and map this texture to a small part of this mesh (so that the image itself doesn't look stretched). Use the GL_REPEAT flag when texture mapping so the image is tiled across the entire large quad.

Clip (don't render) anything outside of a cube / box, like Godus

I've been trying to work out how to clip / not render anything that falls outside of a box, exactly like how Godus works (pictured below: notice the clipping at the back)…
Originally, I experimented with constructive solid geometry (CSG) to manually split and clip every object that falls on the box boundary. However, this is hugely computationally intensive and isn't feasible for a system where I want to be able to scroll around and have the clipped area update in realtime.
Is there a way to achieve this in a way that runs in realtime without modification of the objects, perhaps with shaders or something else? I'm new to shaders and still don't quite understand them enough to know how to implement this myself.
I appreciate the help!
Can the camera go outside of the box? If not, just put a big cube around the area you want and give its inside faces a material.
If the camera can go outside of the box (which would be weird, since you'd be able to see through the back of the meshes) one thing you might try is using vertex colors to make all faces outside of your box the same solid color as the background.

Make HTML5 canvas behave like TclTK canvas for scale/translate?

I'm trying to port a TclTK program I wrote 20 years ago to HTML5.
After hours of frustation, I learned that when you "scale" or
"translate" HTML5's canvas element, it only applies to future
drawings, not items already on the canvas.
This is the opposite of TclTK, where items already on the canvas are
scaled/translated instead.
Short of creating a draw/redraw loop (where I clear the canvas and
redraw all the objects myself when I want to scale/translate), is
there anyway to make HTML5's canvas element behave like TclTK's?
Or am I missing something big?
The Canvas 2D Context is based around pixel-wise image manipulations — it is not a “retained mode” graphics interface as you are apparently familiar with. There literally is no record of your graphics for it to redraw. If you want to change the graphics, you have to redraw them somehow.
Everything is redrawing, in the end (though the redrawing may be hidden from your code), but there are ways to reduce the amount of work you have to do. Here are some options, roughly in order of amount of change you'll have to do to your code (and roughly in order of improved quality/performance):
Draw your graphics on the canvas, then scale and translate the canvas itself using CSS properties (not the width and height attributes of the canvas, which will clear it). This will rescale the image, possibly losing quality, since you're not drawing it anew optimized for the current scale.
Draw your graphics on the canvas, then export them into an ImageData or a data URL, then when needed redraw that onto the canvas. Again, may lose quality.
The above two are essentially kludges to keep using the canvas code you've already written. To get a proper system like you describe TK as being, you want to:
Build your own scene graph: Create a set of objects like Circle, Line, etc. which represent graphics, and containers for those which store transform attributes like scale and position. Then write routines to walk this graph and execute the appropriate drawing commands, whenever you need to redraw.
Use SVG instead. SVG is a language for vector graphics which, in modern browsers, you can embed directly in your HTML, and manipulate in JavaScript just like you would the rest of your page. In SVG, you can simply change a scale attribute and get the change you expect to see.
(The previous option is basically reinventing a small amount of SVG.)

How do I animate clouds?

I have 3 nice and puffy clouds I made in Photoshop, all the same size, now I would like to animate them so they appear like they were moving in the background. I want this animation to be the base background in all my scenes (menu,settings, score, game).
I'm using cocos2d, I have setup the menus and the buttons so the work but how do I accomplish this?
I was thinking to add this as a layer, any other suggestions?
Can anyone show me how some code how to make this please?
David H
A simple way to do it is with sine and cosine. Have slighly different parameters (period and amplitude) to ensure that the user doesn't realise (as easily) that they are programmatically animated.
You may also want to play with animating the opacity value. I'm not sure if layers have those, otherwise you'll have to add the clouds to separate nodes or images and applying it to them.
It's hard to be more specific without knowing what the images look like.
The simplest way to animate anything is to add the sprite to the scene, set the position and call something like...
[myClouds runAction:[CCMoveBy actionWithDuration:10 position:CGPointMake(200, 0)]];
This will slide the sprite 200px to the right over 10 seconds. As Srekel suggested, you can play around with some trig functions to get a more natural feel and motion paths, but you'll have to schedule a selector and iteratively reposition the elements.
The more difficult part of your questions is about getting the animation in the background of all scenes. Keep in mind that when you switch scenes, you're unloading one node hierarchy and loading a new one. The background cannot be shared. You CAN, however, duplicate the sprites and animation in all scenes, but when you transition between them there will be a jump.

Resources