Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
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   
  Show Posts
Pages: [1] 2
1  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2012-01-29 23:20:10
libGDX has a JOGL and LWJGL backend for desktop.

yes, so it would be interesting to see libgdx using JOGL syncing a gameloop @ 60 fps, if libgdx has a sync method, which I would guess it does
although most people will argue that it wont make a difference; just curious though

Yeah, I'm also wondering about issues like this, and whether engine-specific native code yields any significant difference in efficiency or speed. But I guess those are questions we could ask about any engine, not just libGDX. Anyone know the specifics?
2  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2012-01-29 02:19:20
...Wait yeah, you've brought up a good point: LWJGL, for example, uses native code, too! Hence the DLL. Oops. Thank you for the input, pitbuller.
3  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2012-01-29 01:30:19
Wait, I looked a little bit into libGDX: apparently it uses some C/C++ (= "native code"?)? Anyone know the details of what that does for libGDX?
4  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2012-01-28 20:54:39
No, I haven't. Is it pretty widely used?
5  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2012-01-25 22:56:24
Yeah, so with the computers I've tested, the only computer on which I get stuttering even after applying the extra sleeping thread method is the computer on which the Game Maker example stutters. How has the GM example been running for you?

Also, I suspect that the stuttering only seems to get worse with less going on--- in other words, it's just less noticeable with more going on, and doesn't actually yield stuttering any less. But I haven't really tested this guess precisely.
6  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2012-01-18 23:13:47
Thanks for the input, Cero! It's been a while since I've visited this topic, ha ha.

Have you tried the "extra sleeping thread" method? It seems that the fix:

- has no effect on computers that yield little stuttering anyway,
- reduces most stuttering on the computer I tested that yielded the most stuttering, and
- has no effect on my laptop, on which the GM test program and my programs all stutter.

Note that I haven't updated the downloads with this fix.

By the way, although I had known about that fix from when this thread was started, it seemed too inelegant. Eventually, I decided to incorporate it into my programs.
7  Game Development / Newbie & Debugging Questions / Re: Can't Launch Game jar on: 2011-11-24 21:36:17
I don't really know how all of this works, but what works for me is putting the relevant DLLs and JAR libraries in the same folder as the exported JAR.
8  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-21 22:15:23
FRAPS tells it like it is Smiley

Cas Smiley

Well, I think I'll have to look into it more to be able to use it?

---

Two things:

a) You know, I think I'm just going to incorporate the "extra sleeping thread" fix; with it, at least three of the Java examples seem to work just fine, as far as I can tell so far. The Java examples still stutter on my laptop, but so does the Game Maker example. Note: the download has not yet been updated.

I still feel that this solution is a bit inelegant, though. The extra thread forces the program to use a more precise (?) timer, right? Does that mean that functions like System.nanoTime() become more precise, that Thread.sleep becomes more precise, or both? I'd like to think that it's Thread.sleep; it would be nice to know that the timing, at least, is always reliable.

Does anyone know why the reliability of Thread.sleep would be so conditional (?)? Will they ever make it so Thread.sleep always behaves as it does with this solution?

b) Before incorporating that solution, though, something strange happened on my laptop: it started acting like our desktop for a moment! That is, the Game Maker example seemed to run more smoothly than usual, and some if not most of the Java examples were less smooth than usual and couldn't maintain 60 FPS. The programs started to behave as normal after I restarted the computer; this sometimes works on my desktop. Thus, it seems to me that there are (at least) two common computer settings, one in which Game Maker and Java behave similarly, and one in which Game Maker gets less stuttering than usual but in which Java gets more. What could be the cause of this?
9  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-19 20:36:09
Install FRAPS demo and report the FPS.

Cas Smiley

Wait, isn't the FPS reported by the program enough?

---

I updated the box.com download with a new example. If I understand correctly, it's a sort of hybrid between Cas's example and Eli Delventhal's. I'm not sure if it's any smoother than any of the other Java examples, but there's at least one new thing being done here.

