Jump to content

  • Log In with Google      Sign In   
  • Create Account

__SKYe

Member Since 10 Jun 2011
Offline Last Active Yesterday, 12:52 AM

Posts I've Made

In Topic: SDL Input not behaving as expected.

08 June 2016 - 07:12 PM

Yes, as Kercyn says, your keyUpEvent and keyDownEvent are indeed swapped.

 

Also, just as an example, I'll post a different way you could do it.

void Player::update(int elapsed_time_ms)
{
    sprite->update(elapsed_time_ms);

    //OK, this 2 variables don't exist in your code (user_pressed_left and user_pressed_right), but they are
    //simply bools that are set, if the left or right keys are pressed.
      
      //EDIT: Here, there's no 'else' in the second 'if', because if the user is pressing both directional keys,
      //      the acceleration gained from both will cancel each other, and will behave as if no key is pressed.
      //Update acceleration based on user input
      if(user_pressed_left)
      acceleration_x_ -= kWalkingAcceleration * elapsed_time_ms;
      if(user_pressed_right)
      acceleration_x_ += kWalkingAcceleration * elapsed_time_ms;

      //Make sure that the acceleration doesn't exceed the maximum speed
      if(acceleration_x_ > kMaxSpeedX)
      acceleration_x_ = kMaxSpeedX;
      //Same goes for negative acceleration (moving left)
      //EDIT: Added 'else' here, because acceleration can only be either max positive or max negative
      else if(acceleration_x_ < -kMaxSpeedX)
      acceleration_x_ = -kMaxSpeedX;

    //Update player's position
    x_ += acceleration_x_;

      //Now, you can apply kSlowdownFactor (AKA friction).
      //The simplest way, is to check if the player has not pressed any direction buttons (or both),
      //and apply friction if so.
      if((!user_pressed_left && !user_pressed_right) ||  //No keys pressed
         ( user_pressed_left &&  user_pressed_left )   ) //Both keys pressed
      {

        //EDIT: If the acceleration is 0.0f, then the player is already stopped, so don't apply friction
        //      By the way, be careful with equal comparison of floating point numbers.
        if(acceleration_x_ == 0.0f)
        break;

        //If acceleration is negative, apply friction to get it closer to 0.0f
        if(acceleration_x_ < 0.0f)
        {
          //EDIT: If acceleration is bigger than friction, then just apply it
          if(acceleration_x_ < -kSlowdownFactor)
          acceleration_x_ += kSlowdownFactor;
          //EDIT: But if acceleration would become positive, then just set it to 0.0
          else
          acceleration = 0.0f;
        }

        //Same goes for positive acceleration
        //EDIT: Also added 'else' here.
        else if(acceleration_x_ > 0.0f)
        {
          //EDIT: If acceleration is bigger than friction, then just apply it
          if(acceleration_x_ > kSlowdownFactor)
          acceleration_x_ -= kSlowdownFactor;
          //EDIT: But if acceleration would become negative, then just set it to 0.0
          else
          acceleration = 0.0f;
​        }

      }
 
      //Keep player within screen bounds
      if(x_ < 0)
      x_ = 0;
      else if(x_ > 640)
      x_ = 600;
}

void Player::startMovingLeft()
{
    user_pressed_left = true;
}
 
void Player::startMovingRight()
{
    user_pressed_right = true;
}

void Player::stopMoving()
{
    //Do nothing
    return;
}

Note that you don't need the velocity variable this way

 

This code is untested, so sorry if there're any errors.

I hope the explanation is concise, but if it's not (or you have any doubt) hit me up, and I'll try to explain better,

 

Hope it helps.

 

EDIT: I forgot one thing, and that is to stop applying friction when the acceleration would become 0.0. The way it is now, the player would "wiggle" in place, due to the fact that acceleration keeps jumping from positive to negative.

 

Also added a few "else" to make the code a bit more efficient.

Sorry for the mistake.


In Topic: Pixel Art and Screen Resolutions

08 June 2016 - 06:23 PM

In my understanding, tthere are 2 things you can do.

 

If you wish to keep the sprites aspect ratio (scale in multiples of the initial size only, like you say you currently do), you can enlarge the amount of level the user can see.

The player would see more of the world, where it would otherwise be unused (the 160 pixels, in your example).

 

The other is to simply scale the sprites to non-multiples of their size (scale to fullscreen), if necessary. You will get uneven scaling (how much depending on the user's screen), but your game will look the same on every resolution.

 

Basically, in my opinion, either you compromise screen real-estate (to achieve aspect correct scaling), you compromise your game world's view (again, also achieving correct sprite aspect) or you compromise the sprite's aspect ratio (to get full screen coverage and identical game world view).

 

Also, the uneven stretching (stretch to full screen) is, by far, the simplest.

 

As a last note, keep in mind that you may want to keep your game's aspect ratio constant, even across multiple monitors/resolutions.

For example, if your game runs in a 16:9 aspect ratio, in order to maintain it, you'd want to put letterboxes on 4:3 or 5:4 monitors, otherwise, you'd either have to show more of the game's world (possibly compromising gameplay balance), or get a pretty uneven stretching going on.

 

Don't know if it's the answer you are hoping for, but I hope it helps, and if my explanation is confusing, I'm happy to clarify.


In Topic: Help With Serialization

04 June 2016 - 08:13 PM

Hi.

 

I'm not very experienced with serialization but, are you writing pointers (addresses) to the save file?

Because I'm thinking that they would indeed work on the same instance that saved it (because the addresses remain the same) but won't work when you run the game again because your PlayerProfile class pointers have different addresses.

 

Don't know if that's the issue, but that's the first thing that comes to mind.

 

By the way, I'm assuming that's C++, if it's not, then my mistake.

 

Hope it helps!

 

EDIT: Ha, Tangletail beat me to the punch. :)


In Topic: 2d images and OpenGL

04 June 2016 - 08:03 PM

What exactly are your doubts about drawing 2D?

 

As far as I know, the way you describe, is the way to do it (and I wouldn't call it "mimicking" a 2D environment. It IS a 2D environment).

 

You set up the ortho projection, and draw textured quads.

Preferably, you set the ortho projection to match the application's window resolution and draw the quad the exact size of the texture you want to draw. That results in essentialy the same as what other APIs call 'sprites' (like Flash/Java/etc).

 

And, again, that's pretty much all that's needed.

 

Sorry if I'm misunderstanding your question (apart from me not providing articles), but there's not really much else to it that I'm aware.


In Topic: glew does not initializes extensions

06 April 2016 - 12:35 AM

Hi.

 

Have you initialized GLEW (called glewInit()) after creating an OpenGL context?

 

EDIT:

 

I mean, if it works when you initialize it in the DLL, then maybe it's because you initialize the DLL after you've created the window and an OpenGL context.

And perhaps it doesn't work when you initialize it in the EXE, because you're initializing GLEW before you've created an OpenGL context (and the window, maybe).


PARTNERS