When I drag an object in my game, the object is never directly under the finger. There us this lag / delay that I cannot get rid of. It follows my finger instead of being directly underneath it. You can try in the Testbed as well. Trying moving an object really fast and the object is never underneath the mouse/finger
Is this a weakness in box2d? Or am I missing something obvious ?
Thanks in advance
That's because mouseJoint is similar to distantJoint (spring). There is a maxForce parameter you can specify to minimize the delay - make the spring more hard.
EDIT:
Also you can move your object directly specifying it's position to your finger position. But if this object will collide with something it will provide non-physical behavior because the velocity of the body will be zero.
So to move it correctly (if there will be collisions) you should specify it's velocity or acceleration (as mouse joint does). But to evaluate your finger velocity you will need some time and delay will remain.
Most of it has to do with latency in the hardware. If your timings are completely perfect, their will be 16ms of lag caused by the iPhone's GPU, ~20ms of lag from the touchscreen, and then how ever long the processing takes for your scene. So those add up to anywhere between 36-70ms of lag. Also, there is a small amount of damping applied in box2d on the mouse joint, for stability of the physics simulation.
Related
I'm learning basic frame independent movement, but I have a necessary need in the implementation.
Right now, I'm searching for C++ code, but I need a complete example inside a GameLoop that allows an increase in speed. Not a gradual increase, but just the ability to move my sprite faster. I have to translate the C++ code to vb .net since there are not many examples. So let me be clear about this ->
I have a simple GameLoop. In the GameLoop, I have two calls to functions
Update()
Render()
I understand that for the Update() function I should put a deltaTime parameter. So it should be
Update(deltaTime As double)
Since this is how most examples on the web are shown, I just copied the idea but I don't have an actual frame independent setup yet.
How can I set this up and call the Render function.
Please keep in mind, that if it works, that's fine - I cut and paste a different example like that before, but there was no way to increase the speed of the moving sprite. I don't even know where to begin with this?
Please note if you only have C++ code, I will do my best to translate it, so for me it's acceptable.
I wont give you code, cause I'm positive that you will be able to fix this with a proper description, but I will gladly explain how to move your sprite without frame rate dependency.
As you said, you already pass a delta-time in to the function.
The delta time is the time that it took between now and the last time the function was called (a frame).
When you move your sprite, you probably move it by a specific number of pixels, instead of doing this every frame, you should multiply the pixel range with the delta time.
This will make into a quite simple formula:
DetlaTime * TheNumberOfPixelsToMoveInASecond.
If you mul it with 10, then the sprite will move 10 pixels in one second. Mul it with 100, it will move 100 pixels in one second.
That deltaTime idea is to allow your game to run in a way where the perceived speed of the gameplay is constant no matter how fast or slow the machine and environment are that are running the game.
You might notice if you run some poorly coded games designed for old hardware on hardware much newer that the gameplay goes way too fast and becomes unplayable on those fast machines without deliberately slowing things down. There are actual slowdown utilities just to deal with that problem, like Mo'Slow and Cpukiller. This is because these old games were coded in a way where things were being changed by a constant amount every frame instead of a variable amount based on the time that has passed.
So to avoid this problem, you move all your sprites each frame by numbers that are multiples of deltaTime. That'll give you the sense of consistent speed regardless of the speed of the machine/environment.
Now if you want an adjustable game speed on top of that where you want to allow users to deliberately make the game faster, then you introduce a second variable on top of deltaTime that you also multiply by, like gameSpeed. So your sprites should move in Update by a multiple of both deltaTime and gameSpeed.
I have a 5 frame run animation for a character on a sprite sheet. I would like to give this character multiple "upgrades", such as sunglasses, hats, etc. I don't know the "correct way" to do this, so here's what I did:
I constructed a layer to represent the sprite itself, and added the character first, then the hat on top. I have a 5 frame animation for where the hat would be on that characters head ALSO on the sprite sheet, and have it animating with the exact same parameters as the main character.
The problem is that when I try to animate the two sprites simultaneously (the character sprite and the hat sprite), they get out of sync. Sometimes it works great, but sometimes the timing is just a wee bit off, which is enough that his head will go through the top of the hat, or the hat will pop off his head every step.
My current solution is to have an update tick, and manually cycle through the frames every time some number of milliseconds has passed, which works, but I assume since I'm manually setting the frames it's using up more processor time than needed.
So what would be the "correct" way to add a hat to a sprite without having to have a "hatted sprite" series on your sprite sheet, and keep them animating together.
edit: sorry this is tagged badly, I apparently don't have a high enough reputation to tag this "cocos2dx", despite the fact that it's a cocos2dx question.
Well if i have the same situation i will go with taking different spritesheets for different animation according to upgrade of character, that way there will be no need for two different animation pluse u can adjust sprites for best effect and it won't interfare with other animation, only problem is u have to make different sprites according to upgrade.
What kind of animation are you using?
I recommend you to animate using an skeleton. This way is very easy to replace any body-part with different sprites. In TestCpp you have some examples of skeleton animation using CocoStudio (free) or Spine (paid). You even have an example of an animation where weapons are replaced.
If you need to stick to standard frame animation, you need to make sure that both animations start from the same frame when you replace anything. Otherwise, if you replace your hat when you are on a keyframe different from 0, the animation will be out of sync. One solution is to restart both animations. The other is to check the current frame of the body animation and force the hat animation to start on that frame.
OK so what I ended up doing, all the sprites that are assembling a larger character object are put together in a class, together with a float "_lastFrameUpdateTick" and int "_lastFrameNumber". in my update(dt) I have a switch case on _lastFrameNumber for each sprite so it knows if the current time tick is past the _lastFrameUpdateTick + that frame's display time, it should update all the sprites in that class to the next frame number (also allowing me to shift around sprites relative position manually, for cases where, say, a character is bouncing up and down on the back of a horse). This does require me to put copies of any hats repeatedly on the sprite sheet for every animation (though that could probably be faked with plist were one so inclined). This also has the added advantage of allowing certain frames to display slightly longer or shorter than others, allow explicit skipping around in animation sequences depending on events (if there's an earthquake and the character is on a leaned-back part of an animation it falls backwards; if it's on the leaned forward frame of an animation it falls forward), and its easy to halt animations while allowing other stuff to keep running. Most importantly is that doing it manually allows me to always know exactly what frame a sprite is on, so it can smoothly transition between animations without hiccups (I know that if i'm leaned back and want to run forward, i need to go through a leaning-forward animation first).
I'm sure there's a better way to do this, but I'm no C++ developer, and it works, so I'm moving on.
I just started using Cocos2D this week. While playing around with Box2d i was wondering if it was possible to move CCSprites with the help of CCActions and use box2ds collisiion detection feature to detect collision between those sprites..
I'm pretty sure this must be possible?
If you don't need real physics behavior, I'd highly recommend to "manually" deal with your collision logic. That said, for your scenario I would start with this approach.-
Create one body per sprite, and assign each sprite to the user data.
Your 'static' scenario would map to static bodies (i.e floor, platforms, etc...)
Your 'dynamic' sprites would map to dynamic bodies, which only fixture would be marked as sensor
You'd register a b2ContactListener to listen for the collisions.
As for the tricky part, you'd need to set in each iteration of the main loop, the position of each body to the position of each sprite (of course, translating pixels to meters), in order to avoid that they just behave as physics bodies. You could try just to not calling world->step, but not sure if contactListener would work then.
Hope it helps!
I'm using Chrome 24.0.1312.56 (portable version) and 25.0.1364.97 m (installed version) to display some 3D contents. The interation in the 3D scene is not optimal. When I click and move slowly, there is no rotation in the scene. If I move quicker, the interaction starts. It means that I have to interact relatively quickly to mo the 3D scene. This behavior is not seen on firefox 18.0.2.
It looks like there is a minimal movement (or speed movement) under which, the event is thrown away.
The "bug" is worst when the move is in the Y axis of the viewport. Moving in the X axis is better, but not "normal".
Is chrome catching or not propagating some moves to xtk? Is there a threshold for the minimal move or speed?
Thanks,
Laurent.
Yes, I can reproduce if I move the mouse really, really slow..
There is a threshold as defined in here
https://github.com/xtk/X/blob/master/io/interactor.js#L993
The threshold seems reasonable for me. Are you moving really, really slow? We could expose the threshold via a setter.
I'm working on a game where you have to watch out for a ball that bounces around the screen (bounces at the edges of the screen). I am using cocos2d together with chipmunk. In chipmunk I have defined 0 gravity and 0 friction, so that the bouncing ball keeps it's original speed after every bounce.
However, I want to introduce a special type of bouncing ball that gets a temporary speed boost for a couple of seconds and then return to it's original speed.
Is there a nice chipmunk way of doing this, a sort of temporary impulse that one can add? Or do I have to do it the long way manually, by storing the original speed and keeping track of how long (how many cycles) the boosted speed has been running and resetting the original speed at the end of the "boost" period?
Chipmunk doesn't provide timers and such like that, but Cocos2D does.