I noticed that Cas's example can loop many times without CPU problems. I think this means that, even if one of these example programs loops many times, the CPU only starts groaning if it also renders very fast (although it seems that the CPU still starts groaning if the looping is too fast). I tried looping like this in the hybrid example because it seems to me that, since the program checks the time more often, the timing would be more precise.

Also, I incorporated Eli Delventhal's timing method but applied it not only to logic updates but also to the rendering, which amounts, if I understand correctly and if I'm using the right terms, to making logic and rendering almost completely independent of each other in a sense. Put another way, they're each sort of on their own schedule.

Again, I can't really tell if all this allows the program to run any better than any of the other examples, but there it is anyway.

Here's some of the relevant code:

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  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
public void start() {
      try {
         Display.setDisplayMode(new DisplayMode(800, 600));
         Display.create();
      } catch (LWJGLException e) {
         e.printStackTrace();
         System.exit(0);
      }
     
      initGL(); // init OpenGL
     
      vsync = false;
      dsync = false;
      wait = true;
      drawInterpolated = true;
     
      timerResolution = 1000000000;
      updateRate = 60;
      renderRate = GraphicsEnvironment.getLocalGraphicsEnvironment()
            .getDefaultScreenDevice()
            .getDisplayMode().getRefreshRate();
      if (renderRate == java.awt.DisplayMode.REFRESH_RATE_UNKNOWN) renderRate = 60;
     
      double updateInterval = timerResolution / (double) updateRate;
      double renderInterval = timerResolution / (double) renderRate;
      double lastFPSTime = System.nanoTime();
      double lastUpdateTime = lastFPSTime;
      double lastRenderTime = lastFPSTime;
      int updateCount = 0;
      int renderCount = 0;
      int loopCount = 0;
      updatesPerSecond = 0;
      rendersPerSecond = 0;
      loopsPerSecond = 0;
      maxUpdates = 5;
     
      Display.setVSyncEnabled(vsync);
     
      while (!Display.isCloseRequested()) {
         double now = System.nanoTime();
         int localUpdateCount = 0;
         while (now - lastUpdateTime > updateInterval && localUpdateCount < maxUpdates) {
            update();
            lastUpdateTime += updateInterval;
            localUpdateCount++;
            updateCount++;
         }
         if (now - lastUpdateTime > updateInterval) {
            lastUpdateTime = now - updateInterval;
         }
         now = System.nanoTime();
         if (now - lastFPSTime > timerResolution) {
            lastFPSTime = now;
            //lastFPSTime += timerResolution;
           updatesPerSecond = updateCount;
            rendersPerSecond = renderCount;
            loopsPerSecond = loopCount;
            updateCount = 0;
            renderCount = 0;
            loopCount = 0;
            Display.setTitle(updatesPerSecond
                  + ", " + rendersPerSecond
                  + ", " + loopsPerSecond
                  + "; VSync: "+ vsync
                  + "; Display.sync(): " + dsync
                  + "; Interpolated drawing: " + drawInterpolated
                  + "; Yield and sleep: " + wait);
         }
         interpolation = (float) ((now - lastUpdateTime) / updateInterval);
         now = System.nanoTime();
         if (now - lastRenderTime > renderInterval) {
            renderGL();
            Display.update();
            //lastRenderTime = now;
           lastRenderTime += renderInterval;
            renderCount++;
         }
         while (now - lastRenderTime > renderInterval) {
            lastRenderTime += renderInterval;
         }
         loopCount++;
         if (dsync) {
            Display.sync(60); // cap fps to 60fps
        } else if (wait) {
            Thread.yield();
            try {
               Thread.sleep(1);
            } catch (Exception e) {}
         }
      }
     
      Display.destroy();
   }
10  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-11 21:48:02
Wait, I thought the wrapping was achieved later in the code by something like:

