[Feature Request] - Display of internal(in-game) FPS

[Sarania]

I think this would be very nice to have. Currently we only have the GSdx FPS indicator which of course is not true in game FPS. But there should be a relatively easy way to count the internal FPS too, I think. It would be useful in several ways I can think of. One is helping novice users to understand the effect of speedhacks better and how their game can feel slow even at 60 FPS. Another is testing the effects of the proposed EE overclock.

[ramapcsx2]

I'll second the request.
Maybe one can get the (VFPS, is that what other emus call this?) by measuring time between hardware Vsync events? Dunno.

[Sarania]

As I understand it, VFPS is what we have now, and what we are requesting here is RFPS.

For instance in nullDC, 60VFPS is full speed for NTSC, but RFPS can vary internally(like e.g. its 30 in Grandia II).

And yeah, measuring vsync events would be one way to do it, assuming all games on PS2 use vsync.

[Asmodean-]

I was going to have a bash at this last night. Until I realised that I can't even compile the latest gsdx, because of the opencl implementation ;p anyone recommend an opencl sdk?. I briefly tried the intel one, but it didn't work.

[Sarania]

@Asmodean I have the AMD one and GSdx compiles fine for me.

[karasuhebi]

I'll third this request. It would be a great feature so I can finally know what games don't really run at 60FPS internally, like the KH series, plus it'll help us identify variable framerate games, which would be ideal candidates for @Sarania's EE overclock hack. Also this way I'll be able to see the effects that speedhacks like EE Cyclerate and VU Cycle Stealing have on games like Shadow of the Colossus more clearly.

@ramapcsx2 Dolphin calls it VPS. According to one of their developers (@RachelBryk), VPS stands for 'vertical interrupts per second'. So as long as the emulator is running at 100% speed, the VPS reading should be 60Hz. From what I understand then, the FPS reading PCSX2 uses would be considered VPS.

https://forums.dolphin-emu.org/Thread-what-does-vps-stand-for

[Sarania]

So then you are saying my description is right... VPS is what we have currently, right?

[karasuhebi]

Yeah that's what I'm saying.

[RachelBryk]

Yes, that's right. Both measurements are useful to have.

[gregory38]

I think we currently using the internal vsync counter (ps2 hw) to measure fps. What others time do you want?

[Sarania]

@gregory38 That can't be - else that means every single PS2 game runs at 60(or 50) FPS which we know is not true(e.g. many games run at 30). Else I'm misunderstanding you.

Either way what we want to display is the actual in game FPS itself. Like how some games run at 60, some at 30, some are variable and have drops, etc.

E.g. this screenshot from dolphin(that karasuhebi sent me) http://i.imgur.com/c3O65KN.jpg

Note VPS at 60(which is the measurement we have now) and FPS at 30 (which is the in game real FPS, which is what we want).

[skmp]

I use VPS and RPS (=renders per second) on nulldc/reicast, but that also
includes off screen renders right now..

On Mon, Feb 2, 2015 at 8:51 PM, Blyss Sarania notifications@github.com
wrote:

@gregory38 https://github.com/gregory38 That can't be - else that means
every single PS2 game runs at 60(or 50) FPS which we know is not true(e.g.
many games run at 30). Else I'm misunderstanding you.

Either way what we want to display is the actual in game FPS itself. Like
how some games run at 60, some at 30, some are variable and have drops, etc.

E.g. this screenshot from dolphin(that karasuhebi sent me)
http://i.imgur.com/c3O65KN.jpg

Note VPS at 60(which is the measurement we have now) and FPS at 30 (which
is the in game real FPS, which is what we want).

—
Reply to this email directly or view it on GitHub
#444 (comment).

~skmp

[gregory38]

Hum, isn't it the gs configuration mode: progressive or interlace.
I think EE output 50 or 60 fps but gs is free to merge them so in the end you could have 25 or 30 fps.
There is an independant vsync cristal for the EE. Gs is aligned on the vsync of the tv. Note you potentially have the fps from the gpu PoV if GS/GPU is too slow but that unrelated to the EE.

If you want to read the related code check the file pcsx2/counters.cpp

[gregory38]

Potentially somethings that could be investigated
There is a special kernel thread called "idle thread". The thread is only an empty while (1) loop. When EE finish its job (or wait IOP), it executes this thread (until an interrupt is fired). Potentially we could measure the time spend in this thread (or why not in all threads).

