Project

General

Profile

Emulator Issues #12066

Frame counter displays crazy numbers

Added by kamijoan 5 months ago. Updated about 2 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
5.0-11854
Fixed in:
5.0-12228

Description

What's the problem? Describe what went wrong.

The option from "movie/Display Frame Counter" displays really big number increments every frame during any game.

The values are different for each game (?)
As far as I've seen Wii Sports Resort is +550 every frame, RE darkside chronicles or mario party 4 are +524, pandora's tower is +1250. Stuff like that.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

It happened exactly on 5.0-11854, latest is 5.0-11879.

What are your PC specifications? (CPU, GPU, Operating System, more)

Windows 10, Intel i7-6700, Nvidia GTX 1080, 16Gb RAM.

History

#1 Updated by JosJuice 5 months ago

  • Regression start set to 5.0-11854
  • Regression changed from No to Yes
  • Milestone set to Current

#2 Updated by taolas 3 months ago

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.

#3 Updated by JosJuice 3 months ago

  • Status changed from New to Accepted

Why can't the number update go under Renderbase.cpp "if (!is_duplicate_frame)" ?

If dual core is being used, the RenderBase.cpp code is running on the GPU thread, while the movie code is on the CPU thread. (Actually, we used to call Movie::FrameUpdate() from the GPU thread for quite some time with no apparent negative effects... But it would be best to not re-introduce something that's sketchy from a correctness perspective.)

Failing that could it just increment on Core.cpp DoFrameStep getting called?

That would mean that the frame counter doesn't update when you don't use frame advance, not to mention that DoFrameStep also is on the wrong thread.

#4 Updated by JosJuice 3 months ago

  • Status changed from Accepted to Fix pending

#5 Updated by JosJuice 3 months ago

  • Fixed in set to 5.0-12228
  • Status changed from Fix pending to Fixed

#6 Updated by taolas 2 months ago

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.

#7 Updated by JosJuice 2 months ago

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.

#8 Updated by taolas about 2 months ago

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?

#9 Updated by JosJuice about 2 months ago

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.

#10 Updated by taolas about 2 months ago

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.

#11 Updated by JosJuice about 2 months ago

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.

#12 Updated by taolas about 2 months ago

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?

#13 Updated by JosJuice about 2 months ago

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.)

#14 Updated by JosJuice about 2 months ago

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.

#15 Updated by taolas about 2 months ago

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.

Also available in: Atom PDF