1  
if (now < then) { }


O_______O

...Yes?

More observations (although... note that most if not all of my observations throughout both the TIGForums thread and this thread are basically subjective...):

Recently I seem to have observed that the GM example actually stutters more than I had thought. I think it's usually better than the Java examples and all around GM's the most consistent, but currently I suspect that:

-When GM stutters it can be more noticeable than some Java implementations? Especially on (only on?) those computers on which LWJGL's vsync can take effect.

-GM usually tends to run smoothly for longer periods of time than the Java examples, but not? on those computers for which the Java examples don't stutter (i.e. my school's computers). Furthermore, on those computers GM seems to alternate between no stuttering and stuttering more frequently than the Java examples.

Also, another issue: While the simple GM example stutters on those school computers, I had difficulty detecting any stuttering (there was some stuttering, but very little of it) with the demo for a game of mine, Platform Battle 2. In fact I think this might also have been the case during some trials on our desktop (although Java stutters on it). This may have something to do with the implementation:

-With the simple example, nothing is scaled and the box is moved at 2 pixels, whereas, in PB2, although the object I observed (a moving platform in the tutorial) still moves at 2 pixels, the graphics are scaled to two times its "actual" size by a method by ChevyRay.

-PB2 uses a sprite for the platform and has a patterned background. (I do, however, think that I looked pretty closely...)
11  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-11 10:30:55
Sys.getTime() & 0x7FFFFFFFFFFFFFFFL

The L indicates the value is a long integer (64 bits).
The bit-and operation sets the sign bit to zero, assuming that the long is signed. Thus the getTime value is guaranteed to be positive. Maybe you knew that and the question is why it would be necessary to reset the sign bit?


No, I didn't know that; thank you for the explanation. Again, I'm kind of a novice... Please bear with me!

