I'm trying to make a first person shooter style camera for my project. Everything looks smooth if I'm moving forward or back, strafing left or right, or going diagonal... The problem is when I look around with the mouse while moving, the movements get really jittery. It is most prominent when I am strafing and turning with the mouse at the same time.
I'm convinced my problem is similar to this: http://en.sfml-dev.org/forums/index.php?topic=4833.msg31550#msg31550 , however I am using Gentoo Linux, not OSX.
It's quite likely that it's not SFML's fault though, and that I did something wrong, so I would like to get some feedback on my event handling code to see if there's a better way to get smooth mouse movements.
In case you don't want to read through the link I posted, the short of what I think is happening is the mouse movement velocity is being lost every frame when I set the mouse's position back to the center of the screen, which causes a quick visible jerk on screen. This is my going theory as I've tried changing other stuff around for 3 days now and nothing I do makes it less jerky. So I would like to know if anyone has a better way of handling the mouse movements, or whether you think the problem lies elsewhere.
An important note is I have enabled vsync which made a lot of other jitteriness and tearing go away, and I tried using a hard framerate limit like sf::Window::setFramerateLimit(60), but that didn't help at all.
Here is the event handler (which uses the SFML 2.0 realtime interfaces instead of an event loop), you can probably ignore the part related to jumping:
void Test_World::handle_events(float& time)
{
// camera stuff
_mouse_x_pos = sf::Mouse::getPosition(*_window).x;
_mouse_y_pos = sf::Mouse::getPosition(*_window).y;
std::cout << "mouse x: " << _mouse_x_pos << std::endl;
std::cout << "mouse y: " << _mouse_y_pos << std::endl;
_horizontal_angle += time * _mouse_speed * float(_resolution_width/2 - _mouse_x_pos);
_vertical_angle += time * _mouse_speed * float(_resolution_height/2 - _mouse_y_pos);
// clamp rotation angle between 0 - 2*PI
if (_horizontal_angle > 3.14f*2) _horizontal_angle = 0;
if (_horizontal_angle < 0) _horizontal_angle = 3.14f*2;
// clamp camera up/down values so we can't go upside down
if (_vertical_angle >= 3.14f/2.0f) _vertical_angle = 3.14f/2.0f;
if (_vertical_angle <= -3.14f/2.0f) _vertical_angle = -3.14f/2.0f;
std::cout << "horiz angle: " << _horizontal_angle << std::endl;
std::cout << "vert angle: " << _vertical_angle << std::endl;
_direction = glm::vec3( cos(_vertical_angle) * sin(_horizontal_angle),
sin(_vertical_angle),
cos(_vertical_angle) * cos(_horizontal_angle) );
_right = glm::vec3( sin(_horizontal_angle - 3.14f/2.0f),
0,
cos(_horizontal_angle - 3.14f/2.0f) );
_up = glm::cross( _right, _direction );
// keyboard: left, right, up, down
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Left) || sf::Keyboard::isKeyPressed(sf::Keyboard::A))
{
if (_jumping)
{
_position -= _right * time * _speed * ((_jump_speed/2) + 0.1f);
}
else
{
_position -= _right * time * _speed;
}
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Right) || sf::Keyboard::isKeyPressed(sf::Keyboard::D))
{
if (_jumping)
{
_position += _right * time * _speed * ((_jump_speed/2) + 0.1f);
}
else
{
_position += _right * time * _speed;
}
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Up) || sf::Keyboard::isKeyPressed(sf::Keyboard::W))
{
glm::vec3 old_direction(_direction);
_direction.y = 0;
if (_jumping)
{
_position += _direction * time * _speed * ((_jump_speed/2) + 0.1f);
}
else
{
_position += _direction * time * _speed;
}
_direction = old_direction;
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Down) || sf::Keyboard::isKeyPressed(sf::Keyboard::S))
{
glm::vec3 old_direction(_direction);
_direction.y = 0;
if (_jumping)
_position -= _direction * time * _speed * ((_jump_speed/2) + 0.1f);
else
_position -= _direction * time * _speed;
_direction = old_direction;
}
// keyboard: jump
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Space) || sf::Keyboard::isKeyPressed(sf::Keyboard::RControl))
{
// check if standing on something
if (_standing)
{
_standing = false;
_jumping = true;
}
}
// apply gravity if off the ground
if (_position.y > _main_character_height && !_jumping)
_position.y -= time * _speed * _global_gravity;
// if started jumping
else if (_position.y < _main_character_height + _jump_height - 3.0f && _jumping)
{
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Space) || sf::Keyboard::isKeyPressed(sf::Keyboard::RControl))
{
_position.y += time * _speed * _jump_speed;
}
else // if stopped jumping
{
_position += _direction * time * (_speed/(_jump_hang_time*2));
_jumping = false;
}
}
// if near the highest part of the jump
else if (_position.y <= _main_character_height + _jump_height && _jumping)
{
if (sf::Keyboard::isKeyPressed(sf::Keyboard::Space) || sf::Keyboard::isKeyPressed(sf::Keyboard::RControl))
{
_position.y += time * _speed * (_jump_speed/_jump_hang_time);
}
else // if stopped jumping
{
_position += _direction * time * (_speed/(_jump_hang_time*2));
_jumping = false;
}
}
// if reached the highest part of the jump
else if (_position.y >= _main_character_height + _jump_height)
{
_position += _direction * time * (_speed/_jump_hang_time);
_jumping = false;
}
else if (_position.y <= _main_character_height)
{
_standing = true;
}
sf::Mouse::setPosition(_middle_of_window, *_window);
}
After the events, I am changing my _view_matrix like this:
_view_matrix = glm::lookAt( _position, _position+_direction, _up );
Then, I recalculate my _modelview_matrix and _modelviewprojection_matrix:
_modelview_matrix = _view_matrix * _model_matrix;
_modelviewprojection_matrix = _projection_matrix * _modelview_matrix;
After that I finally send the matrices to my shaders and draw the scene.
I am open to any sage wisdom/advice with regards to OpenGL3, SFML 2.0, and/or FPS-style camera handling, and please let me know if it would help to include more code (if you think the problem isn't in the event handling, for example). Thanks in advance for the help!
Edit: I still haven't solved this problem, and FYI it doesn't look like the framerate is dropping at all during the shaky movements...
If I was you I would hide the mouse using this tutorial and then only move the mouseposition when it got to the edge of the screen moving it to the opposite side so it can continue in that direction un-impeded. May not be the best solution, but I'm pretty sure it'll fix your issue.
... another idea is to do some remembering and reckoning as to what they are doing and not use the position data itself, but simply use the position data to guide the reckoning (i.e. use physics to control it instead of the raw data).
Just my thoughts, hope they help^^
Related
notes:
room1Collisions is a 1D array containing 1s and 0s representing collidable tiles.
+/- 0.1 is used so that the player can still move when against a collidable tile.
size is an SFML vector that holds the width and height of the player.
I understand that this code is not in great shape, but I'm trying to get collisions working to then refactor.
The issue (described below) occurs more frequently when the player collides diagonally
code:
void Player::Update(float dt) {
// 0 is a collidable tile
// change room1Collisions to a pointer of current level
if (sf::Keyboard::isKeyPressed(sf::Keyboard::A))
{
// a is top left and b is bottom left
sf::Vector2u a(position.x/tileSize.x, (position.y+size.y/2)/tileSize.y);
sf::Vector2u b(position.x/tileSize.x, (position.y+size.y-0.1)/tileSize.y);
int tileNumberA = room1Collisions[(a.x) + a.y*(tilemapBounds.x/tileSize.x)];
int tileNumberB = room1Collisions[(b.x) + b.y*(tilemapBounds.x/tileSize.x)];
if (tileNumberA != 0 && tileNumberB != 0 && position.x >= 0) {
position.x -= speed * dt;
//animation.resumeAnimation();
}
direction = LEFT;
//animation.resumeAnimation();
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::D))
{
sf::Vector2u a((position.x+size.x)/tileSize.x, (position.y+size.y/2)/tileSize.y);
sf::Vector2u b((position.x+size.x)/tileSize.x, (position.y+size.y-0.1)/tileSize.y);
int tileNumberA = room1Collisions[(a.x) + a.y*(tilemapBounds.x/tileSize.x)];
int tileNumberB = room1Collisions[(b.x) + b.y*(tilemapBounds.x/tileSize.x)];
if (tileNumberA != 0 && tileNumberB != 0 && position.x+size.x <= tilemapBounds.x) {
position.x += speed * dt;
//animation.resumeAnimation();
}
direction = RIGHT;
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::W))
{
sf::Vector2u a((position.x+0.1)/tileSize.x, (position.y+(size.y/3))/tileSize.y);
sf::Vector2u b((position.x+size.x-0.1)/tileSize.x, (position.y+(size.y/3))/tileSize.y);
int tileNumberA = room1Collisions[(a.x) + a.y*(tilemapBounds.x/tileSize.x)];
int tileNumberB = room1Collisions[(b.x) + b.y*(tilemapBounds.x/tileSize.x)];
if (tileNumberA != 0 && tileNumberB != 0 && position.y >= 0) {
position.y -= speed * dt;
//animation.resumeAnimation();
}
direction = UP;
//animation.resumeAnimation();
}
if (sf::Keyboard::isKeyPressed(sf::Keyboard::S))
{
sf::Vector2u a((position.x+0.1)/tileSize.x, (position.y+size.y)/tileSize.y);
sf::Vector2u b((position.x+size.x-0.1)/tileSize.x, (position.y+size.y)/tileSize.y);
int tileNumberA = room1Collisions[(a.x) + a.y*(tilemapBounds.x/tileSize.x)];
int tileNumberB = room1Collisions[(b.x) + b.y*(tilemapBounds.x/tileSize.x)];
if (tileNumberA != 0 && tileNumberB != 0 && position.y+size.y <= tilemapBounds.y) {
position.y += speed * dt;
//animation.resumeAnimation();
}
direction = DOWN;
}
//animation.setAnimation(direction);
//animation.Update(dt, 0.2f);
//animation.setPosition(position);
box.setPosition(position);
}
The problem is that when the game is run on slower computers, sometimes the player will skip (?) a collision check and it becomes stuck in a collidable tile, preventing it from moving orthogonally with respect to the collidable tile. On faster computers this issue is not present unless the player speed (currently 30) is increased significantly.
Below is an image showing the player inside a collidable tile. Please note that in this example the player is not able to move left/right since those directions are perpendicular to the collidable tile, but can still move up.
What you need is to regulate the FPS so that it is consistent for all computers.
Frame rate regulation example(This uses the SDL2 library for SDL_GetTicks and SDL_Delay but there are probably alternatives to that depending on your graphics library):
const int FPS = 60;
const int frameDelay = 1000/FPS;
Uint32 frameStart;
int frameTime;
//Main game loop
while (true)
{
//Gets the amount of milliseconds elapsed since the program was first run
frameStart = SDL_GetTicks();
//YOUR MAIN GAME LOOP HERE
//Gets the amount of milliseconds that it took to run the game loop
frameTime = SDL_GetTicks() - frameStart;
//Checks if the game loop was run faster than the max frame time
if(frameDelay > frameTime)
{
//Delays the game loop so that it takes that the frame time always is the same
SDL_Delay(frameDelay - frameTime);
}
}
(Keep in mind that this is just an example there are lots of ways to regulate the FPS)
After implementing FPS regulation you might need to tweak the speed and collision sensitivity a little but once you have it it should be consistent on ALL computers
I want to implement a conventional FPS control. By pressing the spacebar the camera moves upward and then comes down back on the grid, simulating the jumping action. Right now, I am only able to move the camera upward for a distance but I don't know how to let the camera come down.
This is my camera class:
Camera::Camera(glm::vec3 cameraPosition, glm::vec3 cameraFront, glm::vec3 cameraUp){
position = glm::vec3(cameraPosition);
front = glm::vec3(cameraFront);
up = glm::vec3(cameraUp);
// Set to predefined defaults
yawAngle = -90.0f;
pitchAngle = 0.0f;
fieldOfViewAngle = 45.0f;
}
Camera::~Camera() {}
void Camera::panCamera(float yaw){
yawAngle += yaw;
updateCamera();}
void Camera::tiltCamera(float pitch){
pitchAngle += pitch;
// Ensure pitch is inbounds for both + and - values to prevent irregular behavior
pitchAngle > 89.0f ? pitchAngle = 89.0f : NULL;
pitchAngle < -89.0f ? pitchAngle = -89.0f : NULL;
updateCamera();}
void Camera::zoomCamera(float zoom){
if (fieldOfViewAngle >= MIN_ZOOM && fieldOfViewAngle <= MAX_ZOOM){
fieldOfViewAngle -= zoom * 0.1;}
// Limit zoom values to prevent irregular behavior
fieldOfViewAngle <= MIN_ZOOM ? fieldOfViewAngle = MIN_ZOOM : NULL;
fieldOfViewAngle >= MAX_ZOOM ? fieldOfViewAngle = MAX_ZOOM : NULL;}
glm::mat4 Camera::calculateViewMatrix(){
return glm::lookAt(position, position + front, up);}
void Camera::updateCamera(){
front.x = cos(glm::radians(yawAngle)) * cos(glm::radians(pitchAngle));
front.y = sin(glm::radians(pitchAngle));
front.z = sin(glm::radians(yawAngle)) * cos(glm::radians(pitchAngle));
front = glm::normalize(front);}
void Camera::moveForward(float speed){
position += speed * front;}
void Camera::moveBackward(float speed){
position -= speed * front;}
void Camera::moveLeft(float speed){
position -= glm::normalize(glm::cross(front, up)) * speed;}
void Camera::moveRight(float speed){
position += glm::normalize(glm::cross(front, up)) * speed;}
void Camera::moveUpward(float speed){
position.y += speed;}
This is how I implement it in main.cpp:
if (glfwGetKey(window, GLFW_KEY_SPACE) == GLFW_PRESS)
{
camera.moveUpward(cameraSpeed);
}
Can someone help me?
You can simulate a jump by applying an acceleration to the y-position. You'll need to add 3 new attributes to your struct: acceleration (vec3), velocity (vec3), and onGround (boolean).
void Camera::jump() {
// Apply a upwards acceleration of 10 units. You can experiment with
// this value or make it physically correct and calculate the
// best value, but this requires the rest of your program to
// be in well-defined units.
this->onGround = false;
this->acceleration.y = 10.0f;
}
void Camera::update() {
// Your other update code
// The acceleration should decrease with gravity.
// Eventually it'll become negative.
this->acceleration.y += GRAVITY; // Define 'GRAVITY' to a negative constant.
// Only update if we're not on the ground.
if (!this->onGround) {
// Add the acceleration to the velocity and the velocity to
// the position.
this->velocity.y += this->acceleration.y
this->position.y += this->velocity.y;
if (this->position.y <= 0) {
// When you're on the ground, reset the variables.
this->onGround = true;
this->acceleration.y = 0;
this->velocity.y = 0;
this->position.y = 0;
}
}
}
And in your event handling you'll call the jump method.
if (glfwGetKey(window, GLFW_KEY_SPACE) == GLFW_PRESS)
{
camera.jump();
}
However, this code probably shouldn't be on the camera, but instead on a Physics object of some sort. But it'll work.
I am using a custom game engine created by one of my lecturers.
I have 4 inputs that the user can have for a pong game. These inputs work as intended however as soon as the sprite (paddle for pong) touches either the top or the bottom they get stuck there and are unable to move. Adding an else statement saying w_keypress = false; doesn't work.
if (w_keypress)
{
if (player_one->yPos() >= 0 && player_one->yPos() + player_one->height() <= game_height)
{
yspeed_player_one = -500;
s_keypress = false;
y_pos_player_one += yspeed_player_one * (game_time.delta.count() / 1000.f);
player_one->yPos(y_pos_player_one);
std::cout << "keypress w" << std::endl;
}
}
EDIT: The problem can easily be fixed by setting the y value to a y value that doesn't make the sprite interfere with the top or the bottom of the screen.
e.g.
if (player_one-yPos() > game_height)
{
player_one->yPos(game_height - (player_one->height() / 2)
}
else if (player_one->yPos() < 0)
{
player_one->yPos(0 + (player_one->height() / 2)
}
This code detects if the player has gone off the top or the bottom of the screen and then moves the player half of its height down or up depending on which y value you are.
Let's take a closer look at
if (player_one->yPos() >= 0 && player_one->yPos() + player_one->height() <= game_height)
{
yspeed_player_one = -500;
s_keypress = false;
y_pos_player_one += yspeed_player_one * (game_time.delta.count() / 1000.f);
player_one->yPos(y_pos_player_one);
}
bounds check position. If in bounds,
Update position by adding current velocity
Else
Do nothing
The problem is step 1.1 is too naive. If your sprite is zipping along toward a wall at sufficient speed, it can enter or completely pass through the wall as soon as you update its position. The next test of the bounds will trap the sprite because it is out of bounds.
Eg: Sprite is at 1000. Its height is 50 and its velocity per tick is 50. The wall is at 1080.
Step 1 tests 1000 + 50 <= 1080. This is true, so step 1.1 updates the position: 1000 + 50 = 1050. The sprite now occupies 1050 to 1099 and is inside the wall.
On the next button press, Step 1 tests 1050 + 50 <= 1080. This is false, so 2.1 is executed and the sprite does not move.
The test for collision with the wall is effectively performed after the sprite's gone out of bounds and by then it is too late.
You want a function that does something like
TYPE clamp_move(TYPE max_move,
TYPE distance_to_wall)
{
if (max_move < distance_to_wall)
{
max_move = distance_to_wall;
}
return max_move;
}
to prevent over shooting the bounds. Note this is pretty much std::min, so use std::min.
You wind up with
deltapos = std::min(yspeed_player_one * (game_time.delta.count() / 1000.f),
player_one->yPos());
y_pos_player_one -= deltapos;
or
deltapos = std::min(yspeed_player_one * (game_time.delta.count() / 1000.f),
game_height - (player_one->yPos() + player_one->height()));
y_pos_player_one += deltapos;
depending on which way the sprite is moving. Or by catching the overshoot and clamping before the next test.
y_pos_player_one += yspeed_player_one * (game_time.delta.count() / 1000.f);
if (y_pos_player_one <0)
{
y_pos_player_one = 0;
}
else if (y_pos_player_one > game_height - player_one->height())
{
y_pos_player_one = game_height - player_one->height();
}
whichever is easier on your brain.
I am trying to implement a basic AI for a Turrets game in SFML and C++ and I have some problems.
This AI follows some waypoints stablished in a Bezier Courve.
In first place, this path was followed only by one enemy. For this purpose, the enemy has to calculate his distance between his actual position
to the next waypoint he has to pick.
If the distance is less than a specific value we stablish, then, we get to the next point. This will repeat until the final destination is reached. (in the submitting code, forget about the var m_go)
Okay, our problem gets when we spawn several enemies and all have to follow the same path, because it produces a bad visual effect (everyone gets upside another).
In order to solve this visual problem, we have decided to use a repulsion vector. The calculus gets like this: representation of what we want
As you can see, we calculate the repulsion vector with the inverse of the distance between the enemy and his nearest neighbor.
Then, we get it applying this to the "theorical" direction, by adding it, and we get a resultant, which is the direction that
our enemy has to follow to not "collide" with it's neighbors.
But, our issue comes here:
The enemys get sepparated in the middle of the curve and, as we spawn more enemys, the speed of all of them increases dramatically (including the enemies that don't calculate the repuslion vector).
1 - Is it usual that this sepparation occours in the middle of the trajectory?
2 - Is it there a way to control this direction without the speed getting affected?
3 - Is it there any alternative to this theory?
I submit the code below (There is a variable in Spanish [resultante] which it means resultant in English):
if (!m_pathCompleted) {
if (m_currentWP == 14 && m_cambio == true) {
m_currentWP = 0;
m_path = m_pathA;
m_cambio = false;
}
if (m_neighbors.size() > 1) {
for (int i = 0; i < m_neighbors.size(); i++) {
if (m_enemyId != m_neighbors[i]->GetId()) {
float l_nvx = m_neighbors[i]->GetSprite().getPosition().x - m_enemySprite.getPosition().x;
float l_nvy = m_neighbors[i]->GetSprite().getPosition().y - m_enemySprite.getPosition().y;
float distance = std::sqrt(l_nvx * l_nvx + l_nvy * l_nvy);
if (distance < MINIMUM_NEIGHBOR_DISTANCE) {
l_nvx *= -1;
l_nvy *= -1;
float l_vx = m_path[m_currentWP].x - m_enemySprite.getPosition().x;
float l_vy = m_path[m_currentWP].y - m_enemySprite.getPosition().y;
float l_resultanteX = l_nvx + l_vx;
float l_resultanteY = l_nvy + l_vy;
float l_waypointDistance = std::sqrt(l_resultanteX * l_resultanteX + l_resultanteY * l_resultanteY);
if (l_waypointDistance < MINIMUM_WAYPOINT_DISTANCE) {
if (m_currentWP == m_path.size() - 1) {
std::cout << "\n";
std::cout << "[GAME OVER]" << std::endl;
m_go = false;
m_pathCompleted = true;
} else {
m_currentWP++;
}
}
if (l_waypointDistance > MINIMUM_WAYPOINT_DISTANCE) {
l_resultanteX = l_resultanteX / l_waypointDistance;
l_resultanteY = l_resultanteY / l_waypointDistance;
m_enemySprite.move(ENEMY_SPEED * l_resultanteX * dt, ENEMY_SPEED * l_resultanteY * dt);
}
} else {
float vx = m_path[m_currentWP].x - m_enemySprite.getPosition().x;
float vy = m_path[m_currentWP].y - m_enemySprite.getPosition().y;
float len = std::sqrt(vx * vx + vy * vy);
if (len < MINIMUM_WAYPOINT_DISTANCE) {
if (m_currentWP == m_path.size() - 1) {
std::cout << "\n";
std::cout << "[GAME OVER]" << std::endl;
m_go = false;
m_pathCompleted = true;
} else {
m_currentWP++;
}
}
if (len > MINIMUM_WAYPOINT_DISTANCE) {
vx = vx / len;
vy = vy / len;
m_enemySprite.move(ENEMY_SPEED * vx * dt, ENEMY_SPEED * vy * dt);
}
}
}
}
} else {
float vx = m_path[m_currentWP].x - m_enemySprite.getPosition().x;
float vy = m_path[m_currentWP].y - m_enemySprite.getPosition().y;
float len = std::sqrt(vx * vx + vy * vy);
if (len < MINIMUM_WAYPOINT_DISTANCE) {
if (m_currentWP == m_path.size() - 1) {
std::cout << "\n";
std::cout << "[GAME OVER]" << std::endl;
m_go = false;
m_pathCompleted = true;
} else {
m_currentWP++;
}
}
if (len > MINIMUM_WAYPOINT_DISTANCE) {
vx = vx / len;
vy = vy / len;
m_enemySprite.move(ENEMY_SPEED * vx * dt, ENEMY_SPEED * vy * dt);
}
}
}
I will try to answer your questions one by one, but first, I don't see anything terribly wrong in the code, so it could be simply a set of non contemplated situations.
1 - Is it usual that this sepparation occours in the middle of the
trajectory?
Well, you're applying repulsion forces to every enemy based on distance of near enough others. If something weird happens or if you're moving them more than necessary, could result on a considerable deviation from their original trajectory.
2 - Is it there a way to control this direction without the speed
getting affected?
In this line
m_enemySprite.move(ENEMY_SPEED * l_resultanteX * dt, ENEMY_SPEED * l_resultanteY * dt);
we see you're, in fact, applying that repulsion force based on l_resultante vector. That vector depends directly on l_nv (repulsion vector), which its module (or length) is proportional to the distance between this (enemy you are processing now) and other (the neighbor). As you're multiplying this vector by the speed of the enemy (a constant value), greater the distance, greater the force applied and more separation will be between them.
I suggest you to:
Normalize the vector l_nv (Easier): This is, force it to have module 1. With this solution every enemy will be pushed with the same force (basically ENEMY_SPEED) but in proper direction.
Inverse the vector l_nv (Little harder): If you apply this vector inversely proportional to the distance (module = 1/distance), they will behave the opposite and they will be pushed less if they are farther from each other.
Also consider that you are applying forces consecutively and you're making them effective by every neighbor processed. This implies something undesirable. If you push an enemy, this force could move it into a location where a future enemy (in the for loop) could push it maybe more than before. If this effect concatenates several times, could trigger a chain reaction where your enemy is pushed more and more. This effect will be amplified if you're applying the forces proportional to the distance.
3 - Is it there any alternative to this theory?
I actually run out of ideas, but I left this space here if someone want to edit the answer and suggest something
I'm coding a simple roguelike game in C++ using SDL library, and I have some problems moving my character on the screen. Each time a frame needs to be rendered, I update the position of the sprite using the update() function, which does nothing if the player is standing still. To issue the movement command, and thus starting the animation, I use the step() function called only once per each player movement from one tile to another. Upon receiving the "up" command, the game behaves fine and the character moves smoothly in one second to the new position. However, when the "down" command is given, he moves at about half the speed, and obviously after one second has passed, he is instantly "teleported" to the final position, with a sudden flicker. The code for the movement is basically identical, but for the fact that in one case the delta movement is summed to the y position, in the other case is subtracted. Maybe the fact that the position is an integer and the delta is a double is causing problems? Does sum and subract behave differently (maybe different rounding)? Here is the relevant code (sorry for the length):
void Player::step(Player::Direction dir)
{
if(m_status != STANDING) // no animation while standing
return;
switch(dir)
{
case UP:
if(m_currMap->tileAt(m_xPos, m_yPos - m_currMap->tileHeight())->m_type == Tile::FLOOR)
{
// if next tile is not a wall, set up animation
m_status = WALKING_UP;
m_yDelta = m_currMap->tileHeight(); // sprite have to move by a tile
m_yVel = m_currMap->tileHeight() / 1000.0f; // in one second
m_yNext = m_yPos - m_currMap->tileHeight(); // store final destination
}
break;
case DOWN:
if(m_currMap->tileAt(m_xPos, m_yPos + m_currMap->tileHeight())->m_type == Tile::FLOOR)
{
m_status = WALKING_DOWN;
m_yDelta = m_currMap->tileHeight();
m_yVel = m_currMap->tileHeight() / 1000.0f;
m_yNext = m_yPos + m_currMap->tileHeight();
}
break;
//...
default:
break;
}
m_animTimer = SDL_GetTicks();
}
void Player::update()
{
m_animTimer = SDL_GetTicks() - m_animTimer; // get the ms passed since last update
switch(m_status)
{
case WALKING_UP:
m_yPos -= m_yVel * m_animTimer; // update position
m_yDelta -= m_yVel * m_animTimer; // update the remaining space
break;
case WALKING_DOWN:
m_yPos += m_yVel * m_animTimer;
m_yDelta -= m_yVel * m_animTimer;
break;
//...
default:
break;
}
if(m_xDelta <= 0 && m_yDelta <= 0) // if i'm done moving
{
m_xPos = m_xNext; // adjust position
m_yPos = m_yNext;
m_status = STANDING; // and stop
}
else
m_animTimer = SDL_GetTicks(); // else update timer
}
EDIT: I removed some variables and only left the elapsed time, the speed and the final position. Now it moves without flickering, but the down and right movements are visibly slower than the up and left ones. Still wonder why...
EDIT 2: Ok, I figured out why this is happening. As I supposed in the first place, there is a different rounding from double to integer when it comes to sum and subtraction. If I perform a cast like this:
m_xPos += (int)(m_xVel * m_animTimer);
the animation speed is the same, and the problem is solved.
Consider the following:
#include <iostream>
void main()
{
int a = 1, b = 1;
a += 0.1f;
b -= 0.1f;
std::cout << a << std::endl;
std::cout << b << std::endl;
}
During the implicit conversion of float to int when a and b are assigned, everything past the decimal point will be truncated and not rounded. The result of this program is:
1
0
You've said that m_yPos is an integer and m_yVel is a double. Consider what happens in Player::update if the result of m_yVel * m_animTimer is less than 1. In the UP case, the result will be that your sprite moves down one pixel, but in the DOWN case, your sprite won't move at all, because if you add less than one to an integer, nothing will happen. Try storing your positions as doubles and only converting them to integers when you need to pass them to the drawing functions.
A trick you can do to ensure rounding instead of truncation during conversion is to always add 0.5 to the floating point value during assignment to an integer.
For example:
double d1 = 1.2;
double d2 = 1.6;
int x = d1 + 0.5;
int y = d2 + 0.5;
In this case, x will become 1, while y will become 2.
I'd rather not do incremental calculations. This is simpler, will give correct results even if you go back in time, doesn't suffer from lost of precision, and will be just as fast, if not faster, on modern hardware:
void Player::step(Player::Direction dir)
{
// ...
case UP:
if(m_currMap->tileAt(m_xPos, m_yPos - m_currMap->tileHeight())->m_type == Tile::FLOOR)
{
// if next tile is not a wall, set up animation
m_status = WALKING_UP;
m_yStart = m_yPos;
m_yDelta = -m_currMap->tileHeight(); // sprite have to move by a tile
m_tStart = SDL_GetTicks(); // Started now
m_tDelta = 1000.0f; // in one second
}
break;
case DOWN:
if(m_currMap->tileAt(m_xPos, m_yPos + m_currMap->tileHeight())->m_type == Tile::FLOOR)
{
m_status = WALKING_DOWN;
m_yStart = m_yPos;
m_yDelta = m_currMap->tileHeight();
m_tStart = SDL_GetTicks(); // Started now
m_tDelta = 1000.0f; // in one second
}
break;
// ...
}
void Player::update()
{
auto tDelta = SDL_GetTicks() - m_tStart;
switch(m_status)
{
case WALKING_UP:
case WALKING_DOWN:
m_yPos = m_yStart + m_yDelta*tDelta/m_tDelta; // update position
break;
default:
break;
}
if(tDelta >= m_tDelta) // if i'm done moving
{
m_xPos = m_xStart + m_xDelta; // adjust position
m_yPos = m_yStart + m_yDelta;
m_status = STANDING; // and stop
}
}