[Sarania]

I've noticed something interesting:
http://forums.pcsx2.net/attachment.php?aid=53474
That's a screenshot of a game running on an old GSdx version. Note it's showing 28.2FPS as 93%, which would mean full speed at 29.97 or so.

Did older versions of GSdx do things differently?

[karasuhebi]

Nice find @Sarania!

[ramapcsx2]

Isn't that game "Goemon"? If so, how did it manage to run before @gregory38 's recent fix? :p

[Sarania]

@ramapcsx2 It is "Goemon" and it didn't run before that, but it still needs an old GSdx version to work right.

[ssakash]

yeah, it crashes within a moment of play in the newer gsdx version's but, it runs well in gsdx-rev1286 according to parotaku.

[karasuhebi]

So what's the status of this? @Asmodean-, are you still thinking of giving this a bash?

[karasuhebi]

Here's another reason for an in-game FPS counter, trying to find 60FPS hacks!
http://forums.pcsx2.net/Thread-PCSX2-Widescreen-Game-Patches?pid=372284#pid372284

The member calls it VPS, but ignore that. She means FPS. VPS is what we have. XD

[karasuhebi]

bump

[KabutoKun]

Yeah, I am very interested in this and I hope it gets implemented at some point, I would like to make some PS2 games run at 60 FPS so I need to know the real framerate at what they are running 👍

[karasuhebi]

@KabutoKun Nice username. Mazinger for life!

[karasuhebi]

I'm sure @skmp or maybe someone from Dolphin (@RachelBryk?) could give us some ideas. I believe @Asmodean- said he was going to try and give this a shot.

[karasuhebi]

So now that @gregory38 is all GSdx all the time and @refractionpcsx2 is back, I thought maybe we could figure out a way to get this done? :D

[refractionpcsx2]

The only way i can think of doing this is looking for a "finish" command on the GIF/GS side, but i suspect that is per routine rather than frame. I guess we can test it, but i don't guarantee that it'll work. Doing it on VSync's wont work because in the case of speedhacks where it gives false FPS, the emulator sends the same frame twice, so we would count the same frame.

[karasuhebi]

Any progress on this? I've found yet another user who's been confused by PCSX2 calling its counter "FPS":

https://www.reddit.com/r/PCSX2/comments/3iusnp/is_there_any_way_to_limit_the_frame_rate_on_121/

[refractionpcsx2]

Yeah you didn't quite explain it right.