So is it basically a faster way of doing abs(x), or something along those lines?
12  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-11 09:17:42
Added three new examples based on code by Cas, Notch and Tommy: box.com download (Note: haven't tested these much yet)

Still haven't made it so the programs detect the refresh rate of the display.

A question for Cas, if it's alright to ask: In your code, how does the following code work? How is it different from calling just Sys.getTime?

1  
Sys.getTime() & 0x7FFFFFFFFFFFFFFFL
13  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-08 00:19:06
Oh yeah and go ahead, all my code is public for a reason.

Cas Smiley

Thank you!!!

That being said, I think at least one particular setting on one example may yield suitably smooth rendering all around: example_delventhal.zip without Display.sync, with yield and sleep, and without frequent yield and sleep. It still stutters with those settings, but, if I'm not mistaken, it only stutters a little more than does the Game Maker example.

Looks like I spoke too soon:

I had already known that, sometimes, our desktop (which usually yields the most visible stuttering) runs the Java programs I've been testing pretty well for some reason; but only for a while, and in a currently unpredictable manner. Even the Java2D builds run smoothly in this situation! It seems that this had been the case when I was testing my LWJGL examples earlier, because yesterday they seemed to yield lots of stuttering... Looks like I might try to give Cas's method a go!

EDIT:

Quote
Admittedly, I don't know how this setting fares on a computer on which vsync works; it may have to be turned off on such computers. But then again, on such a computer, vsync might yield smooth rendering on its own.

Looks like the program runs just fine under these particular settings, at least as far as I can tell.

By the way: currently, the only way I know how to test if vsync has an effect is to turn off Display.sync (and frequent yielding and sleeping) and see if toggling vsync does anything. On my school's computers the FPS drops from several hundred (without vsync) to 60 (with vsync), whereas on our desktop and my laptop the FPS seems to stay at several hundred regardless of the state of vsync reported by the program.

Also, I'm still not really sure about the following point:

Quote
I guess it's also possible that the smooth rendering that seemed to be achieved with vsync on the computers at my school could only have been achieved with the speed of those computers (they seem pretty fast).

In other words, I don't know if my programs might still yield stuttering on other computers for which vsync has an effect; it could just be that, as usual, the main reason my programs run smoothly on my school's computers is that they're fast (or more powerful in some other fashion).
14  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-06 23:23:17
Just another thing worth mentioning: not all monitors run at 60Hz - some will be 72hz or 75hz etc. This will screw your timing unless you change the display mode to 60Hz.

Cas Smiley

Ooh, good point. I think I do know of a way to get the default refresh rate, though; I wonder if that will be enough to accommodate this issue. Also, I found something you posted at lwjgl.org in 2010, Cas; it's contained in the following forum thread:

EDIT: That's strange, for some reason I can't get the link to work... The title of the thread is "Timer Comparison."

Would it be alright if I made a new example (as in, add another new member to my examples download) based (heavily) on your method?
15  Game Development / Game Mechanics / Re: Scaling a 2D game ? on: 2011-11-06 06:40:44
Fake Scan Lines: We Make Things Look Worse (tm)

WHY?!

Nostalgia, probably. I've seen pixel artists do cool things with scan lines. Currently can't find any of the pieces I've seen, but.
16  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-06 05:34:16
Hello everyone, it's been a while!

So currently I know of at least 10 different versions of the fixed timestep loop--- all from various sources, some of those sources being examples of code that people have submitted here--- so I prepared three different versions of the LWJGL example Cero posted, each of which incorporates one of the different fixed timestep code examples.

I've bundled together those examples in a single download, along with some other example programs (like a similar Game Maker example) and the source for all the different examples. You can download it here: box.com download

Note: example_simple.jar and example_variabletimestep.jar are examples without fixed timesteps; they're there for comparison.

There are various settings you can toggle within the JARs, like vsync and the usage of Thread.yield and Thread.sleep. More details are contained in the included readme file.

Here's what I discovered:

-With certain settings, the stuttering can be improved pretty well on all tested computers (at least one school computer, our desktop, and my laptop).

-Rendering as fast as possible seems to yield fairly smooth graphics, but it seems that our desktop and my laptop have difficulty with that kind of rendering (I can't tell if it's difficult for the computers at my school).

-I finally saw that LWJGL's vsync actually does have an effect, and yields some of the smoothest rendering I've seen yet! (That is, with Java.) ...However, although this smooth rendering was achieved on a computer at school, it doesn't seem to work on our desktop or my laptop. In fact the API documentation for LWJGL says:

Quote
[About Display.setVSyncEnabled:] This call is a best-attempt at changing the vertical refresh synchronization of the monitor, and is not guaranteed to be successful.

That being said, I think at least one particular setting on one example may yield suitably smooth rendering all around: example_delventhal.zip without Display.sync, with yield and sleep, and without frequent yield and sleep. It still stutters with those settings, but, if I'm not mistaken, it only stutters a little more than does the Game Maker example.

Admittedly, I don't know how this setting fares on a computer on which vsync works; it may have to be turned off on such computers. But then again, on such a computer, vsync might yield smooth rendering on its own.

EDIT: I guess it's also possible that the smooth rendering that seemed to be achieved with vsync on the computers at my school could only have been achieved with the speed of those computers (they seem pretty fast).
17  Game Development / Game Mechanics / Re: Scaling a 2D game ? on: 2011-11-06 05:14:53
For pixel art I like nearest-neighbor interpolation, which, I think, is the kind of scaling where every pixel becomes 2 pixels big.
18  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-02 20:45:27
Saucer, I even wrote a tutorial (!) about a gameloop using fixed timesteps for updates and required tweening for rendering.
Unfortunately it's for BlitzMax but of course the principle works the same regardless of the programming language (and BlitzMax has most OO features you'd require).

The tutorial can be found here: http://www.rightanglegames.com/topdownshootertu/index.html. The game loop is based on stuff you'll find at Gaffer's blog.

