This never made sense to me. I looked at GLFW's and Three.js' examples and Cinder's implementation which actually has this comment in there:
mark all windows as ready to draw; this really only matters the first
time, to ensure the first update() fires before draw()
All three libraries seem to be doing that and I don't understand why. There really is no point in updating the i.e. position of something that's never been drawn on screen or is there?
Here's what my loop looks like:
Draw the (first) frame
Swap buffers
Update events
Animate (with the input from the events), update logic, ...
Start from the top
This order makes a lot more sense to me but maybe I'm missing something.
I think that it makes perfect sense to update objects first and then draw them.
Imagine you animate a ball going from one side of the screen to the other and back just like a pendulum. Imagine you also want it to actually reflect real time in your computer. If you draw your scene before updating the ball's position, then where your ball will be positioned in the first frame? Unless you set it's initial position manually, it would be at zero point of your scene, which might be completely out of it's intended trajectory. If you decide to initialize it's position before start of animation, it might happen that there is a time gap causing it to be in the wrong position too.
But if you always update it's position before drawing, it will be on the right place right from the first rendered frame.
But to be honest - nobody will probably notice the first frame, so it is more sense of logic doing it that way rather than any practical reason. I just feel it makes more sense to prepare your scene before drawing it, not vice versa.
Related
In order to solve the problem of z-fighting, I limited the near and far of camera to a small range.But when I want to add a larger object,it was culled by view frustum.
I tried object3d.frustumCulled property,not working as expected,the reason is as follows:
https://github.com/mrdoob/three.js/issues/12170
So,is there a way to ensure that some specific objects are not frustum culled without changing the camera near and far? THX.
Culling doesn't mean that an object is drawn or not. It can be either drawn or not drawn depending on where it is. It is an optimization that tries to say something like this:
Hey, i have a really cheap check (plane/sphere intersection) that i can do and tell you if you need to attempt to draw this at all.
So you do a cheap check, and if the object is guaranteed to be entirely out of the frustum, you never issue the draw call. If it intersects, you have to issue a draw call, but you may still see nothing if none of the triangles are actually in the frustum.
If you download something like specter.js and inspect your draw calls, you will infact see that with frustumCulled = false you get a draw call for every object in your scene. Your screen may be empty.
Above you can see my Scratch workspace where the ship on the left is upside down when it is running, and IT IS THE SAME CODE.
Is it a bug of scratch or some kind of other problem?
Make sure that the sprite is set to don't rotate in the info tab
Alternatively, you can add the set rotation style to (don't rotate).
It will make the sprite no longer rotate all around.
Otherwise, if you want to make it look like it is walking rather than just looking in a direction while walking, replace the parameter don't rotate to left-right
I use Scratch 2 for kids programming classes and as a beginner at this object, at first I had the same problem that confused me a lot as to what would provoke the Sprite to turn around.
It turned out that Scratch makes the character rotate when it bounces off the edge (I guess that the reason is not functional).
Anyway to solve it I added the move->set rotation style (don't rotate) before (the position doesn't matter, could as well place it after) the if on edge bounce block.
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?
sorry for a dumb question. We put every drawing objects in Draw method, does all objects get drawn each time even some of them not changed? Does it need some kind of back buffer and draw at once to reduce flickering? or at least add if-else reduce drawing unchanged objects?
Draw is called every frame and yes it will re-draw the entire screen even if an object has not been moved or similar.
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.