Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

877206 Posts in 32849 Topics- by 24292 Members - Latest Member: DeviantYoda

May 18, 2013, 08:36:52 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Dealing with Stuttering - Java, Game Maker, and DirectX considered
Pages: 1 ... 6 7 [8]
Print
Author Topic: Dealing with Stuttering - Java, Game Maker, and DirectX considered  (Read 10731 times)
lasttea999
Level 2
**



View Profile
« Reply #105 on: November 19, 2011, 12:47:32 PM »

My apologies for the late replies, folks.

Java does garbage collecting on background - maybe that's one of the reasons?

I think someone somewhere mentioned that they used some program or other to check the garbage collector, and didn't find much wrong?

Quote
I'm also working on a slick2d project but in a very very early stage so I can't say a thing about stuttering.

Tell us what happens!

Well, the stuttering in cas, delventhal and gafferongames was big like 5-10px which means that the framerate dropped dramatically (high frametime) so something processor-heavy must have happened - just like if GC has kicked in or something. But when nothing like this is happening, then all the examples behave quite equally IMO (at least 90% equally) so really the different timesteps aren't behaving much differently.

When you say "all the examples behave quite equally," does that include the Game Maker example...?? ...Maybe?  Beg

---

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:

Code:
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();
}
« Last Edit: November 19, 2011, 01:17:14 PM by lasttea999 » Logged

Vertex: Exploration platformer by iMoose
HARA HARA DUEL: Dueling game
Solving stuttering: fixed timesteps
rivon
Level 10
*****



View Profile
« Reply #106 on: November 19, 2011, 04:06:39 PM »

Well, the stuttering in cas, delventhal and gafferongames was big like 5-10px which means that the framerate dropped dramatically (high frametime) so something processor-heavy must have happened - just like if GC has kicked in or something. But when nothing like this is happening, then all the examples behave quite equally IMO (at least 90% equally) so really the different timesteps aren't behaving much differently.

When you say "all the examples behave quite equally," does that include the Game Maker example...?? ...Maybe?  Beg
Yes? Dunno what you mean exactly.

Maybe one thing - probably the cas, delventhal and gafferongames don't stutter, maybe its really just something CPU-heavy in the background happening which freezes the game for a moment. That would mean that notch and chromanoid are bad...
Though whatever the case, GM, simple, variablestep and tommy are the best.
Logged
lasttea999
Level 2
**



View Profile
« Reply #107 on: November 21, 2011, 02:14:11 PM »

Yes? Dunno what you mean exactly.

I was asking if, when you said "all the examples," you meant that the Game Maker example also behaved pretty similarly to the Java examples when nothing dramatic was going on.

Quote
Maybe one thing - probably the cas, delventhal and gafferongames don't stutter, maybe its really just something CPU-heavy in the background happening which freezes the game for a moment. That would mean that notch and chromanoid are bad...
Though whatever the case, GM, simple, variablestep and tommy are the best.

Thank you for your continued feedback!

---

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 GM 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?
« Last Edit: November 21, 2011, 04:28:37 PM by lasttea999 » Logged

Vertex: Exploration platformer by iMoose
HARA HARA DUEL: Dueling game
Solving stuttering: fixed timesteps
Chromanoid
Level 7
**



View Profile
« Reply #108 on: November 21, 2011, 02:47:45 PM »

Regarding the sleep issue this http://stackoverflow.com/questions/824110/accurate-sleep-for-java-on-windows and this http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks (linked in the former link Smiley) might be interesting.
Logged
rivon
Level 10
*****



View Profile
« Reply #109 on: November 21, 2011, 03:36:22 PM »

Yeah, they behaved equally in the sense that they were all smooth. Mostly.
Logged
lasttea999
Level 2
**



View Profile
« Reply #110 on: November 21, 2011, 03:57:49 PM »


Edit: Wait, so are there drawbacks or risks to forcing usage of the more precise timer?

Ahhh are they ever going to fix this?? Also, what's your experience with the extra thread solution, Chromanoid?

