Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
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  
  Sys class issue?  (Read 3735 times)
0 Members and 1 Guest are viewing this topic.
Offline TheAnalogKid

JGO Coder


Projects: 2



« Posted 2005-11-14 15:19:41 »

Hi,

I have upgraded from 0.95 to 0.98-1 yesterday and without any code change my frame rate dropped to 48-49 fps and my game was running at synchronized 60 fps with version 0.95. I use the Sys class to handle fps and for animation timing. I've read on the LWJGL forums (http://lwjgl.org/forum/viewtopic.php?t=1217&highlight=sys) that Sys.getTimerResolution()  seems to always return 1000 on Windows. Do you think it might be related to my problem? It seems that something has been broken after 0.95 in the Sys class.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #1 - Posted 2005-11-14 16:25:55 »

there was a timing problems with i think lwjgl 0.96 and before, but it has been fixed now the best way to cap the game at a certain fps now is if you use
1  
Display.sync(60);

maybe try that instead of the timer ur using atm.
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #2 - Posted 2005-11-14 16:42:39 »

I you use Display.sync(), how do you handle movement timing if the fps drops below 60? If its 50 then all the characters moves must adapt to that fps if all the moves are time based (pixels/second). For example if my character moves at 200 pixels per second then how do you adapt the character move if the fps drops below 60?

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #3 - Posted 2005-11-14 17:36:57 »

Using tick based movements also means you movement slows down if the FPS is low.
This is usually not a problem, but if it is you should use time based movement instead.

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #4 - Posted 2005-11-14 17:44:23 »

Matzon,

according to your answer do you think I need to replace Sys usage for lwjgl.util.Timer or GAGE timer?

Online kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2005-11-14 18:03:36 »

But isn't getTimeResolution() whats used to convert between "tick" based movement to "time" based movement?

Kev

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #6 - Posted 2005-11-14 18:05:46 »

But isn't getTimeResolution() whats used to convert between "tick" based movement to "time" based movement?

Kev

Correct but if this method always returns 1000 under Windows it's not accurate at all based on the CPU clock speed.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #7 - Posted 2005-11-14 18:42:35 »

I you use Display.sync(), how do you handle movement timing if the fps drops below 60? If its 50 then all the characters moves must adapt to that fps if all the moves are time based (pixels/second). For example if my character moves at 200 pixels per second then how do you adapt the character move if the fps drops below 60?

well if its time based using delta, movement shouldn't be effected even if the fps goes below or above 60.

Oh btw have a look at the SystemTimer.getTime() class included in the space invaders demo with lwjgl it handles the issue very nicely.
Online kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2005-11-14 18:45:53 »

But isn't getTimeResolution() whats used to convert between "tick" based movement to "time" based movement?

Kev

Correct but if this method always returns 1000 under Windows it's not accurate at all based on the CPU clock speed.

Absolutely, thats why I was surprised when Matzon referred to tick based being the problem. If Windows always returns a 1000 thats not a problem - 1000 ticks per second, meaning that each tick happens to be a millisecond on windows (unless of course you wanted submillisecond timing!)

Kev

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #9 - Posted 2005-11-14 18:58:48 »

Sorry but I don't unerstand your reasoning. Sys.getTimerResolution used to return the actual CPU ticks/sec and now whatever the CPU the game is running on it always returns 1000??? How such a value can be 100% accurate? Please explain me this.

About the referred SystemTimer class, it wraps the GAGE timer actually so there is no relationship with LWJGL Sys class. My goal is to use only LWJGL and no other third party lib.

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #10 - Posted 2005-11-14 19:02:11 »

getTimeResolution just refers to the resolution of the clock, which in the case of windows is 1000. It was previously a cpu dependent value but now it's a multimedia timer since there are BIG issues with using the old high performance timer.

Slightly confused here... - but I was answering to: "how do you handle movement timing if the fps drops below 60?"
No matter what timer you use, you will still have problems if you based your movement upon fps since slower fps = slower movement.
to solve that issue, you will have to use a time based movement instead, that is x units per y time elapsed.

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #11 - Posted 2005-11-14 19:09:33 »

