Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (553)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Frame rate capping (aka predictable drawing time)  (Read 2646 times)
0 Members and 1 Guest are viewing this topic.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Posted 2003-03-27 18:00:37 »

Hi all,

I knocked up a simple frame rate capping class this evening to make my life easier - I was fiddling with a few things, and my animations were running at different speeds depending on the amount of work done that frame.  Lock the frame rate to 60 FPS and I can be sure that things will run at no more than that rate.

This is a very simple bit of code, and is a first cut.  It works fine, but needs a few more features.  Cas mentioned the process in his diary a while back, and I've just found need for it.

I'd be grateful if anyone interested in it give it a go and tell me if it works for you.  Consider it BSD licenced! Here's the new class:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
import org.lwjgl.Sys ;

public class FrameRateCap
{
      private FrameRateCap() {}

      private static int frameRate = -1 ;
      private static long preferredFrameTicks ;
      private static long frames ;
      private static long startTick ;
      private static long endTick ;
      private static long frameStartTick ;

      public static void setFrameRate(int frameRate2)
      {
            assert (frameRate2 > 0) : frameRate2 ;
            assert (frameRate == -1) : "Already set" ;

            frameRate = frameRate2 ;
            preferredFrameTicks = Sys.getTimerResolution() / frameRate ;
      }

      public static void start()
      {
            startTick = Sys.getTime() ;
            frames = 0 ;
      }

      public static void startFrame()
      {
            frameStartTick = Sys.getTime() ;
      }

      public static void endFrame()
      {
            frames++ ;

            long frameDurationTicks = Sys.getTime() - frameStartTick ;

            while(frameDurationTicks < preferredFrameTicks)
            {
                  long sleepTime = ((preferredFrameTicks - frameDurationTicks) * 1000) / Sys.getTimerResolution() ;

                  try
                  {
                        Thread.sleep(sleepTime) ;
                  }
                  catch(InterruptedException e)
                  {
                  }

                  frameDurationTicks = Sys.getTime() - frameStartTick ;
            }
      }

      public static void end()
      {
            endTick = Sys.getTime() ;
      }

      public static long getFrames()
      {
            return frames ;
      }

      public static float getFramesPerSecond()
      {
            return frames / ((endTick - startTick) / (float)Sys.getTimerResolution()) ;
      }
}


And you use it like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
FrameRateCap.setFrameRate(60) ;
FrameRateCap.start() ;

while(!finished)
{
      FrameRateCap.startFrame() ;

      // Drawing code here

      FrameRateCap.endFrame() ;
}

FrameRateCap.end() ;

System.out.println("Frames rendered: " + FrameRateCap.getFrames()) ;
System.out.println("FPS: " + FrameRateCap.getFramesPerSecond()) ;


You just tell it how many FPS you want, tell it when the drawing process starts and ends, and tell it about the start and end of each frame, and it'll introduce a padding delay if the drawing completed early and track number of frames rendered and actual frames per second for you.


Any comments?

Hellomynameis Charlie Dobbie.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #1 - Posted 2003-03-28 08:28:39 »

Nice, I'll give it a go this weekend :-)

Offline darcone

Junior Member




Size matters


« Reply #2 - Posted 2003-03-30 20:57:54 »

Is this really neccessary? using the Sys.getTime() I managed to get the time it takes to draw each frame and then update the current FPS depending on the time it took. Something like this:

temp = Sys.getTime();

rendering code...

FPS = 1((Sys.getTime() - temp)/Sys.getTimerResolution());
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #3 - Posted 2003-03-31 05:05:36 »

It's not for throttling gameplay, but just to limit the fps. More than 60fps is just not necessary so when you limit to that speed, you will have time left for other things(like GC?).

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2003-03-31 05:20:47 »

Quote
More than 60fps is just not necessary

And 640 kb is enough?  Tongue

Seriously I can detect a difference in 60 fps vs. 100!
Monitor updates below 85Hz almost makes my eyes bleed.

Offline NielsJ

Senior Newbie




Java games rock!


« Reply #5 - Posted 2003-03-31 06:19:36 »

You are confusing framerate with monitor update frequency. The latter will make your eyes bleed if set to low, the first will just look ugly.

A 60 fps framerate is way more than what is used in Hollywood movies (20-something i believe?), and way way more than what is used in e.g. anime movies (12fps I think).

So yes, 60fps is quite enough. And no, it is not comparable to BGs famous 640K statement Smiley, as human eyes are not likely to evolve at the same rate that computer HW and SW has Tongue

(Oh, and another thing: Monitor update frequency is not a generic problem, but related especially to CRT monitors because these screens loose their charge quickly, a TFT at 60Hz is rock solid)
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #6 - Posted 2003-03-31 07:24:22 »

Quote
You are confusing framerate with monitor update frequency.

no no no Smiley
That was why I talked fps vs monitor updates (refresh rate)

