I want to maintain same speed for a body in LIBGDX. When I run the game in low resolution phone, the character body is moving at a slow rate. Whereas , when I run the game in high resolution mobile, the character is moving at a fast rate. I wanted the speed to be constant no matter what the mobile is.
This is my code,
if (gamehero.heroBody.getLinearVelocity().x > -1.5f) {
Vector2 RUNNER_JUMPING_LINEAR_IMPULSE = new Vector2(1.4f, 0);
gamehero.heroBody.applyLinearImpulse(RUNNER_LEFT_LINEAR_IMPULSE, gamehero.heroBody.getWorldCenter(), true);
}
This is the code I execute when the "right"key control is pressed. To maintain the speed for all resolution, I tried the below code by referrring this SO link
float s = Math.min(Gdx.graphics.getDeltaTime(), 1 / 60f);
gamehero.setPosition(gamehero.heroBody.getPosition().x + 50f*0.5f,0) ;
When I use the above code, the body is not moving at all. Any help would be great. Thanks.
Related
I've some problem for render Box2D Debug with Box2DDebugRenderer.
I've 2 OrthographicCamera, one for render the world (named Cam) and one for the HUD (healthBar, Armor, ...) (named hudCam).
I've tried to render :
b2dr.render(world, cam.combined); -> I can't see the Box2D
b2dr.render(world, cam.projection);
b2dr.render(world, hudCam.combined);
b2dr.render(world, hudCam.projection);
b2dr.render(world, new OrthographicCamera().combined); and b2dr.render(world, new OrthographicCamera().projection)
I can't find a way to render the Box2D exactly like cam, to see the edge of all bodies.
If somebody understand my problem, please help me !
Thx.
Unfortunately some tutorial out there suggest to use a meter-to-pixel-conversion when using Box2D. This is not neccessary (at least with Libgdx), as this conversion can be done by using a camera.
The problem in your case is, that you are using a meter-to-pixel-conversion when rendering the Sprites, while the Box2DDebugRenderer renders everything 1:1.
To solve this problem you have to get rid of the meter-to-pixel conversion and use the camera or the viewport to "scale" the things.
THis way, the Box2DDebugRenderer and your SpriteBatch can (and should) use the same camera to render.
For the camera/viewport:
The constructor has the params width and height. Those params are often set as Gdx.graphics.getWidth() and Gdx.graphics.getHeight(), which in my optinion is not right, the game should be resolution-independent.
You should instead select those values depending on how big your player (or any other visible entity) is in real life and how big it should be on screen.
Let's say you have a little characte, like in your game. It is 1m tall in real live and should take 1/13 of the screen height (more or less like in your first picture, where the screen is about 13 times as high as the character).
So your cameras height should be 13, your characters height (also it's Box2Ds Body height) should be 1m. Next you need to define the width. For that i like to think about my desired aspect ratio. Lets assume the game should focus on 16/9 devices, the width is then (13/9)*16=23.
Now your camera should be created like this:
camera = new OrthographicCamera(23, 13);
Basically my problem is simple - I have a ParticleEffect which looks nice on small screen but on my private phone (Samsung S4) it looks very small. My question is: How can I scale the effect?
I have already done something like this:
// Callback method
public void addEffect(Vector2 position, boolean special) {
// Callback Method for the particle effects
PooledEffect effect;
if (!special)
effect = (MathUtils.random(0, 1) == 0) ? yellow_star_pool.obtain()
: green_star_pool.obtain();
else
effect = special_star_pool.obtain();
effect.setPosition(position.x, position.y);
effect.scaleEffect(Values.Scalar_Width*1.3f);
effects.add(effect);
}
But the result is that the effect is scaling exponentially, something I don't want.
I just want the effect to be scaled so that it will look the same on all screens. How can I achieve that?
First, I want to explain why current approach doesn't work. Note that the method you use for scaling is named scaleEffect, not setScale. Every time you call it the effect will be scaled relative to its current state. When you use pooled particle effects you scale the effect as many times as the particle had been reused. That's why you see it scaling exponentially.
So, the solution is to scale only the particle effect that you use as a prototype for the pool. Something like:
prototypeEffect.scaleEffect(Values.Scalar_Width * 1.3f);
ParticleEffectPool yellow_star_pool = new ParticleEffectPool(prototypeEffect, 10, 100);
Then you didn't have to scale every particle effect you obtain.
I'm developing a top-down view game, and I've got a problem with the camera.
Currently camera simply follows the player entity - it seems fine to me, but people want another camera.
I'm using Starling, and StarlingPunk, but it shouldn't make much difference, its more theoretical question.
Camera works like this:
public function centerOnEntity(target:SPEntity):void
{
var newCameraX:Number = (target.x + target.width / 2) - SP.width / 2;
var newCameraY:Number = (target.y + target.height / 2) - SP.height / 2;
SP.camera.setPosition(newCameraX, newCameraY);
}
And basically, every frame, camera is centered on the user.
Following image will demonstrate the problem:
As you can see, I've got rectangular levels, and if level is small, or user is near to the level bounds a background image is displayed.
So, what kind of camera do I need?
I need a camera, that will show maximum level space, and minimum background image.
How can I achieve that?
Help would be appreciated!
i'm trying to implement kinetic scrolling of a list object, but i'm having a problem determining the amount of friction (duration) to apply based on the velocity.
my applyFriction() method evenly reduces the velocity of the scrolling object based on a duration property. however, using the same duration (IE: 1 second) for every motion doesn't appear natural.
for motions with a small amount of velocity (IE: 5 - 10 pixels) a 1 second duration appears fine, but applying friction over a 1 second duration for motions with lots of velocity (IE: 100+ pixels) the scrolling object will appear to slow and stop much faster.
essentially, i'm trying to determine the appropriate duration for each motion so that both small and large amounts of velocity will share a matching friction, so the moving object will appear to always have a constant "weight".
is there a general algorithm for determining the duration of kinetic movement based on different velocities?
note: i'm programming in ActionScript 3.0 and employing the Tween class to reduce the velocity of a moving object over a duration.
A better model for friction is that the frictional force is proportional to velocity. You'll need a constant to determine the relationship between force and acceleration (mass, more or less). Writing the relationships as a difference equation,
F[n] = -gamma * v[n-1]
a[n] = F[n]/m
v[n] = v[n-1] + dt * a[n]
= v[n-1] + dt * F[n] / m
= v[n-1] - dt * gamma * v[n-1] / m
= v[n-1] * (1 - dt*gamma/m)
So, if you want your deceleration to look smooth and natural, instead of linearly decreasing your velocity you want to pick some constant slightly less than 1 and repeatedly multiply the velocity by this constant. Of course, this only asymptotically approaches zero, so you probably want to have a threshold below which you just set velocity to zero.
So, for example:
v_epsilon = <some minimum velocity>;
k_frict = 0.9; // play around with this a bit
while (v > v_epsilon) {
v = v * k_frict;
usleep(1000);
}
v = 0;
I think you'll find this looks much more natural.
If you want to approximate this with a linear speed reduction, then you'll want to make the amount of time you spend slowing down proportional to the natural log of the initial velocity. This won't look quite right, but it'll look somewhat better than what you've got now.
(Why natural log? Because frictional force proportional to velocity sets up a first-order differential equation, which gives an exp(-t/tau) kind of response, where tau is a characteristic of the system. The time to decay from an arbitrary velocity to a given limit is proportional to ln(v_init) in a system like this.)
i had looked into this problem before: why does Android momentum scrolling not feel as nice as the iPhone?
Fortunately, a guy already got out a video camera, recorded an iPhone scrolling, and figured out what it does: archive
flick list with its momentum scrolling and deceleration
When I started to work [on this], I did not pay attention carefully to the way the scrolling works on iPhone. I was just assuming that the deceleration is based on Newton’s law of motion, i.e. a moving body receiving a friction which is forced to stop after a while. After a while, I realized that this is actually not how iPhone (and later iOS devices such as iPad) does it. Using a camera and capturing few dozens scrolling movement of various iOS applications, it came to me that all the scrolling will stop after the same amount of time, regardless the size of the list or the speed of the flick. How fast you flick (which determines the initial velocity of the scrolling) only determines where the list would stop and not when.
This lead him to the greatly simplified math:
amplitude = initialVelocity * scaleFactor;
step = 0;
ticker = setInterval(function() {
var delta = amplitude / timeConstant;
position += delta;
amplitude -= delta;
step += 1;
if (step > 6 * timeConstant) {
clearInterval(ticker);
}
}, updateInterval);
In fact, this is how the deceleration is implemented in Apple’s own PastryKit library (and now part of iAd). It reduces the scrolling speed by a factor of 0.95 for each animation tick (16.7 msec, targeting 60 fps). This corresponds to a time constant of 325 msec. If you are a math geek, then obviously you realize that the exponential nature of the scroll velocity will yield the exponential decay in the position. With a little bit of scriblling, eventually you find out that
325 = -16.7ms / ln(0.95)
Giving the motion:
Your question was about the duration to use. i like how the iPhone feels (as opposed to Android). i think you should use 1,950 ms:
- (1000 ms / 60) / ln(0.95) * 6 = 1950 ms
I'm trying to play an FLV using the Netstream class - standard stuff, really using nothing more complex than things you can find in the help files. I've created a control panel with a bar you can use to click and drag and scrub through the video.
Exporting to Flash Player 9, it's working fine and I can scrub through the video, but only while the FLV is still loading. As soon as it hits 100% the scrubbing (using Netstream.seek()) becomes incredibly unresponsive, almost to the point of crashing the player.
I've killed all ENTER_FRAMES, removed all unnecessary listeners and nullified everything I can think of but something massively resource-intensive seems to be kicking in as soon as the load finishes.
Has anyone ever seen this? I've never come across this and can't find anything similar across assorted forums.
Code below but I don't think the mouse-move drag actions are the problem! Fine in the Flash CS4 IDE, broken in the browser.
Thanks for any help you might be able to provide,
Gareth
// Drag
private function dragVideo(e:MouseEvent):void {
// Match the x position of the dragger to the x position of the mouse
videoControls.progressBar.dragger.x = videoControls.progressBar.barInner.mouseX;
// If this results in the dragger moving outside the dragging area, constrain it
if (videoControls.progressBar.dragger.x < videoProgressRectangle.left) {
videoControls.progressBar.dragger.x = videoProgressRectangle.left;
} else if (videoControls.progressBar.dragger.x > videoProgressRectangle.right) {
videoControls.progressBar.dragger.x = videoProgressRectangle.right;
}
// As the dragger moves, work out its position as a percentage of the total distance it CAN move
// That distance is the width of the black inner bar but you must also accomodate the centred registration point of the dragger
// So knock off half the dragger's width from it's current position (which gives the left edge of the inner bar)
// Then knock off the dragger's width minus the 2px overhang of the white progress bar border, from the total draggable distance
videoSeekPercentageMouse = (videoControls.progressBar.dragger.x - (videoControls.progressBar.dragger.width / 2)) / (videoControls.progressBar.barInner.width - (videoControls.progressBar.dragger.width - 2));
// Now use that percentage to seek the video to the equivalent percentage of its total time
if (videoSeekPercentageMouse <= 0) {
videoNetStream.seek(0);
} else if (videoSeekPercentageMouse >= 1) {
// Because video metaData says the length is xyz while the real length is xyz + 0.015,
// seek to slightly before the end
videoNetStream.seek(videoDuration - 0.016);
} else {
videoNetStream.seek(videoDuration * videoSeekPercentageMouse);
}
// Show the video's current progress
videoControls.progressBar.barProgress.scaleX = videoSeekPercentageMouse;
// After the mouse moves update the display
e.updateAfterEvent();
}
Got it!
You should try this..
Pause the streaming "before" seeking..
Seek()
And then resume the streaming!