Yeah, they behaved equally in the sense that they were all smooth. Mostly.

Cool! Thank you.
« Last Edit: November 21, 2011, 04:20:42 PM by lasttea999 » Logged

Vertex: Exploration platformer by iMoose
HARA HARA DUEL: Dueling game
Solving stuttering: fixed timesteps
gnat
Level 1
*



View Profile WWW Email
« Reply #111 on: April 19, 2012, 12:49:47 AM »

Just wanted to say that the first post of this thread is a goldmine on this topic, especially the source examples. Thanks. Smiley Even though this is an old thread it deserves a bump.
Logged

nc-cms - Open source, lightweight, and fast website content management for indies.
Woot Events - Gamer event listing site. LAN Parties, Game Jams, etc.
lasttea999
Level 2
**



View Profile
« Reply #112 on: April 19, 2012, 09:42:26 AM »

Just wanted to say that the first post of this thread is a goldmine on this topic, especially the source examples. Thanks. Smiley Even though this is an old thread it deserves a bump.

Hey, thanks for the feedback! I hope that this thread has been useful, and that its information is accurate. Couldn't have compiled this information without help from many sources, including the various internet articles and forums I consulted and the help I got directly from forum-goers, such as those at Java-Gaming.org and at TIGForums.
« Last Edit: April 19, 2012, 09:51:35 AM by lasttea999 » Logged

Vertex: Exploration platformer by iMoose
HARA HARA DUEL: Dueling game
Solving stuttering: fixed timesteps
lasttea999
Level 2
**



View Profile
« Reply #113 on: July 04, 2012, 11:44:28 PM »

So it's been a while and I haven't really looked into any of the following information, but it looks like the latest update to LWJGL (LWJGL 2.8.4) has a new change that may be related to the topic of this thread. From the changelog at lwjgl.org:

Quote
2012-03-24 00:04  kappa1

   * src/java/org/lwjgl/opengl/Display.java,
     src/java/org/lwjgl/opengl/Sync.java: Replace Display.sync(int
     fps) with an even better implementation, special thanks to Riven.

Here's a forum thread I found that seems to be discussing this update: click here
Logged

Vertex: Exploration platformer by iMoose
HARA HARA DUEL: Dueling game
Solving stuttering: fixed timesteps
lasttea999
Level 2
**



View Profile
« Reply #114 on: November 30, 2012, 08:09:06 PM »

So it's been a while (again), but recently I've been trying C++ and DirectX. For now, I've settled on a Japanese library that uses DirectX, called something like "DX Library", and I've been getting smoothness that I hadn't even DREAMED of! (At least, in windowed applications. I don't think I've really tested fullscreen applications yet.)

There still seem to be some issues with this library and fixed timesteps--- in fact, I think I've settled on a method based on some code on the DX Library site that some people may not consider a true fixed timestep--- but my test programs so far even run smoothly on my laptop! Although, I guess it's possible that it's my (previous) fixed timestep code that's faulty, and not the library.

I should note, by the way, that I've mostly only been testing on laptops, and the only tested computer that seems to have a problem with my test programs is our desktop. (For some reason, my test programs using DX Library almost always run at 61 FPS, even though the monitor says it's going at 60 Hz, I think? Maybe my FPS-measuring code is faulty? Or perhaps the desktop's timer?)

Also, please note that my using DirectX means that those programs are meant to run mainly on Windows computers.

The reason I decided to try out DirectX is that I finally found some games that didn't seem to stutter on my laptop, and was told that those games used DirectX. Cave Story and Hanano Puzzle are two such games.

I *think* what enables the smoothness may be vertical synchronization. Isn't there any way that vertical synchronization can be achieved in Java or OpenGL, in windowed applications?
« Last Edit: November 30, 2012, 09:27:20 PM by lasttea999 » Logged

Vertex: Exploration platformer by iMoose
HARA HARA DUEL: Dueling game
Solving stuttering: fixed timesteps
Pages: 1 ... 6 7 [8]
Print
Jump to:  

Theme orange-lt created by panic