Movement in my game is already time based. I just upgraded to version 0.98 and now I have 48-49 fps max instead of capped 60. I still don't understand how the change in Sys class can work as before. What kind of change do I need to do in my code?

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #12 - Posted 2005-11-14 19:33:57 »

if it is time based, I dont understand why you have issues with movement??
if you move x pixels given a time period, you should at the end of that period have moved just as far regardless if you're getting 60 or 0.001 FPS

As to why the framerate has dropped it might be because of some internal lwjgl changes - it would have to be benchmarked to identify

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #13 - Posted 2005-11-14 19:58:42 »

Below is what I do in my rendering loop. As you can see, there is a dependency on Sys.getTimerResolution() to calculate the actual time of the current frame. If Sys.getTimerResolution() used to return 1400 for example (don't remember the exact value) before 0.98 than that should explain the reason of the fps drop do you agree?

Maybe there is something wrong in it???

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  
    // Initializes rendering loop variables.
   frameCount = 0;
    long fpsCountTicks = 0;
    long actualFrameTicks = 0;
    long ticksPerSecond = Sys.getTimerResolution();
    frameTicks = ticksPerSecond / maxFps;
   
    startFrameTicks = Sys.getTime();
   
    Graphics2D g;
    running = true;
    while (alive) {
      // Make the Graphics2D object available before rendering.
     g = (Graphics2D) bufferStrategy.getDrawGraphics();
      Game2DContext.setGraphics(g);

      // Render all animation stuff.
     animation.render();
      if (animation.isCompleted()) {
        break;
      }

      // Paint the frame and render it.
     animation.paint();
      g.dispose();

      // Put the offscreen image to the screen.
     bufferStrategy.show();

      // Used to calculate fps.
     frameCount++;

      actualFrameTicks = Sys.getTime() - startFrameTicks;
      if (actualFrameTicks < frameTicks) {
        while (Sys.getTime() - startFrameTicks < frameTicks) {
          Thread.yield();
        }
        actualFrameTicks = Sys.getTime() - startFrameTicks;
        startFrameTicks = Sys.getTime();
      } else {
        startFrameTicks = Sys.getTime();
        Thread.yield();
      }

      // Update the current frame duration.  This will allow animations to calculate movements accordingly.
     Game2DContext.setFrameDuration(((float) actualFrameTicks) / ticksPerSecond);

      // Do the frame rate calculations.
     fpsCountTicks += actualFrameTicks;
      if (fpsCountTicks >= ticksPerSecond) {
        fps = frameCount;
        Game2DContext.setFps(fps);
        frameCount = 0;
        fpsCountTicks = 0;
      }
    }

Online kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #14 - Posted 2005-11-14 20:14:42 »

I don't think so. "frameTicks" is based on the resolution, so it will always be the number of ticks occuring in a second.

Kev

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #15 - Posted 2005-11-14 20:16:31 »

About the referred SystemTimer class, it wraps the GAGE timer actually so there is no relationship with LWJGL Sys class. My goal is to use only LWJGL and no other third party lib.

actually the SystemTimer class that comes with LWJGL doesn't use the GAGE timer!
http://cvs.sourceforge.net/viewcvs.py/java-game-lib/LWJGL/src/java/org/lwjgl/examples/spaceinvaders/
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #16 - Posted 2005-11-14 20:44:26 »

Do I have to put my glasses because I don't see a class called SystemTimer in the URL you gave me. The version of this class I checked was on Kevin's website. It embed an AdvancedTimer object, which is the GAGE timer. I guess that this version is not up to date to the latest LWJGL version.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #17 - Posted 2005-11-14 20:52:52 »

whoops could have sworn it was there, ok maybe i'm just getting old but here a quick copy paste

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  
public class SystemTimer {

   /** The number of "timer ticks" per second */

   private static long timerTicksPerSecond;

   

   /** A little initialisation at startup, we're just going to get the timer going */

   static {

      timerTicksPerSecond      = Sys.getTimerResolution();

   }

   

   /**

    * Get the high resolution time in milliseconds

    *

    * @return The high resolution time in milliseconds

    */


   public static long getTime() {

      // we get the "timer ticks" from the high resolution timer

      // multiply by 1000 so our end result is in milliseconds

      // then divide by the number of ticks in a second giving

      // us a nice clear time in milliseconds

      return (Sys.getTime() * 1000) / timerTicksPerSecond;

   }
}


then in the main game loop u can do

1  
2  
long delta = SystemTimer.getTime() - lastLoopTime;
      lastLoopTime = SystemTimer.getTime();


to get delta, which u can use with ur game entities
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2005-11-14 21:02:27 »

I'm not sure here what the confusion is all about??? You don't really even need to know what Sys.getTimerResolution() returns. You just need to look at the difference between now and then and divide by the resolution and that's the time that's passed between now and then in seconds. If your framerate is lower suddenly then it's nothing to do with the timer at all.

Cas Smiley

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #19 - Posted 2005-11-14 21:51:38 »

And what do you think about what I posted previously:

Quote
Below is what I do in my rendering loop. As you can see, there is a dependency on Sys.getTimerResolution() to calculate the actual time of the current frame. If Sys.getTimerResolution() used to return 1400 for example (don't remember the exact value) before 0.98 than that should explain the reason of the fps drop do you agree?

Offline tom
« Reply #20 - Posted 2005-11-15 02:02:17 »

Sorry but I don't unerstand your reasoning. Sys.getTimerResolution used to return the actual CPU ticks/sec and now whatever the CPU the game is running on it always returns 1000??? How such a value can be 100% accurate? Please explain me this.

getTimerResolution did only return the actual CPU ticks/sec on computers with multiple cpus/cores. It usually used another independant clock. But because of this bug it had the tendency to speed up/down on laptops with speedstep. Wich is why cas used timeGetTime() instead on the latest versions of LWJGL. It usually has a resolution of 1000, meaning it can returns 1000 unique number a second. But it is also buggered on some computers. The resolution can degrage to 10-15 ms wich makes it just as bad as System.currentTimeMillis(). This can explain what you are seeing. I suggest you mesure the real resolution on your computer. Do it by spinning in a loop and capturing the difference in the timer when it changes. Also, it performs badly when yielding in a loop. Instead use Thread.sleep(1). That might improve the resolution and fix the problem.

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #21 - Posted 2005-11-15 15:21:20 »

Yesterday I temporarily reimplemented my rendering loop with lwjgl.util.Timer class to see if it gives a better performance and it's exactly the same behavior. Also, I rolled back my lwjgl libs to 0.95 and replaced Thread.yield() by Thread.sleep(1) and it resulted in a loss of 10 fps so I don't understand why you are saying that sleep produces better results???

Offline tom
« Reply #22 - Posted 2005-11-15 16:25:10 »

Yesterday I temporarily reimplemented my rendering loop with lwjgl.util.Timer class to see if it gives a better performance and it's exactly the same behavior.
I'm not surprised as it uses the Sys.getTime() and Sys.getTimerResolution(), just as your code did.

Quote
Also, I rolled back my lwjgl libs to 0.95 and replaced Thread.yield() by Thread.sleep(1) and it resulted in a loss of 10 fps so I don't understand why you are saying that sleep produces better results???

When using timeGetTime() (LWJGL version 0.96 and above) you need to use Thread.sleep(1). With earlier version (0.95 and belove) yielding worked fine. It seems that timeGetTime() need there to be some free time available or it will choke, reducing it's resolution.

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #23 - Posted 2005-11-15 16:50:08 »

OK thanks for the useful info!  Smiley

I'll try sleep(1) with 0.98.

Stay tuned.

P.S. Just checked Unded arena. Have you done any progress recently since the last screenshot refers to May 2005?

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.

Riven (4 views)
2014-07-29 12:53:52

Dwinin (7 views)
2014-07-29 10:59:34

E.R. Fleming (20 views)
2014-07-29 03:07:13

E.R. Fleming (8 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (51 views)
2014-07-17 23:47:54
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!