In "GameUpdateAndRender" (handmade.cpp) the movement, physics and collision code is inside a for loop that checks for input from attached Controllers ("Input->Controllers").
Each frame the loop is executed 5 times (length of "Input->Controllers"). That doesn't seem right:
- Only in the first cycle do we get "EndedDown" events
- The physics is dependent on the length of said array (and not only on "Input->dtForFrame")
Forced to only cycle per frame ("ControllerIndex < 1" instead of "ControllerIndex < ArrayCount(Input->Controllers") the physics change (our guy seems to move on ice) and the (current) collision code doesn't allow sliding along an obstacle anymore, but I guess this code was meant to run only once per frame. Please have a look.
Each frame the loop is executed 5 times (length of "Input->Controllers"). That doesn't seem right:
- Only in the first cycle do we get "EndedDown" events
- The physics is dependent on the length of said array (and not only on "Input->dtForFrame")
Forced to only cycle per frame ("ControllerIndex < 1" instead of "ControllerIndex < ArrayCount(Input->Controllers") the physics change (our guy seems to move on ice) and the (current) collision code doesn't allow sliding along an obstacle anymore, but I guess this code was meant to run only once per frame. Please have a look.
How could hundreds of us didn't notice that ?
Right now it's actually fine because we only have one digital controller so if I'm not mistaken it can only execute once the way we've been testing it (with the keyboard). But yes, we should move it outside sometime soon and use some aggregate control information. We need to actually do game control stuff relatively soon anyway so we can certainly do it this week, because right now we don't handle the analog stick at all either.
- Casey
- Casey
When I checked alst time (cannot double check at the moment) it did execute 5 times per “GameUpdateAndRender” call.
And only in the first cycle did I get keyboard events, so the acceleration was set only once in 5 cycles, the remaining 4 cycles our hero decelerated. Physics aside, that affected the old collision code (it actually made the sliding effect possible) and I fear it might also affect your new collision detection approach.
And only in the first cycle did I get keyboard events, so the acceleration was set only once in 5 cycles, the remaining 4 cycles our hero decelerated. Physics aside, that affected the old collision code (it actually made the sliding effect possible) and I fear it might also affect your new collision detection approach.
The check to see if we use the keyboard is wrong. It checks for isAnalog and that variable is only set to true if we use the stick on the controller.
There is a controller->isConnected variable that would solve the problem if no controller is plugged (but still not work if there is one controller plugged).
Would solve the problem for the moment (controller index 0 is the keyboard).
1 2 3 4 5 | if ( controller->isAnalog ) {
} else {
// Code is here.
}
|
There is a controller->isConnected variable that would solve the problem if no controller is plugged (but still not work if there is one controller plugged).
1 2 3 | if ( controllerIndex == 0 ) {
// Code is here.
}
|
Would solve the problem for the moment (controller index 0 is the keyboard).
Edited by Simon Anciaux
on
Reason: Clarification
We'll move it outside tonight so it's not a problem. Either way, thanks for posting!!
- Casey
- Casey
Oh My God!!!
I almost lost my mind, trying to figure out why my hero movement is different than Casey.
I am following along with the series from the start with my code, when Casey explains what he is going to do I pause the video and I try to do code myself then I watch him coding.
I look at both to see which one I like better. Most of the times I find bugs and typos that happens on the stream and I try to guess what the result is going to be. And I keep my code for the next day.
When I was typing the controller code I was aware that there was no check for IsConnected so I typed it in and I forgot about it and I knew it's gonna cause bug someday.
When I reached Day 43 and I was coding the movement code, everything was working fine so far until I start tuning the code that slow down the player
My hero was still swimmy while his is very subtle and stable so I had to turn the numbers very high to get a better movement.
I checked the frame rate, I checked all the code that is related to Meter/Pixel, I checked all the vector math and operators overloading five times, and I debugged the motion equations but nothing weird was going on.
So I moved on and I wasn't satisfied.
In Day 44 where Casey was making the hero slide along the wall, my hero wasn't sliding, he just stuck and stop moving and Casey was surprised that his hero didn't stuck because he was expecting that to happen.
I debugged the code and it make sense when the hero collide we eliminate the speed in the wall direction but we don't update the position and in the next frame, the acceleration speed up the hero in the wall direction and we deny the move again so the hero should not be moving.
So why his is moving?!
I scrolled up the page more and I saw the IsConnected thing and DUH!!
I commented out the check and everything became identical, the movement and the sliding but of course it wasn't correct.
The reason behind what was happening is every frame we clear the GameInput to zero and XInputGetState will fail so IsAnalog will stay false and so this portion of code will execute five times if you don't have any controller plugged in.
Also the hero speed and position will get updated five times every frame.
And since the GameInput is cleared to zero there is no acceleration in the wall direction during the four times in the loop and so it will act like updating the player position after we eliminated the speed toward the wall in the first time and the hero will slide.
It is nice that a bug will help tuning the hero movement and fix the collision problem.
I'm glad that someone already caught that.
I feel like there should be some place for every day where people, following the series later, can head to if they have something weird going on.
I almost lost my mind, trying to figure out why my hero movement is different than Casey.
I am following along with the series from the start with my code, when Casey explains what he is going to do I pause the video and I try to do code myself then I watch him coding.
I look at both to see which one I like better. Most of the times I find bugs and typos that happens on the stream and I try to guess what the result is going to be. And I keep my code for the next day.
When I was typing the controller code I was aware that there was no check for IsConnected so I typed it in and I forgot about it and I knew it's gonna cause bug someday.
When I reached Day 43 and I was coding the movement code, everything was working fine so far until I start tuning the code that slow down the player
1 2 3 4 5 6 7 8 |
f32 PlayerSpeed = 10.0f;
if(Controller->ActionUp.EndedDown)
{
PlayerSpeed = 50.0f;
}
ddPlayer *= PlayerSpeed;
ddPlayer += -1.5*State->dPlayerP;
|
My hero was still swimmy while his is very subtle and stable so I had to turn the numbers very high to get a better movement.
I checked the frame rate, I checked all the code that is related to Meter/Pixel, I checked all the vector math and operators overloading five times, and I debugged the motion equations but nothing weird was going on.
So I moved on and I wasn't satisfied.
In Day 44 where Casey was making the hero slide along the wall, my hero wasn't sliding, he just stuck and stop moving and Casey was surprised that his hero didn't stuck because he was expecting that to happen.
I debugged the code and it make sense when the hero collide we eliminate the speed in the wall direction but we don't update the position and in the next frame, the acceleration speed up the hero in the wall direction and we deny the move again so the hero should not be moving.
So why his is moving?!
I scrolled up the page more and I saw the IsConnected thing and DUH!!
I commented out the check and everything became identical, the movement and the sliding but of course it wasn't correct.
The reason behind what was happening is every frame we clear the GameInput to zero and XInputGetState will fail so IsAnalog will stay false and so this portion of code will execute five times if you don't have any controller plugged in.
Also the hero speed and position will get updated five times every frame.
And since the GameInput is cleared to zero there is no acceleration in the wall direction during the four times in the loop and so it will act like updating the player position after we eliminated the speed toward the wall in the first time and the hero will slide.
It is nice that a bug will help tuning the hero movement and fix the collision problem.
I'm glad that someone already caught that.
I feel like there should be some place for every day where people, following the series later, can head to if they have something weird going on.