The code can easily be converted to Java and Slick. I would suggest you create your own AppGameContainer subclass where you implement your own game loop using the mechanisms above.
I guess this would be the cleanest way to introduce a different update/render behavior into Slick.

Hope that helps,
Tommy

Ah, my apologies. Thank you for the tutorial! If I remember correctly I've seen this tutorial before, but I didn't look too closely at it because it was for BlitzMax. If I find an opportunity, I'll see if I'll be able to convert it to Java successfully, and report back with results!
19  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-02 01:24:00
Saucer, your Slick2D example doesn't make much sense for the idea of Slick IMHO. Way too complicated.

Slick basically works by calling update() and render() in a loop. The time spent between the previous and the current update call is passed in milliseconds as delta. That's it. Update your positions by multiplying with a factor and the delta and you're done.

You can finetune Slick by switching on vsync, setting a target frame rate, delta smoothing, minimal and maximal update time and so on.

But basically I would start simple.

Give the games in my signature a try: they are all done with Slick, the source code to all those games is available on my website or part of MarteEngine. See if they stutter that much that you consider them unplayable or annoying (stuttering wise, not gameplay  Tongue).
SpiderTrap is completely based on calculations using the delta value. Back to the past and StarCleaner use a target frame rate of 60.

Don't overcomplify things - try to get some games done  Grin

Cheers,
Tommy

Thank you for your advice, Tommy, but I'm specifically trying to avoid using that style of updating. Do you know the distinction between fixed and variable timesteps, or about making the physics framerate independent? I'm trying to implement fixed timesteps (independent physics), and that's (sorta?) what's causing the stuttering.

EDIT: I guess I could try to fix the delta on Slick's terms--- as, after further consideration, I think you may be suggesting--- by using various features such as minimal and maximal update time, but I feel that that would be too indirect; in other words, although the raw code seems more complicated, in the end it sounds to me like trying to incorporate a fixed timestep directly would be a lot simpler than trying to force Slick's internals to make a fixed timestep out of a variable timestep.

EDIT EDIT: Ah, this looks sort of promising:

Quote

Somehow I get the impression that setting both the min and the max to what I want (and thus achieving fixed timesteps?) will be a little less robust than directly doing it myself, but that remains to be seen. Also, I wonder if those functions only take integers...? An update rate of 60 updates per second corresponds to an interval of not exactly 16, nor exactly 17, right... I guess I'll still have to try similar things with LWJGL, but without Slick.
20  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-01 15:54:30
Slick does not use Display.sync() by default. You can switch it on by setting a target frame rate but it's off by default.

See method updateAndRender() in class GameContainer and method gameLoop() in class AppGameContainer.

Just be careful what example code you copy to start with  Wink

Cheers,
Tommy

