• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

FPS counter only displaying ideal FPS

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have an fps counter in my game loop:

When I print the fps variable to the terminal window, it show a value of ~59.9998 - very close to the frameRate of 60. That is to be expected, and works well. The problem is that when I deliberately make the game go really slow, by spamming a bunch of enemies, the game looks slow, but the FPS is still apparently ~59.9998. I thought that maybe the paint() method was not calling when it was supposed to, but that might not be the case.

This FPS counter should be working, I can't see where I have gone wrong. Is there a problem with the code, or is there another problem that might cause the screen to be redrawn 10 times a second with an FPS of 60?
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Avoid Math.pow(x, i) where i is a small integer number. It is probably quicker and more precise to use multiple multiplication, and in your present case the literal 1_000_000_000 (underscores _ available only in Java7+) (or 1e9) would probably do just as well.
 
Alfie Noakes
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alright, I've taken your advice. Thanks.

I have fixed my problem. I have put the timing code in the paint method, and it works perfectly now. The paint method mustn't have been called every time that I called repaint().
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why are you using paint() at all? You should override paintComponent() with protected access, and super.paintComponent(g); as its first line.
 
Alfie Noakes
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I use paintComponent() it gives me a StackOverflowError, however paint() works fine. I'm not sure why, though...
What are the advantages of using paintComponent()? I haven't got super.paintComponent(g), it appears to change nothing in my case.
 
Bartender
Posts: 322
24
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Alfie,

Not sure about the StackOverflowError without seeing the code and understanding what sort of component you are painting, but with regards to Sheriff Ritchie's answer, paintComponent is the correct method for all your painting code to be placed into when using lightweight Swing components. It's not really an 'advantage' thing. It's a 'proper way' thing.

The correct signature for paintComponent() is:



(@Override is optional, but a good idea when overriding. It helps insure you are overriding the intended method signature)

The reason you call the super's paintComponent method in the first line is to clear the existing graphics from the component - effectively, the super's paintComponent erases any existing graphics in the component and gives your custom code a clean piece of paper to draw on.

So, what does the paint() method do? It invokes several methods in the following order:
1) paintComponent()
2) paintBorder()
3) paintChildren()

Now, normally you don't ever call paint() directly. Instead you would call repaint() - which will suggest to the JVM that the component should be repainted when resources are available.

If I remember correctly (before my time with Java, but I'm sure some of the more senior folks can correct me), AWT (the precursor to Swing) had only a paint() method to draw heavyweight components. When Swing was introduced, and extended from AWT heavyweight components, paint() was retasked to call the methods I've outlined above in lightweight Swing components.
I found this old article that should help explain in detail if you are curious: http://www.oracle.com/technetwork/java/painting-140037.html

Cheers!
Chris
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you get a StackOverflowError then you should fix that instead of changing your code to use the wrong method.

As for why paint() is wrong and paintComponent() is right: what paint does is to call paintBorder and paintChildren and paintComponent. It may be that your component doesn't have a border and it doesn't have any children, but you shouldn't rely on that.

... In other words, what Chris just said. (And yes, AWT only had the paint() method.)
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic