Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  About framerate  (Read 2298 times)
0 Members and 1 Guest are viewing this topic.
Offline SluX

Junior Member





« Posted 2005-07-20 13:34:01 »

I have just started using jogl and i have a question about animator class.
Can i somehow control speed of its calls to display method(with that option i would be able to control frame rate).

Maybe it's a wrong piece of code to check for framerate....

Help,please.

"Intelligence is the most beautiful gift and the greatest temptation which one life can receive from the gods."Me Cheesy
Play strategic football
Offline Soulfly32

Senior Newbie





« Reply #1 - Posted 2005-07-20 14:26:19 »

Search for FPSAnimator class in this forum.
With this you can control the fps.

_____________________________________
www.soulfly-design.de
www.soulflyhome.com
Offline zero

Junior Member





« Reply #2 - Posted 2005-07-20 14:35:21 »

I don't know about the FPSAnimator class, but:

Concerning animation, a fixed framerate is not a good the solution. It's better to measure the time between to display calls in use this a scaling factor. As a result animation is still correct, even if the framerate drops.

In order to display the elapsed frames per second, you could measure the time t between a certain amount of frames n, then you have n/t frames per second.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2005-07-20 15:51:04 »

Concerning animation, a fixed framerate is not a good the solution. It's better to measure the time between to display calls in use this a scaling factor. As a result animation is still correct, even if the framerate drops.
Ah bugger, you've done it now. Expect several pages of arguing over which is best, filled with lots of misconceptions of the "refresh rate" of the eye and other such oddness.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline zero

Junior Member





« Reply #4 - Posted 2005-07-20 16:17:40 »

Concerning animation, a fixed framerate is not a good the solution. It's better to measure the time between to display calls in use this a scaling factor. As a result animation is still correct, even if the framerate drops.
Ah bugger, you've done it now. Expect several pages of arguing over which is best, filled with lots of misconceptions of the "refresh rate" of the eye and other such oddness.

Sorry, I don't get the point. Besides that I doubt that a high framerate has any negative effect on the eyes using double buffering, people worrying about the "eye refresh rate" only have to set 'enable verticel sync' to 'always' in the driver settings. As a result the frames per second will match the monitor's refreshrate and every should be fine. So please tell me what I'm missing.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #5 - Posted 2005-07-20 21:29:26 »

Physics...

Variable frame rates affect physics in a very bad way. Hence, most games fix their FPS so that physics calculations that depend on the step size are not affected, thus making the physics simulation reliable.



Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline weston

Junior Member





« Reply #6 - Posted 2005-07-20 21:52:50 »

I'm guessing when Orangy Tang spoke of  misconseptions about the eye's 'refresh rate' he was talking about the fact that having a high framerate (and monitor refresh rate)  will only make a difference to a certain point because our own eyes won't 'refresh' the image as fast.

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2005-07-20 22:16:42 »

Concerning animation, a fixed framerate is not a good the solution. It's better to measure the time between to display calls in use this a scaling factor. As a result animation is still correct, even if the framerate drops.
Ah bugger, you've done it now. Expect several pages of arguing over which is best, filled with lots of misconceptions of the "refresh rate" of the eye and other such oddness.

Sorry, I don't get the point. Besides that I doubt that a high framerate has any negative effect on the eyes using double buffering, people worrying about the "eye refresh rate" only have to set 'enable verticel sync' to 'always' in the driver settings. As a result the frames per second will match the monitor's refreshrate and every should be fine. So please tell me what I'm missing.

This argument always goes the same way:

- Someone says they're using fixed/variable framerate
- Someone contradicts and says variable/fixed is clearly far superior
- Members from the 'variable' camp say they don't want a game fixed at a low framerate on their uber computer
- Members from the 'fixed' camp say they don't want choppy gameplay and lousy scrolling
- Much debate ensures around deterministic logic, physics update frequencies, methods of interpolating between logic ticks, crazy multithreading ideas, 2d vs. 3d, monitor refresh rates, etc.
- Sooner or later, someone insists that 'the eye can only see 24fps anyway' and that the whole discussion is moot.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #8 - Posted 2005-07-20 23:46:35 »

- Sooner or later, someone insists that 'the eye can only see 24fps anyway' and that the whole discussion is moot.

Except they would be wrong, and even if they were right it would mean you would have to implement proper motion blur, because natural objects do not teleport from one point to another, they move through every point on some path between the start and end.
:-)

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #9 - Posted 2005-07-20 23:52:09 »

- Sooner or later, someone insists that 'the eye can only see 24fps anyway' and that the whole discussion is moot.

Except they would be wrong,

Thats kinda my point. Roll Eyes

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zero

Junior Member





« Reply #10 - Posted 2005-07-21 11:25:54 »

Physics...

Variable frame rates affect physics in a very bad way. Hence, most games fix their FPS so that physics calculations that depend on the step size are not affected, thus making the physics simulation reliable.

Never heard of that, can you give me an example please?
Again, I can't imagine such a situation. If you're doing intersection tests at two successive frames (which of course isn't enough for a good collision detection) , then the accuracy increases with the framerate. In cases you use a more sophistaticated approach, you'd either have to solve some equations containong time as a variable or the time interval is subdivied during some iterations, but I can't see a benifit a fixed framerate here. Moreover only the maximum of a framerate can be fixed, since running other applications in the background can always lead in a drop. In conclusion animation and physics should ever be implemented independent of the framerate.


And concerning the discussion in general: I'm just sharing my experiences, hoping it will help others. And if it comes to a discussion, because someone has good arguments against my proposals, I'm very glad, I probably will learn something Smiley
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2005-07-21 12:12:19 »

NOOOOOOOOOOOOOOOO not the roving framerate thread! Move to Clubies. Or banish it to the fiery pit from whence it came etc. but whatever you do, don't start talking about it again! Orangy Tang summarized 100 threads in one funny post there.

Cas Smiley

Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #12 - Posted 2005-07-24 16:46:54 »

Do some tests with ODE, Tokomak, Newton and you'l see they are frame-rate dependant. Novodex is also frame rate dependant, but somehow, they can go around that but they do say its not reliable.

By reliability I mean if you run your simulation 100 times, in a fixed frame rate game, you are guaranteed 100 times that the object falls in exactly the same spot. However, with a variable frame rate, its all over the place. Hence the simulation is not reliable.

Yes, for once i agree with princec, move to clubiiiiies!

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #13 - Posted 2005-07-24 17:05:46 »

By reliability I mean if you run your simulation 100 times, in a fixed frame rate game, you are guaranteed 100 times that the object falls in exactly the same spot. However, with a variable frame rate, its all over the place. Hence the simulation is not reliable.

Actually, as a "variable framerater", I found darkprophet's comment quite useful, since I'd heard the 'physics needs fixed framerate' before, but didn't understand the issue.  Guess I've got a foot in each boat now.  OooooOOO Splash! Grin

Alan

Time flies like a bird. Fruit flies like a banana.
Offline zero

Junior Member





« Reply #14 - Posted 2005-07-24 20:40:00 »

Do some tests with ODE, Tokomak, Newton and you'l see they are frame-rate dependant. Novodex is also frame rate dependant, but somehow, they can go around that but they do say its not reliable.

By reliability I mean if you run your simulation 100 times, in a fixed frame rate game, you are guaranteed 100 times that the object falls in exactly the same spot. However, with a variable frame rate, its all over the place. Hence the simulation is not reliable.

At first, thanks for the second reply darkprophet.

I only have looked a havok physics engine yet and although it seems to have no problems with a variable framerate, I must confess that I never have made such a reliable test.

On the other hand we're are talking about the graphics framerate, at least I assume that in the jogl forum Wink, and a fixed time update step in the physics engine can coexist with a variable (graphics) framerate. Even if you call the 'update physics' within the display method you can adjust it respectivly to the measured time: either you have to call multipliy times for a low framerate or ignore it having a high-framerate. Then you have an equal update step, which as you indicated, is required for some physics engines. Of course this is not very different from applying the same algorithm originally used to fix the framerate, on the physics method.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #15 - Posted 2005-07-24 23:43:56 »

<offtopic>
To compensate for low-frame rates (or large step sizes), it is usually recommended that you increase the step interactions taken by the physics engine. Step interactions can be thought of as a simple formula: divide the step size by the step interactions number and update the engine with the new, smaller, step size for stepInteraction loops . This results in a more accurate calculation of forces accumulated as the penetration depth between two objects will be at a higher accuracy and is close to what it truly is, also, because friction coffecients are calculated by depth penetration testing (in most modern engines), then that will also be affected by the frame rate . How much to increase the step interactions by is highly user dependant as well as library dependant, so assumptions about calculations (like stepInteractions + (fixedFrameRate - ActualframeRate)) cannot be generalised. Also note that the engine also makes assumptions about the step interaction size and optimises for it, so setting the step interactions to 1 and doing the loop manually is highly not recommended.
</offtopic>

Personally, i dont mind either one, variable frame rates or fixed frame rates. As long as my calculations are frame-rate independant, my other threads in the engine are getting what they need, does it really matter?

Anyways, yes, this is a JOGL forum, graphics...etc, enough chit chat about physics.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline zero

Junior Member





« Reply #16 - Posted 2005-07-24 23:54:29 »

Personally, i dont mind either one, variable frame rates or fixed frame rates. As long as my calculations are frame-rate independant, my other threads in the engine are getting what they need, does it really matter?

a good conclusion Smiley
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.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (26 views)
2014-09-07 01:11:22

Longarmx (26 views)
2014-09-07 01:10:19

mitcheeb (34 views)
2014-09-04 23:08:59
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!