Quote
A 60 fps framerate is way more than what is used in Hollywood movies (20-something i believe?), and way way more than what is used in e.g. anime movies (12fps I think).

Yes, TV's are 24 fps - however unlike Cameras, computers cannot (or rather do not) use motion blur, which is what makes 24 fps acceptable.

Quote
So yes, 60fps is quite enough.

As you also know, any game doing 24 fps will look awfully jerky - and many will also say that they can feel a difference between 60 and 100 fps - I for one can.
But this is mostly related to FPS games. Many games can get off with much lower framerates - puzzle/rpg/rts games often do much lower framerates - some even 30 fps.

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #7 - Posted 2003-03-31 08:42:24 »

No problem, cap the frame rate to 100 instead! Grin

This little class is just designed to waste a bit of time at the end of each frame, making sure the frame rate never goes *above* a certain limit.  Naturally, if your drawing takes longer than the set limit allows it'll never sleep and your frame rate will drop.

The primary purpose of this is not to calculate your FPS, but to slow down the game logic so animations can be written to change every six frames or whatever - avoiding the need to calculate actual frame rendering time and adjust animations, object movements etc accordingly.

It's a time saving hack really, but I've found it pretty darn useful.  Naturally, depending on how you've written your render/update logic, this solution may be totally inappropiate for you.  YMMV and all that.

Hellomynameis Charlie Dobbie.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #8 - Posted 2003-03-31 08:43:22 »

Quote
Yes, TV's are 24 fps


Not that it's really important, but TV's are 25 fps in Europe and 30 fps in the US, 50 resp. 60 fps interlaced.
Cinema is 24fps.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2003-03-31 11:15:22 »

<smartass mode>
Actually North American television is approximately 29.97 frames per second, it was only 30 fps in the days of black and white. :-)
</smartass mode>

The only reason I bring it up, is that it sometimes matters if you are doing video work and you want your audio and video to stay in sync.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #10 - Posted 2003-03-31 11:47:21 »

Yeah, I always loved that 24/25 incompatibility between cinema and TV.  They generally don't bother rescaling the original accordingly.

This does mean that films on TV are just that little bit shorter than in the cinema, and the voices are a bit faster and higher in pitch.  Not something that many people would notice, but bloody funny when you think about it.

Hellomynameis Charlie Dobbie.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #11 - Posted 2003-03-31 17:28:57 »

Well perhaps it is less disturbing than the 3:2 pull down that is used to show movies in NTSC...
I often wonder why they don't just make the PAL TVs so they can sync to 24fps and come up with a signal variation with slightly different timing...  I know that we did just that at the last company I worked at to make a true 'film mode' video preview.

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #12 - Posted 2003-03-31 22:44:40 »

Quote
Yeah, I always loved that 24/25 incompatibility between cinema and TV.  They generally don't bother rescaling the original accordingly.

This does mean that films on TV are just that little bit shorter than in the cinema, and the voices are a bit faster and higher in pitch.  Not something that many people would notice, but bloody funny when you think about it.


it's a part of the evil plan of the industry :>

think about it... that allows more commercials  Shocked

back to the fps discussion... i play q3 with 85 fps and i know that 85fps can be smooft or jerky.

there are some things wich are neccessary to get it smooft:
  • vsync. it's essential - no tearing and it ensures, that the time between each frame stays the same (if the comp is fast enough)
  • the movement has to be steady. if something moves with 4 units per frame, it should always move this 4 units (340ups) - not 3 in one and 5 in another.
  • a matching mouse polling interval is nice or twice as high and interpolation or just higher (than the hz of the display)


first one is nice and more ergonomic. 2nd has a _huge_ impact - it feels like havin at least 30% fps more. 3rd is just an accuracy thingy but it's nice this way Smiley

hm... all we need is a hi-res timer. vote for it Smiley

well timing is much easier for console devers. 25, 30, 50 or 60 fps... timing is frame/game tick based and u have to ensure that u get that framerate always otherways u get slowdowns (half fps=half ticks=half speed).

弾幕 ☆ @mahonnaiseblog
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #13 - Posted 2003-04-01 02:00:05 »

One comment Onyx. Sometimes games can be smoother if the characters move a different number of pixels per frame. A walking animation for example, should cause the character to move more pixels during the longer part of the stride, and fewer during the shorter part. This looks natural and more realistic. Other than that, you're dead on. Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (24 views)
2014-08-22 19:31:30

atombrot (34 views)
2014-08-19 09:29:53

Tekkerue (30 views)
2014-08-16 06:45:27

Tekkerue (28 views)
2014-08-16 06:22:17

Tekkerue (18 views)
2014-08-16 06:20:21

Tekkerue (27 views)
2014-08-16 06:12:11

Rayexar (65 views)
2014-08-11 02:49:23

BurntPizza (41 views)
2014-08-09 21:09:32

BurntPizza (33 views)
2014-08-08 02:01:56

Norakomi (42 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!