Thank you very much; I guess I'll give Slick2D another go too, then. Has anyone looked at or tried the Slick2D example I posted, by the way? Here it is again:

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  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
@Override
    public void update(GameContainer container, int delta)
            throws SlickException {
        double now = Sys.getTime() * 1000000000.0 / Sys.getTimerResolution();//*/
       int updateCount = 0;
         
        //Do as many game updates as we need to, potentially playing catchup.
       while(now - lastUpdateTime > timeBetweenUpdates && updateCount < maxUpdatesBeforeRender) {
            innerUpdate();
            lastUpdateTime += timeBetweenUpdates;
            updateCount++;
            updatesPerSecondCount++;//
       }
         
        //If for some reason an update takes forever, we don't want to do an insane number of catchups.
       //If you were doing some sort of game that needed to keep EXACT time, you would get rid of this.
       if (now - lastUpdateTime > timeBetweenUpdates) {
            lastUpdateTime = now - timeBetweenUpdates;
        }
 
        interpolation = Math.min(1.0f, (float) ((now - lastUpdateTime) / timeBetweenUpdates));      
         
        //Update the frames we got.
       int thisSecond = (int) (Sys.getTime() / Sys.getTimerResolution());
        if (thisSecond > lastSecondTime) {
            updatesPerSecond = updatesPerSecondCount;//
           updatesPerSecondCount = 0;//
           lastSecondTime = thisSecond;
        }
         
        deltaDisplay = delta;
    }
     
    public void innerUpdate() {
        for (int i = 0; i < positions.length; i++) {
            positions[i] += directions[i] * (SPEED * i + SPEED);
            if (positions[i] <= 0) directions[i] = 1;
            else if (positions[i] >= DEFAULT_WIDTH) directions[i] = -1;
        }
 
        for (int i = 0; i < positions.length; i++) {
            lastPositions[i] = positions[i];
        }//*/
   }
 
    @Override
    public void render(GameContainer container, Graphics g)
            throws SlickException {
        //double now = Sys.getTime() * 1000000000.0 / Sys.getTimerResolution();//*/
       g.scale(DEFAULT_SCALE, DEFAULT_SCALE);
        g.setColor(Color.lightGray);
        g.fillRect(0, 0, DEFAULT_WIDTH, DEFAULT_HEIGHT);//*/
       g.setColor(Color.red);
        for (int i = 0; i < positions.length; i++) {
            int x;
            if (drawInterpolated) {
                x = (int) ((positions[i] - lastPositions[i]) * interpolation + lastPositions[i]);
            } else {
                x = (int) positions[i];
            }
            for (int j = 0; j < 2; j++) {
                //g.fillRect(x, HEIGHTS[j] + 16 * i, 16, 16);
               sprite.draw(x, HEIGHTS[j] + 16 * i);
                //fonts[j].draw(":)", x, HEIGHTS[j] + 16 * i - 16);
           }
        }
        g.setColor(Color.white);
        g.drawString("Hello, Slick world!", 16, 100);
        g.drawString("Delta: " + deltaDisplay, 16, 116);
        g.drawString("Updates per second: " + updatesPerSecond, 16, 132);
        g.drawString("Sys.getTime(): " + Sys.getTime(), 16, 148);
        g.drawString("Sys.getTimerResolution(): " + Sys.getTimerResolution(), 16, 164);
        g.drawString("" + Sys.getTime() * 1000000000.0 / Sys.getTimerResolution(), 16, 180);
        g.drawString("Interpolation: " + interpolation, 16, 196);
        /*interpolation = Math.min(1.0f, (float) ((now - lastRenderTime) / timeBetweenUpdates));
        lastRenderTime = now;//*/

        /*for (int i = 0; i < positions.length; i++) {
            lastPositions[i] = positions[i];
        }//*/

    }
21  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-11-01 03:16:30
My game loop would work fine for LWJGL. Slick2D handles the game loop for you.

Alright, I'll try it some time; but again, I think we were saying that Display.sync(60), which I think Slick2D uses for its gameloop, causes stuttering.
22  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-31 20:57:35
EDIT:

@Saucerking - and how about you, with my games? Any stuttering (windowed/fullscreen)?

Cas Smiley

Haven't tested yet, sorry!

Use Slick2D. It should get you started much quicker than fiddling with glBegin()/glEnd() in pure OpenGL.

I tried, but I still got stuttering, remember? Sad Also, doesn't Slick2D use Display.sync(60)? Don't quite know how to use its features without using one of its GameContainers.

Quote
I remember how hard it was to get texture loading and rendering to work in the beginning.

I don't think I'll have to worry about this; when I tried LWJGL, I used a texture loading method provided in one of Kevin Glass's tutorials.

Quote
I've been thinking about putting together a tutorial for detecting, diagnosing and preventing stuttering, both Java specific problems and general problems related to the graphics pipeline. I get the feeling my mile-long posts are being a little bit ignored here, so I'm wondering if anyone would find that useful, or think that someone else (newbies?) would find it helpful/interesting. I'm thinking of splitting it up into three main parts: Detecting stuttering (finding out if your program stutters), diagnosing stuttering (find out what causes it) and finally preventing/fixing it. Thoughts?

