Accurate FPS && HUD

[??????]

Accurate FPS && HUD​

Dekita​

 ​

Introduction:

The purpose of this script is to give the developer an accurate representation of your frames per second and a small hud to display it.

The default FPS counter (seen by pressing F2 in game) can be wildly inaccurate depending on your setup.

IMO - the purpose of a frames per second display, is to show how many times your frames are being refreshed each second.
For some reason, the F2 FPS counter is quite different from the actual amount of updates the Graphics module processes each second.

Simply pop the script in your game in a new script page and a small hud will be displayed. The hud settings can be configured slightly in the Real_FPS customization module.

Along with showing you the real FPS rate, this script gives you an average FPS rate and a total target rate, target rate shows you the percentage of which your games FPS has been equal to the target FPS since the last average FPS refresh occurred..

Features:

See above

Screenshots:

Uhh, why not...

How to use:

Usual stuff, see script documentation for full details.

Demo:

Nope

Script:

Link

FAQ:

What is your cat's name?

- Cat.

Credit && Thanks:

Dekita / DekitaRPG

Notes:

N/A

 

[Tsukihime]

Can you try it with 500 FPS? lol


Use this: http://himeworks.com/2014/10/rm-fps-control/

 

[??????]

Tried and failed:

to be fair, my laptop is rather old...

Perhaps you can reach 100% total accuracy at 500 FPS

Edit:

also, moving around the screen at that speed is just painfull on the old eyes

 

[Tsukihime]

What's interesting is that the exe says 52 but your script says 258.


I did notice that when I set it to 500, even if it says 130, it definitely feels faster than 130. And when I set it to 130, it did feel slower.


So you're on to something when you say the FPS is inaccurate.

 

[??????]

Oh yea, for sure the FPS is inaccurate.

It must be displaying something,but I dont quite thinks its the 'successful' graphics refresh rate.

After leaving it testing for a few minutes I was averaging 250 FPS, so I'm assuming someone with a better cpu would be able to get faster than that

 

[♥SOURCE♥]

Accurate FPS && HUD​

Dekita​

 ​

Introduction:

The purpose of this script is to give the developer an accurate representation of your frames per second and a small hud to display it.

The default FPS counter (seen by pressing F2 in game) can be wildly inaccurate depending on your setup.

IMO - the purpose of a frames per second display, is to show how many times your frames are being refreshed each second.

For some reason, the F2 FPS counter is quite different from the actual amount of updates the Graphics module processes each second.

Simply pop the script in your game in a new script page and a small hud will be displayed. The hud settings can be configured slightly in the Real_FPS customization module.

Along with showing you the real FPS rate, this script gives you an average FPS rate and a total target rate, target rate shows you the percentage of which your games FPS has been equal to the target FPS since the last average FPS refresh occurred..

Hello.

The FPS display of Ace is very accurate, but you are misunderstanding it's purpose. F2 FPS display will show you how many times the screen was drawn in a second, not how many iterations were processed in a second. Your script actually shows how many iterations were processed, so your HUD can say 20 FPS but the actual number of times the screen was drawn in a second can be 4 instead.

This is because how the actual hidden update method works, it doesn't draw the screen each time it's being called, it has it's own set of rules for frame skipping that we can just guess without seeing the actual code.

If you want it to actually draw the screen each time Graphics.update it's being called, you would have to call frame_reset before executing it to break its internal timing for frame skipping. Like this:

module Graphics class << self alias_methodoriginal_update, :update) def update # This will reset the internal frame skipping timer so that the # screen is drawn at each update call. frame_reset original_update end endendBy using the code above, you will actually experience lag as a slow motion effect, things will appear to go smooth but slow, if that makes sense...

So, in reality, your script is an inaccurate FPS display (unless the code above is executed and thus making the screen draw happen every iteration, consequently making iterations per second same as frames drawn per second.) but an accurate iterations per second display.

 

[??????]

 ... your HUD can say 20 FPS but the actual number of times the screen was drawn in a second can be 4 instead...

Yea, I completely get what you are saying, but this statement feels like a contradiction to me (sorry).

Like, if the graphics update method is being called 60 times per second, but for [x] reason the system cannot process as many updates within the allocated second, that creates an inaccurate frames per second display..

I wouldnt expect everything* to be drawn / redrawn after each graphics update, but I would certainly expect the number of successful iterations of the method to match up with the amount of times the method is called. To me that just makes sense.. Perhaps I am forgetting / not thinking of something?

Either way though, yea, this script shows an accurate representation of iterations of the Graphics#update method per second.

 

[♥SOURCE♥]

Yea, I completely get what you are saying, but this statement feels like a contradiction to me (sorry).

Like, if the graphics update method is being called 60 times per second, but for [x] reason the system cannot process as many updates within the allocated second, that creates an inaccurate frames per second display..

