Unable to move Vehicle after dropping flame trail or triggering emitters

[jamescote]

For some reason, when a flame trail is dropped or emitters are triggered, the vehicle stops taking movement input from the user.

I'm not exactly sure why this might be happening, but some potential culprits might be:

• The emitter and flame trail might be dropping too many instances when triggered; may be a command handler problem.
• Perhaps the PhysicsManager update is fetching results too soon, before they're update properly?

I think there may be some other bugs that this is just a symptom of, but it's important to put it on the radar and look out for it.

[EvanQuan]

I can confirm this is not a problem with the InputHandler or CommandHandler. When the vehicle is stuck while there are many flame or emitter particles, the CommandHandler sends movement commands at the same rate as normal.

Therefore, this is almost certainly a problem with the PhysicsManager.

[EvanQuan]

It turns out that any number of expensive actions will slow the vehicle down. Similar to how I was using system("CLS") every frame to print information when I was working on the InputHandler and ComandHandler, that would slow the vehicle down. I can compensate for this slowing by increasing the movement force. This means that expensive non-physics related actions don't actually stop the physics from working altogether, but do have an impact on how forces interact with objects.

[EvanQuan]

As of #122, Camera movement also slows down with expensive operations. This means that if there is a lot of fire, I can rotate the car and the camera will very slowly try to move behind the player. If there is enough fire, I can make the car face the camera.

[EvanQuan]

This means this may not be a problem inherit to physics after all, but the update loop that updates everything from physics to the camera to whatever else.

[EvanQuan]

Tracing the logic of the camera and physics updating, it all leads back to GameManager::renderGraphics

// Intended to be called every cycle, or when the graphics need to be updated
bool GameManager::renderGraphics()
{
    // Update Timer
    m_pTimer.updateTime();
    m_fFrameTime += m_pTimer.getFrameTime();

    // Execute all commands for this frame
    m_commandHandler->executeAllCommands();

    // Update Environment
    m_pEntityManager->updateEnvironment(m_pTimer);

    // call function to draw our scene
    if (m_fFrameTime >= m_fMaxDeltaTime) // This locks the framerate to 60 fps
    {
        ...
        m_pEntityManager->renderEnvironment();

I wanted to see what would happen if we didn't lock the frame rate, which is to say the environment and the rendering both updated as often as they could.

So I set the frame rate condition to true, basically, removing the if statement

    // call function to draw our scene
    if (true) // This locks the framerate to 60 fps

Lo and behold, the camera really lagged behind and the movement became sluggish and halted in a smilar manner to when emitter particles were spammed.

So if it's rendering every frame, then each GameManger::renderGraphics() call takes longer as it needs to do more work, which means that GameManager::renderGraphics() is called at a lower rate. Obviously the use of fDeltaTime is meant to compensate for this, but it doesn't seem to be doing its job correctly. Unsure if this a problem with Physics or something else.

For the Camera lagging, this is my fault. I know the solution to it and will fix it as soon as I can.

[EvanQuan]

Camera problem is fixed as of #127

[EvanQuan]

Luckily, haven't experienced this problem in a while. Then again, no particles are being generated with the current state of the project.