All games run at 50fps or 60fps (its actually like 59.97 FPS, but who's counting right?) however a lot of games are interlaced, which means every "frame" for the emulator, it's actually only drawing half a frame, so 2 frames would be a full frame on the PS2, so you end up with 30 full frames per second on NTSC, 25 frames per second on PAL. We only count each vsync sent by the main emulator. I guess a cheap way of doing it would be to detect if interlacing is being used then half the frame rate displayed, but there is a percentage there to which is correct whichever way you look at it.

[avih]

Interlacing might be the issue on some cases, but at least some deinterlace methods (In PCSX2 - the bob variants) double the rate such 30 frames/s end up in actual 60 screen updates per second. The Weave and Blend methods, however, do end up with 30 screen updates/s.

However, I think that interlacing is not the only issue. For cases such as SoTC which can show 60 FPS but actually update the screen as low as 15-20 times a second (because that's how the real PS2 does it) is even more misleading, and this is where "internal/in-game fps" would be more useful.

IMO we should change the "FPS" title to "Speed", and the change value to the current fps value divided by the display mode's inherent rate.

So e.g. If currently we display "FPS: 59.94" for an NTSC title, then it should be "Speed: 100%" instead, and if the current fps is 25 on a PAL title, then it should show "Speed: 50%".

So this would at least clear the confusion about the FPS value.

However, the in-game fps value (like 20 for SoTC when it's running at 100% speed) would still be useful, and IMO that's what this bug is really about.

[gregory38]

Yes. But let's forget about half image. It is a minor details implementations.

[willkuer]

So i think the texture upload threshold idea by gregory is indeed as close as possible to the idea that was always requested. About fmv's one can talk later i guess.

[Sarania]

Internal FPS for an FMV is less pertinent. I think we can fake it TBH. For NTSC, the FMV is gonna be 29.97 and for pal it will be... what is it? 24.97 or something? Anyway the FMV will conform to the old SD standards, I'm 100% sure. So literally just fake it. Variable FPS in digital video is a very recent thing - it won't be present on something as far back as the PS2. And I can't believe that any game dev would have encoded it at anything less than the standard. There is no reason to. If there is an off case where it's wrong... I don't think it's that big a deal TBH. I'd rather fake it than show 0 and I don't think the extra work is worth it here.

As for why we need internal - well here is some reasons:

The EE overclock was designed to increase internal FPS. However judging that with your eyes is often hard. How do we know it's not just a placebo unless we can see?

Also other speedhacks often cause "false" VFPS and users don't understand why their game is "60 fps" but "half speed." That was somewhat mitigated by changing the label to speed, but yeah it still happens.

Another one is it could help in creating 60 fps patches for more games, which is always a welcome thing I think.

And lastly... it's just a good thing to know in my opinion.

[Sarania]

Actually I just check my PM and I have a build from ssakash to test... so on to that.

[mirh]

If some measurement has to be hardcoded because "we already know the value".. then it doesn't even make sense to take in the first place.
I guess counter could even disappear in FMVs, if there's really no way.

[Sarania]

It's no different than how the framelimit is hardcoded for NTSC/PAL etc. It has to come from somewhere. Games don't say "Hey, I run at 60FPS" rather they say "Hey, I'm NTSC"

[mirh]

Mhh.. I dunno. Tbh I remember some wizardry mumbling by @ramapcsx2 about some crystals somewhere somehow :s

[Sarania]

Lol.

As for the build @ssakash provided me I will probably test it tomorrow. I've got some household stuff I am trying to do. But once I test it, I will report back. He seems to think it won't show the difference as caused by overclock or speedhack but we will see.

[Sarania]

I tested ssakash's build just now. He is using some method based on draw call counting. While it does indeed seem to show the internal FPS, it's not affected by EE clock changes or VU stealing or anything. Ssakash said that was the expected behavior though because it was independent of what was happening in the core.

Anyway he said he is working on a much nicer way so I am waiting and looking forward to testing that. Good progress though!

[karasuhebi]

Nice progress @ssakash, I'm glad you got it to show you in-game FPS! How is your "much nicer way" coming along? Is it able to show the difference in FPS when the core is messed with?

[KabutoKun]

@ssakash @Sarania
Can I get access to that PCSX2 build with the WIP internal FPS counter (any version)? I'd like to test how effective it is.
I made a FPS cheat for Metal Gear Solid 3 and Kingdom Hearts has had it for a long time thanks to someone else, both these games are good test cases for this.

Right now this is how I calculate the internal FPS of SOME PS2 games in PCSX2:

• Almost every game has an internal frame counter in its RAM stored as an integer and every time a real game frame gets rendered it gets increased by 1.

• By using cheat engine you can easily find the address of this value in a game: just keep searching for values that are increased after every search.

• Thanks to the nice disassembler in PCSX2 (ported from PPSSPP right?) you can confirm it by setting a write breakpoint to it: if you see the game moves only one frame between every stop from the breakpoint, you may have found the right one. You should reboot the game with the write breakpoint still enabled to see that the value will be a 0 before it gets increased by 1 again (0 because the game has not rendered any frames yet after the reboot).

BTW, this can also be used as a workaround for a "frame advance" feature until this is implemented (someone created an issue around here asking for it).

• Using an external app (not PCSX2 related) I read every 1 second the address in RAM with the frame counter I found before, and the difference between the new and the previous value is the actual internal FPS of the game, for example: I read a frame counter value of 230, then I save it in the external app, wait 1 second, now I read a value of 260, so we have 260-230=30 internal FPS. Of course this calculated internal FPS will only be correct if your game has been always running at full speed in PCSX2.

As a workaround to also consider slowdowns or lower than full speed in PCSX2, some games have an internal time counter too, which may be stored in seconds or some fraction (like a running time in menus for RPGs, lap time in racing games, etc): if the game is running at full speed, the internal new-previous time difference should be 1 second too (the same as the external app time).

When it's not the same time then you divide the the new-previous frame difference by new-previous time difference, for example: I read the time address and I got a value of 45.0 (in seconds, stored as a float) and a frame value of 439, then after 1 second in the external app I read again and I get a time of 45.7 (lower than 1.0 external second of difference because the game at some point was running at lower than full speed in PCSX2) and a frame of 460: 45.7-45.0=0.7 and 460-439=21, so 21/0.7=30 internal FPS.

Thanks to using this crazy method, I can say:

• KH uses double buffered V-Sync, so when it can't keep a solid 60 FPS (using the 60FPS cheat), it drops to 30 FPS. Increasing the PS2 CPU speed makes the game totally stable at 60FPS.
• MGS3 runs at around 20+ FPS with lower than default PS2 CPU speed (depending what happens on screen). Higher than default PS2 CPU speed is needed to reach stable 60FPS (using 60 FPS cheat).
• Burnout 3 doesn't seem to be affected by PS2 CPU speed changes according to some limited testings.

Also, if there is any way to get the internal time of the emulated PS2 (using a syscall or something), that would be great because then I can write a better/cleaner method in assembly at least in a per game basis (I made a generic custom internal FPS counter for PSP games I use for special hacks).

Maybe some of this info is "useful" for a proper internal FPS counter in PCSX2 (at least the part to get the internal frame counter as a reference). Anyway let me know where can I get that WIP PCSX2 build (even if it is an older version, I won't share it with others if that's a concern).

[Sarania]

@KabutoKun -

Nice sleuthing there! Unfortunately I don't have the build anymore. @ssakash had given me an older WIP version that only kinda worked but I don't have that one anymore. He had told me he had a better one in the works but I never personally had that one and I don't know how viable it turned out to be.

However having memory addresses for some in game counters could be a boon. It's at least a way to directly compare any counter we make. So good job there for sure!

[willkuer]

If this is not an address in the bios address space (does that even exist?) it doesn't help at all. To maintain a list of all game counter addresses in the gamedbf will never be possible.

@KabutoKun 60FPS in MGS? This sounds like the nightmare that will destroy the whole world regarding cpu consumption... probably your cpu will heat to some Schwarzschild temperature that will turn the earth into a black hole. What kind of pc do you have to consider and even enable playing something like that?

[Sarania]

Why doesn't it help? To test the current test in game FPS implementations weve had to glue our eyeballs to the screen and try to notice a difference. As I said at the very least it would give us something to compare a general solution too.

[willkuer]

I was actually not addressing you. Not sure why I put the @ in the center of the response. You can not use the feature as general direct access to the frame advance feature and frame counter. But for sure you can use it in a specific case as a reference as you said.

Tbh I don't really get why there should be such a counter in release code if the game does not explicitely need it.

[ramapcsx2]

Well, those people that like tweaking will certainly find it useful to find perfect EE / VU cycle settings for their games. It can also quickly show any affect of any of the advanced settings on the internal frame rate.
It's also just very informative :)

On the method:
Isn't there a simple GS flag to watch for page flips or so?
I think we can ignore the complexity of deciding what kind of rendermode a game uses.
The metric people have a use for is the internal game execution speed. It wouldn't be a problem to have one title say like "30 flips / s" at full speed, and the other "60 flips / s". It should become clear what the game aims to display just by watching the counter through some scenes. People will then tune their settings to those values.

[ramapcsx2]

@gregory38 had a nice idea with the draw call counting earlier. Ignoring issues with FMV where it wouldn't work right, this is entirely on the GS and should produce the metric people have most use for. After all, they would (should) be tuning settings for in-game 3D anyway.

[refractionpcsx2]

Didn't GSDX used to have a drawcall counter?

[gregory38]

There is a global variable used for debug. GSstate::s_n

Otherwise more complex you can try to track if the frame buffer was written since previous vsync

[gregory38]

Some games such as God of war, use a rendering shortcut when you play with EE/VU cycles. For example they can use the background of the previous frame. Maybe draw call number could be interesting too

[refractionpcsx2]

Hey we could start a list "Games which might benefit from Vulkan" :P

[GameSpiritGS]

Bump. I see 60 FPS codes for games all the time but is there a way to see internal FPS counter?

[GameSpiritGS]

Bump. I just tried analyzing framerate from raw video footage with trdrop. Explained it in forum https://forums.pcsx2.net/Thread-Guide-Analyzing-internal-FPS

[refractionpcsx2]

Bump. I see 60 FPS codes for games all the time but is there a way to see internal FPS counter?

Not reliably, no. Some games are easy to detect, others are near impossible. This is something we've tried to do internally but there's no real solution to do this which will work for all games, which is why it hasn't been added.

[RedDevilus]

This old issue (7 years old - 2015) is finally fixed in #5361 :)