I would find it useful, but seeing as I, being kind of a noob, haven't quite gotten how to detect, diagnose and prevent stuttering after reading your posts (albeit in a rush), perhaps you could make your tutorial be a more concise and dumbed down version of your posts.

EDIT: Anyone care to demonstrate a smooth fixed timestep loop in either LWJGL or Slick2D?
23  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-30 23:40:01
Thank you, ra4king, for your loop code, and thank you everyone in general for your continued feedback!

Well, I guess I will try implementing LWJGL again, then, but I probably won't be able to work on that for a while. In the meantime, please feel free to keep the discussion going! Perhaps someone else could try their own hand at producing a smooth "bouncing box" example using all of this new information?

If the stutter is still unacceptable because you're wasting hours sitting with a high-speed camera recording a bouncing box running at 1 pixel per update through a microscope instead of actually making your game, you've done what you can on this side of the hardware, and the only thing you can do is enable VSync, which is just Display.setVSyncEnabled(true); =D

I appreciate the hyperbole, but know that the stuttering seems to make the version of my test program with more than just bouncing sprites actually seem pretty legitimately unplayable on my desktop... (with GM still running just fine)
24  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-30 21:56:21
Java2D is slow. LWJGL is a native binding to OpenGL, which means you can directly access the graphics card. Slick2D has a Java2D-like API but uses LWJGL underneath, so it's fast for relatively small games.

OpenGL has several hundred times more performance than un-accelerated Java2D (the OpenGL acceleration for Java2D is unreliable in my experience). It also gives you access and control over the only thing that will solve the stuttering that you experienced with Cero's example, VSync. You'll also have to use something more accurate than Display.sync(60) though, but that's a wheel that has already been invented.

I see. Well, if I can't use Java2D and can't use Display.sync(60), what would the game loop look like with a fixed timestep? Would I just use Display.update() in the place of g.dispose() and strategy.show()? What if it still stutters? Any possibility of providing example code for a loop? I'm curious as to how you all go about doing this, because, if I remember correctly, when I tried LWJGL I got more stuttering than with Java2D.
25  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-30 21:03:15
(Was JGO down for a bit?)

<Link to GM stutter test>
I think it stutters exactly the same way as Cero's bouncing box, but it's almost impossible to see because 1. it doesn't use just a box and 2. they aren't moving at 1 pixel per update.

Good point, I might make another example like that.

Quote
Just use LWJGL. xD

That's what Cero's example uses, right, and it still causes stuttering. Is it better than Java2D? I don't think we've determined that quite yet. Also, would Slick2D be a suitable equivalent option?

Because Swing is a GUI library, not a graphics library. If you want to use GUI items like buttons, menus, etc... then use Swing. Otherwise, it's an unnecessary overhead.

Is it? It seems to produce more stutterfree graphics... Shocked

I see. I thought I observed more stuttering with Paint than with BufferStrategy, personally.
26  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-30 01:11:43
That's true. However, in the two examples you posted on the TIG forum you let the user choose, before the application launches, if he wants to use Double buffering or not...  right? o.O

Ohhh yes, you're right. Sorry, I'd forgotten that the stuff I posted on TIGSource is a little older; the build I'm currently testing on my own doesn't use Type 2 (Paint) anymore. I think Type 1 (BufferStrategy) should still be relevant, though, although I did refactor stuff a bit.

I would argue that the GM game and your Java examples with Double buffering produce the same quality of stuttering.

Wait, really? I guess this may be the case on my laptop, but on our desktop there seems to be quite a difference. Note: I still have yet to test on my university's computers.
27  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-30 00:43:17
Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

I exp lots of stutter of the slow moving characters, I think this is because of rounding errors and could easily be fixed by enabling interpolation in GM. (In Game Options inside GM)

