Emulator

Why can't the number update go under Renderbase.cpp "if (!is_duplicate_frame)" ? Is there a reason it needs to update sooner? Would the number be off by one there and if so could it just be decreased by one? Failing that could it just increment on Core.cpp DoFrameStep getting called?

If you have to do it directly before the first non-duplicate frame update, but can only decide if it was a non-duplicate update after it has been updated... that seems impossible.

Getting counter +2 each frame in some games. Both conditions are triggering per frame.

if (s_half_line_count == 0 || s_half_line_count == GetHalfLinesPerEvenField())
Movie::FrameUpdate();

Happens in Wii - Xenoblade. GC - Super Mario Sunshine. Does not happen in Wii - Mario Kart.

The frame counter is now counting how many fields would have gotten sent in the video signal, not how many unique frames are rendered. So 30/25 fps games will have two "frames" per rendered frame. I believe it would be difficult to change this without undermining the point of PR 8347.

Interesting. It's important to have consistent frame reporting though.

Are there any systems reliant on the field reporting through frameupdate() being accurate like that?
Can we detect the field-to-frame ratio and just correct the frameupdate() reporting with the ratio?
TASing just uses unique frames, right? Do old recordings work if the frames increase in increments of 2?

Are there any systems reliant on the field reporting through frameupdate() being accurate like that?

I believe that the only system that cares about the frame count at all is the TAS input window turbo functionality, which I made configurable recently so that you can have it mash e.g. every 4th frame instead of every other frame.

Can we detect the field-to-frame ratio and just correct the frameupdate() reporting with the ratio?

You could try to assume that the ratio will remain the same as it was recently, but... well, there are games that change framerate on the fly, so that won't necessarily work.

TASing just uses unique frames, right? Do old recordings work if the frames increase in increments of 2?

The concept of "frames" is largely irrelevant to playing back TASes. What matters is at what times controllers get polled. Because of this, I believe old recordings should still work, but I haven't tested it, and old recordings break all the time anyway.

If the frame counter number is largely irrelevant, can't we just decouple it from the displayed frame count?

Actually, doesn't imgui itself have ImGui::GetFrameCount()? Not sure if that'd be robust or loop back to zero too easily.

If the frame counter number is largely irrelevant, can't we just decouple it from the displayed frame count?

Well... you need some kind of frame counter in order to be able to display the frame count, no? There isn't really any other frame counter we can use.

Actually, doesn't imgui itself have ImGui::GetFrameCount()? Not sure if that'd be robust or loop back to zero too easily.

That brings with it a bunch of problems. A major one is that the counter does not go change when you load a savestate.

What I mean by decouple is that if we don't need it to update the displayed count number exactly when the polling does its thing, is there a more accurate, slower method that can be added just for the display?

Does the FPS calculation use its own accurate frame count?

Is there a problem where it needs to update before the imgui update goes out and other methods can't assure it will? Can the number just lag behind by 1 frame, but definitely increment by one sometime between imgui updates? Heck can it increment during imgui routines?

I suppose the information about whether a frame is duplicate or not actually becomes available just before the imgui update happens, so it would be possible to show an up-to-date count of non-duplicate frames for the imgui display only. But is it such a big deal that the frame counter includes duplicate frames? (Genuine question, since I don't have much TASing experience.)

For instance, assume that a TASer is trying to get from point A to point B in a game which usually runs at 60 fps but sometimes lags and slows down the gameplay speed. The TASer wants to make it to point B as fast as possible in real time. If the frame counter runs at a flat 60 fps, then it is a serviceable substitute for a real time timer. But if the frame counter skips counting lag frames, then the frame counter could show the same value for a non-laggy approach as for a laggy approach, with the non-laggy approach actually being faster in real time.

I don't TAS. I brought it up out of curiosity. I do use the frame counter to just count durations, texture stuff, etc. I figured having it not count 1:1 would be a bit annoying for me and others, as it's not a typical behavior of any frame counter I've seen. Plus, it didn't seem like something that you really have to compromise on.

Having it line up to 60 = 1 second does seem nice, as it works even on 60fps hacks where it's correctly 1:1. I guess I shouldn't say it has to be changed, just that it shouldn't be considered undoable.