[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 https://github.com/PCSX2/pcsx2/issues/444#issuecomment-72524920.

~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 :+1:

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

[refractionpcsx2]

from what i've noticed with SoTC at least, the game does some crazy stuff where it just tries to do as much as it possibly can within its given timeframe and constantly hammers the VU's, if it can't get it done in time, it repeats the last frame giving the slowdown feel. Of course for us this causes massive speed issues, which is why the vu cycle stealing hack (or actually putting timing on the VU microprograms) helps the framerate for us massively. Of course the latter is much less choppy :P

[avih]

I wasn't talking about hacks. On a real PS2, SoTC updates the screen less than 60 updates/s most of the time and as low as 15-20 times/s on some situations. PCSX2 on a fast enough system would do the same without hacks, but will still display 60 FPS at the title.

Like I said, I think we should do two things:

1. Change the current FPS value to Speed in percentage, so this gets rid of the misleading info.
2. Try to figure out a way to count how many screen updates we push per second - this is not the PS2's vsync signals we manage to push per second.

[karasuhebi]

I agree with @avih, we should totally do the name change from FPS to Speed.

[Sarania]

I agree with changing it to speed.

[karasuhebi]

I'm making a separate issue about changing "xFPS" to "x%" so that this issue can continue being about implementing an in-game FPS counter.

[avih]

@ssakash just changed it to e.g. Speed: 100% (59.96). Here's what we get from it:

• Simpler to interpret value in percentage and without decimal points.
• We keep the more accurate "fps" value which also helps to identify NTSC/PAL rates, but don't display the string "fps" anymore (hopefully less confusion).

However, we still don't display the "real" fps (i.e. how many new images we push per second). Hopefully at some stage.

[willkuer]

Maybe 'Hz' after the fps value in the brackets? Somehow missing units are annoying. But as it never had a unit before you can as well just ignore this comment.

[avih]

Maybe 'Hz' after the fps value in the brackets?

Interesting idea, and not without merit. This might be the best description of this value indeed.

I'm pondering loudly though, the title is already quite long and with lots of data... when do we consider it too long? and when it's too long, which values do we remove from it, and to where?

[karasuhebi]

Off-topic: I was thinking Hz as well, but maybe we could do VPS (Vertical Interrupts Per Second) like Dolphin does? If I'm understanding this correctly, VPS is just as technically correct as Hz. Or again, we could leave it blank as it is now. That's fine too IMO. BTW @willkuer, if you want to keep this discussion going I humbly ask that you make a new Issue as I did with changing 'FPS' to 'Speed' so that we can better keep track of progress and discussion on all of these different topics without getting them mixed up. We can also keep the conversation going on #822 or #827.

On-topic: Has anyone tried any of the ideas given in this comment thread to see if we can get an actual FPS reading? Here's the ideas/clues I've seen thrown around so far:

• @ramapcsx2 had mentioned measuring time between hardware Vsync events.
• @gregory38 mentioned measuring time spent in a special kernel thread called "idle thread"
• @Sarania found a screenshot of PCSX2 running an old version of GSdx which seems to show FPS.
• @refractionpcsx2 mentioned something about a "finish" command on the GIF/GS side of things.

Also, does anyone have any new ideas? As I mentioned before, maybe @skmp could give us some ideas, and I believe @Asmodean- said he was planning on looking into this a while back.

[karasuhebi]

bump on the on-topic stuff.

[Sarania]

Does the PS2 have any sort of present command it uses to push frames to the screen we could count? I guess if it were that easy this would be obvious though.

I read a few days ago a comment from the code on frameskipping: // gsFrameSkip // -------------------------------------------------------------------------------------- // This function regulates the frameskipping status of the GS. Our new frameskipper for // 0.9.7 is a very simple logic pattern compared to the old mess. The goal now is to provide // the most compatible and efficient frameskip, instead of doing the adaptive logic of // 0.9.6. This is almost a necessity because of how many games treat the GS: they upload // great amounts of data while rendering 2 frames at a time (using double buffering), and // then use a simple pageswap to display the contents of the second frame for that vsync. // (this approach is mostly seen on interlace games; progressive games less so) // The result is that any skip pattern besides a fully consistent 2on,2off would reuslt in // tons of missing geometry, rendering frameskip useless. // // So instead we use a simple "always skipping" or "never skipping" logic.

Since frameskipping exists, can't we detect that pageswap and count it?

[KabutoKun]

This might be totally useless and unrelated to the topic here, but I'll post it anyway just in case.

It's easy to see the internal FPS for PSX games: just use Fraps or similar with any of the Pete OGL PSX plugins and you will see the game internal FPS, as the built-in FPS display does the same as PCSX2.

The "interesting" part here is that GSDX can be used in PSX emulators, but if you try the same method with Fraps it won't work, It will show you the same fixed 50/60 fps/vps/hz as it does in PCSX2.

I know the PS2 has an entirely different hardware to the PSX, but maybe understanding what's needed to show the internal FPS in PSX mode, in comparison to the working plugins, can be a hint to fix this on PCSX2.

BTW, I tried running the old version of GSdx from the mentioned screenshot, with several combinations of old PCSX2 versions and games, but it showed the usual fixed FPS. Weird.

[Sarania]

Mega bump.

@ssakash @gregory38 @refractionpcsx2 @ramapcsx2 (sorry for mega ping!)

Any ideas on this? I'm still curious about that old GSdx version. Is there any way to view that revs source? I think it was before we moved to Github.

I'm also still interested about the frameskipping stuff posted above. It says many games use double buffering and a pageswap. I feel this pageswap could provide hints on how to count this.

If anyone can tell me how to view the source from that really old rev I'd like to dig in it. Meanwhile tomorrow I will look into the frameskip code and see what it's up to and if it can be used to count real frames.

[ssakash]

I'm still curious about that old GSdx version. Is there any way to view that revs source? I think it was before we moved to Github.

That's the information sent by GSDX when there's a managed window. ( legacy GUI , GS Dump GUI)

also I don't necessarily think that's the real FPS. the limit for the old code was determined using the color subcarrier's register values. the old code was made to simply have the FPS limit based on the INT register status.

Behavior of old code:

Video mode	FPS limit value
NTSC - I	60 fps
NTSC - NI	30 fps
PAL - I	50 fps
PAL - NI	25 fps

Behavior of current code:

Video mode	FPS limit value
NTSC - I	60 fps
NTSC - NI	60 fps
PAL - I	50 fps
PAL - NI	50 fps

Note::

• NI -> Non-Interlaced
• I -> Interlaced

I already did preliminary work for accurate vertical frequency limit per video modes on https://github.com/PCSX2/pcsx2/pull/1175 , but I still haven't made those values be displayed on the GSFrame yet since I'm not sure whether it'll produce the actual FPS when used along with GSPerformance monitor class functions. ( also do note that it misses the impact of the INT register's status).

If anyone's interested, Feel free to investigate into it ;)

[Sarania]

Well, how hard is it to make it display that? If you can tell me how, or provide a build, I will do some testing and comparison to see if it produces the in game FPS reliably or not.

[willkuer]

These are still not real fps. VU cycle stealing and frameskip will make this reading inaccurate. How does fraps work? Does it take a random sample pixel set of the window and checks regularly if these pixels where updated? I think that would be the only possibility. Everything that is based on vsync will fail if two times the same frame will be emitted.

If you implement ssakash suggestion people will ask why they can only get 25 FPS while in the official youtube channel one can see 50 FPS.

[refractionpcsx2]

I suspect FRAPS watches for frame buffer flips in the API, I doubt it uses any sampling technique as that would be very inaccurate.

[gregory38]

Just a random idea. If I understand correctly the goal is to separate a fully rendered image from a nearly empty vsync. So maybe, one could count the number of draw call between 2 vsyncs. Below 10, image is the same as before (so +0), above 10 image is real (so +1). Then fps is +1*n/Vsync. 10 is an example (it is surely closer of 0). However, it won't work for FMV that just upload the image in the RT without any rendering.

[refractionpcsx2]

What about interlaced scenarios where it's doing half a frame per vsync? that is technically 25fps but that would still show 50 (in PAL anyway)

[avih]

What about interlaced scenarios where it's doing half a frame per vsync? that is technically 25fps but that would still show 50 (in PAL anyway)

It produces 50 (PAL) distinct images to the TV per second, so it should be considered 50. Also, if you choose BOB deinterlace in GSdx, then it's also actually 50 in PCSX too.

[gregory38]

So we could have 3 FPS values

• rendered image by second
• half-rendered image by second
• displayed image by second

Will people be happy with it ?