Lag

You can try my FPS counter. Usually (this will probably differ from pc to pc) I get like 10% of the FPS I get offline on the website. This is the scenario. It features all kinds of UI.

Does it needs a surplus code or a small amount of code If its a small code then will u write it for me becaz due to some reason i won't be able to download it If its a long code then let it be I will download it later on.....

The raw FPS measurement code is pretty short, but the code for the visuals is pretty big (For example that you can click on it to switch the mode). Also, I correctly do not have access to the code. If you really need it a can post it here later

Here is all the code: Time class (does the core fps calculations): Button class: Text class (used to display text by the button): Fps-Counter class (combines fps with button functionallity): Especially the button class looks very long but it's mostly documentation. You may say now that some of the methods are never used, but that's because this is to be used in various cases not just for the fps counter. To use this, simply create a new class in greenfoot and copy in all the code. After all it is propably easier to download the scenario and grap the packages folder for your scenario.

I can't express it...... Who r u ??? I think you r mad in coding It would be something around 10-20kb(just a guess) Thanks for sharing it But now i can't add it becaz i m much more concerned about my scenario storage after looking at the code I know its below 100kb(the maximum guess) but i want my scenario to work very smoothly

Actually i m newbie in java so its pitty long for me And i wanted it to learn that how does it work and also wanted to add it. Now its not possible for a newbie to learn it

Button.java ~21kb ;-) If you want to learn how it works then take a look at the Time class. It does all the neccecary stuff to calculate the fps. This is the act and fps method of the time class simplified to everything that is neccecary for simple fps calculation: Let's take a look: First off all the current time (in milliseconds, 1000 milliseconds = 1 second) is saved: "deltaTime" represents the fraction of a second since the last frame. For example, with 10 fps the deltaTime would be 0.1 as the time between each frame is a tenth of a second. We calculate it by getting the defference in time between the last and the current frame. This is a value that represents the milliseconds since the last frame. Now we divide that number by 1000, the length of 1 second. There we have deltaTime. Finally we save the current time for the next frame. Now we have a value that describes the length of the last frame. Let's take a look at the fps method which calculates the fps from the current deltaTime: The first line checks weather the current deltaTime is 0. If this is the case, the time step since the last frame and the current frame is less than a millisecond. Might seem quick, but with little in the world this is totally possible (Remember, the fps in Greenfoot do not mean the fps that your screen draws but the frames executed per second. Some frames might not be drawn). In this case we simple return 2000 fps (1000 would be a stable 1 millisecond per frame, so it's twice the framerate of what we would notice). If however deltaTime is in a normal range, we return 1 divided by deltaTime (as an integer). This means that we essentially count how often a frame of the current length would fit into 1 second. There you go! Fps of the current frame. However, this fps method returns a very precise number for each frame but not a nice average. For that the other code in the time act method is used. But for some simple performance tests, this is totally enough. The problem is that while you can calculate the fps now, you can't output it yet. You may think that you could just print it to the console, but, unfortunatly, the console is pretty slow and itself will slow down your game to like 100 fps even if you could have 1000. So my recomentation would be to use getWorld.showText("FPS: " + fps(), 100, 100); which simply draws the fps onto the world background at the coordinates 100, 100. But that's why I am using the button to print it. Also, the button allowes to switch fps modes between average and precise. After all, "deltaTime" is not only useful for measuring fps. It's actually just a side product. The real purpose is that you can have fps-independent movement and similar. What you can do is for example say: Since the more often the method is executed per second the smaller deltaTime is, the actor will move 20 pixels per second, no matter if you have your speed slider at max or limiting to 10 fps. Also, this will for some degree smoothen out lag as it will accelerate objects more at lower framerates. Finally, I just wanted to mention that I'm 'only' coding java (and generally) for about 2 years now. I'm sure you can learn this really quickly, too!

Thank u!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! U wasted a lot of ur time i teaching a newbie After looking at the code i knew that my basic is not strong and i have to strive more(actually i knew it already) I have not been taught java. I m learning on my own and my basic is not so strong to understand ur code. Lastly i would like to say u that; when i will be a genius like u then i shall look that how u made fps Initially i thought that fps would be easy and easy to learn but now its not easy for me or a beginner