FPS and Delta Timer Implementation

[SpinnerX]

We should consider properly implementing how we want to handle FPS and Delta timing. In contrast, considering how we track our FPS.

The idea behind FPS is it'll be a framerate that the application developer making the game is aware of and can utilize our frame-rate tracker to make sure the frame rate in sync.

Example in the Current Mainloop

Currently, Engine3D only has FrameTimer::UpdatePerFrame(); that updates the FPS every frame as the following:

while(m_CurrentWindow->IsActive(){
          FrameTimer::UpdatePerFrame();

         // update events or other things and so on...
}

Application Developer Usage (TBD)

This is just a brief example, we can discuss it further but this could be an idea on using fps/dt data that is stored in FrameTimer

GameApp::GameApp(const std::string p_DebugName){

}

void GameApp::UpdateEventPerTick(Event& p_Event){
         // doing something with the frame rate (or dt)
         float time = FrameTimer::GetCurrentDeltaTime();
         EventDispatcher dispatcher(p_Event, time);
         dispatcher.Dispatch<WindowCloseEvent>(OnWindowClose);
}

[SpinnerX]

Something that was mentioned. The proper usage for this specific feature is utilizing a basic test with actual scenes. This means defining how we may want scenes defined, including public API's for executing and updating scenes. Including if users want to set up their scenes and what that looks like to developers making their games.

The question to keep in mind is, do we need this to be generic?

[ZacharyH777]

SyncUpdateManager written with a local deltaTime and local fps. This means we can create children of the manager to run all the different kinds of virtual updates functions. The FPS is a little incorrect in timing off by 1 frame in global. Not in delta time though strangely. Local fps is a little harder to tell wether it is off by one or not.

Biggest problem though is that moving the window bar effects fps as chronos still runs. I am not certain how to solve this issue, possibly moving GlobalUpdateManager loop to a jframe may stop it from being tethered to the window. This has not been tested yet though.

[ZacharyH777]

I ended up creating a corrisponding Update class to each manager. That will be the parent of the component user try to make so they can run the virual functions. Might need to review the idea with someone though.