Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411412 Posts in 69360 Topics- by 58415 Members - Latest Member: sophi_26

April 15, 2024, 10:56:38 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Dealing with Stuttering - Java, Game Maker, and DirectX considered
Pages: 1 ... 4 5 [6]
Print
Author Topic: Dealing with Stuttering - Java, Game Maker, and DirectX considered  (Read 41858 times)
Chromanoid
Level 10
*****



View Profile
« Reply #100 on: November 12, 2011, 12:56:12 PM »

The effect of interpolation should be more visible if your visible framerate is faster than the update rate or out of sync. Currently you use 60hz for updates and drawing which decreases the need for interpolation.
Logged
rivon
Level 10
*****



View Profile
« Reply #101 on: November 12, 2011, 02:15:15 PM »

Well I have a (somehwat) fast computer and vsync has worked always AFAIK. Athlon X2 @ 2.9GHz + GF 9600.

And, of course not using 'sleep' causes stress on the CPU because it just computes and draws and stuff all the time. Cause the apps are written like that. That's why you limit FPS. So it doesn't do it all the time.
Logged
lasttea999
Level 2
**


View Profile
« Reply #102 on: November 12, 2011, 10:21:05 PM »

The effect of interpolation should be more visible if your visible framerate is faster than the update rate or out of sync. Currently you use 60hz for updates and drawing which decreases the need for interpolation.

Ah, thank you. Please forgive my ignorance!

Well I have a (somehwat) fast computer and vsync has worked always AFAIK. Athlon X2 @ 2.9GHz + GF 9600.

And, of course not using 'sleep' causes stress on the CPU because it just computes and draws and stuff all the time. Cause the apps are written like that. That's why you limit FPS. So it doesn't do it all the time.

Yup! Thing is, Slick2D seems, by default, to draw very fast, so I don't know why I'd have problems with doing the same in LWJGL. I haven't really observed how computers react to Slick2D games, though.

---

Well, I can think of a few more things we could try, but... I dunno. If we really have ruled out all those possible causes we've encountered so far, then I don't know what the problem could be. Is it really just that Game Maker involves more "native" code (am I expressing that accurately?) than Java, as I think someone mentioned earlier in this thread? Does Java do too much under the hood, as a TA at my university (I think) once told me? Does C++, Flash or Python fare any better?

What's strange to me about this problem is that it seems too fundamental and well-known a problem for us to have gone this long without having had someone pop in and say, "Oh, we dealt with this ages ago, everyone knows how to deal with that! Here's your solution!" Are we overlooking something completely ordinary here...?
Logged

Geeze
Level 5
*****


Totally.


View Profile
« Reply #103 on: November 13, 2011, 12:03:39 AM »

Java does garbage collecting on background - maybe that's one of the reasons? I'm also working on a slick2d project but in a very very early stage so I can't say a thing about stuttering.
Logged

rivon
Level 10
*****



View Profile
« Reply #104 on: November 13, 2011, 05:19:33 AM »

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. So I'm sticking with pos = velocity * dt; :D
Logged
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

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

Chromanoid
Level 10
*****



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

gnat
Level 1
*



View Profile WWW
« 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

LAN Party List - The definitive LAN party list. Also Game Jams, etc.
GitHub
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

lasttea999
Level 2
**


View Profile
« Reply #113 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: June 22, 2017, 06:56:02 PM by lasttea999 » Logged

Pages: 1 ... 4 5 [6]
Print
Jump to:  

Theme orange-lt created by panic