The high speed ones, ( like the one at the bottom ) is really smooth. However, I do believe, by careful examination, that it experienced stuttering as well. But very little compared to the two Java versions you posted (on the TIG forum). Using double buffering on your Java programs, however, reduced the stuttering phenomenally ( as you would expect ) and I would argue that the GM game and your Java examples with Double buffering produce the same quality of stuttering.

This was all tested on my laptop (notebook really).

Also I'm certain GM uses fixed timesteps. At least GM7 and anything prior did. Therefore GM8 probably does too.

Thank you for your feedback. You say "using double buffering"... Isn't that something that the programmer uses? Like, with the BufferStrategy class? Game Maker and my Java programs all should be implementing double buffering whether the player likes it or not...
28  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-30 00:38:13
Care to drop a link or create a program that is exactly the same to this one but made in Game Maker?

Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

This example actually DOES stutter on my laptop... ha ha. But I had already observed a little bit of that going on; I have yet to test it on our desktop, on which the differences seem to be most apparent between GM and Java. Specifically, on my desktop GM seems to run more smoothly than on my laptop, and Java seems to run less smoothly. I'll try to report on that later.

So I tested this on my desktop and there is some stuttering, but I *think* it happens less often than with Java. When it does happen in the Game Maker example, it seems to be a slightly different sort of stuttering; it's more... "minuscule"? And the stuttering in Java is more "jarring." Also, it seems that my Java programs have a harder time maintaining an (reported) FPS of 60 (that is, on my desktop; on my laptop 60 FPS is usually maintained, I think).

Has anyone else tested the GM example?

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

Basically: PC Game Programming and Console Programming are very different things. When programming for a console you know the exact hardware and it will be the same hardware every time - this allows you to write very low level code that works perfectly with this hardware - but not at all with other hardware.

Which is why I would rather program console games Grin

John Carmack said this even about Rage, that it was easier to get Rage running at 60 fps on the consoles than it was on the PC, because of the way ID Tech 5 and especially Mega texture uses the memory, and that pc drivers for memory and video card are written so that they work with many different things - which doesnt allow, what he always calls "aggressive high performance operations" - because of too much driver overhead

By the way, I'm totally going for an SNES/GBA sort of feel with the stuff I want to make. I can understand that the programming would be different between consoles and PC, though. I wonder if Nintendo will ever support indie games.
29  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-29 23:54:03
Care to drop a link or create a program that is exactly the same to this one but made in Game Maker?

Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

This example actually DOES stutter on my laptop... ha ha. But I had already observed a little bit of that going on; I have yet to test it on our desktop, on which the differences seem to be most apparent between GM and Java. Specifically, on my desktop GM seems to run more smoothly than on my laptop, and Java seems to run less smoothly. I'll try to report on that later.
30  Game Development / Newbie & Debugging Questions / Re: Solving Stuttering With Fixed Timesteps, Once and For All on: 2011-10-29 23:10:32
Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering:
 - Better sleep precision than what we have right now.
 - Newer more advanced game loops and delta handling than those in the game loop thread.
 - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

For all I know, this may be the case; but, if so, and it really does only matter on the hardware, then there's still the ever-present question: Why are Game Maker games fine?

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

I can't currently test this right now, but if I remember correctly I didn't see any stuttering. However, it was a little difficult to be sure if there was or wasn't any stuttering/tearing. This is because (again, if I remember correctly) the gameplay is pretty fast, it's all vertical movement, and the movement isn't at constant speed, and all of those factors make it harder to see if there is or isn't stuttering.

EDIT: ra4king, perhaps you could make one of those sprites-moving-side-to-side examples with your method? Also, could you perhaps post your game loop and rendering code?
Pages: [1] 2
 

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

The first screenshot will be displayed as a thumbnail.

BurntPizza (25 views)
2014-09-19 03:14:18

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

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

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

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

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

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

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

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

Longarmx (40 views)
2014-09-07 01:10:19
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!