I wouldnt expect everything* to be drawn / redrawn after each graphics update, but I would certainly expect the number of successful iterations of the method to match up with the amount of times the method is called. To me that just makes sense.. Perhaps I am forgetting / not thinking of something?

Either way though, yea, this script shows an accurate representation of iterations of the Graphics#update method per second.

The number of successful iteration do match up with the number of times the method is called, what I am telling you is that Graphics.update doesn't draw the screen each time it is called. And FPS are the number of times the screen is drawn in a second, not the number of iterations the game loop did in a second.

try:

iteration = 0loop do p iteration iteration += 1endThe amount of times that loop iterates is not limited by your game until you add Graphics.update:

iterations = 0loop do Graphics.update p iterations iterations += 1endThis is because Graphics.update handles the timing and frame rate, probably making a sleep call to keep a regular timing after each screen draw based on how long it took to draw the screen vs the limit to get 60 draws per second (1 / 60). So there you have limited iterations, but each iteration doesn't mean a new screen drawing, especially when some time consuming process occurs, this is because how it handles the frame skipping, and we can't do anything more than guess, to "correct" that you can use the frame_reset technique I displayed in my previous post.

 

[??????]

So, if the F2 FPS displays the number of times the screen is drawn/redrawn in one second , surely I cannot have a higher F2 FPS than the number of times the game is iterating over the update method?

After all, if the frames are only being processed at [x] speed, which creates an rate of the graphics being drawn/redrawn at 30 FPS with the aforementioned limitations on iterations, surely the Graphics.update method is not being called more frequently?

Spoiler

 

[♥SOURCE♥]

So, if the F2 FPS displays the number of times the screen is drawn/redrawn in one second , surely I cannot have a higher F2 FPS than the number of times the game is iterating over the update method?

Graphics.update won't draw the screen more times than it's called, but it may draw the screen less times than it's called, because of its frame skipping.

After all, if the frames are only being processed at [x] speed, which creates an rate of the graphics being drawn/redrawn at 30 FPS with the aforementioned limitations on iterations, surely the Graphics.update method is not being called more frequently?

If you call Graphics.update more than one time per game iteration, you will experience the slow motion effect and you will break its frame skipping timing and FPS calculus (and thus it's display will be inaccurate).

 

[??????]

So, I finally got around to adding a frame reset into the graphics update process as your snippet illustrates, whilst using it, my game was showing an FPS of 60 (the F2 FPS), but my script that shows iterations was only outputting 42 FPS.

Either way though, this script provides a new way to show / calculate your games graphics update processes.

 

[♥SOURCE♥]

So, I finally got around to adding a frame reset into the graphics update process as your snippet illustrates, whilst using it, my game was showing an FPS of 60 (the F2 FPS), but my script that shows iterations was only outputting 42 FPS.

Yes, the F2 FPS display will be broken if you add the frame reset, but in exchange, your script will actually be accurate regarding FPS because the iterations (in that case 42) will represent the actual drawings (since frame_reset before update makes every update call draw the screen without skipping frames internally).

 

[??????]

Yea I get what you are meaning now, sorry.

Still though, a script - does stuff

 

[Tsukihime]

Ok, so now are you getting 500? lol

 

[??????]

lol nah, cant even break 180 FPS when using the frame_reset approach.. Are you able to get the full 500 displaying using my fps display?

 

[Halrawk]

Can you try it with 500 FPS? lol

Use this: http://himeworks.com/2014/10/rm-fps-control/

You can indeed reach the 500 FPS target, the average was slowly going up the longer I ran the game, just didn't feel like running it full time until the average went up.

 

[??????]

Whats your system specs dude?

would be nice to know what kinda system I gotta go buy in order to reach a 500 FPS side scrolling shooter !

 

[Halrawk]

Intel i7 Processor 2.8 GHz

32 GB ram

Dual Nvidia GTX 780M

And on solid state drives, so that might help.

Not sure if you'd need more info than this.

 

[??????]

lmao yea...

I'm on

Intel i3 2.4Ghz(x2)

4GB Ram

Intel HD Graphics

no SSD's :/

I really gotta get my ass a new comp. Think im gonna splash out on a windows 10 os when it is fully released

 

[Kane Hart]

Sorry if I missed something but I could not figure something out so I went ahead and used fraps to check how many rendered frames are being display. It seems that the f2 is truly the most accurate number:

http://i.imgur.com/hwjlRcs.png

I also noticed using the frame limiter and increasing to say 500+ I got about 200 but it's not rendered frames yeah sure it's maybe internal ticking for the game but not actual real frames.

http://i.imgur.com/yBriyMy.png

Just wanted to share my own findings sorry if I'm stepping on toes or missing something.