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

Login with username, password and session length

 
Advanced search

998776 Posts in 39178 Topics- by 30587 Members - Latest Member: gemstar

April 20, 2014, 08:33:24 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Dealing with Stuttering - Java, Game Maker, and DirectX considered
Pages: [1] 2 3 ... 8
Print
Author Topic: Dealing with Stuttering - Java, Game Maker, and DirectX considered  (Read 14784 times)
lasttea999
Level 2
**



View Profile
« on: October 03, 2011, 05:59:13 PM »

Current solution??: LWJGL + extra thread fix (downloads have not been updated with this fix)

Also, smoothness achieved with C++ and DirectX!? Some updates to what I know:
http://forums.tigsource.com/index.php?topic=22054.msg822358#msg822358

Hello TIGSource,

I've been using Game Maker for quite a while, but recently I learned some Java in college so I've been trying to make a game engine in Java (relying further on tutorials and various other sources). Problem is, on some computers the graphics never get rendered as smoothly as, say, a GM game--- moving images sometimes stutter. I've been trying to figure out why this happens for a while now. Any ideas as to the cause?

EDIT: Here are some newer examples I prepared, most of which are different versions of the LWJGL example someone called Cero posted in a thread over at Java-Gaming.org. Most of the examples incorporate different examples of fixed timesteps from various sources.

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.

To make the programs, I drew on help from these and other sources:

Quote

I've been testing on three types of computers:

1) The computers at school, which run Windows 7. They seem to be very fast, and GM programs and the Java examples alike seem to run fine on them.

2) My 3 or 4 year old laptop, which runs Windows Vista. The Game Maker examples and the Java examples all stutter a fair bit, but it might be a bit better with the Game Maker program; it's a little difficult to tell.

3) Our desktop at home, which is newer than my laptop and runs Windows 7. The Java examples seem to have the most trouble on this computer, relative to the Game Maker example. However, the phenomenon is pretty inconsistent between trials (for example, sometimes the programs run more smoothly than on the laptop), and I don't really know what's behind the differences between different trials.

Potential causes:

1) Hardware. It could just be that the machines I test on are slow, but I doubt this is the case because as far as I know there shouldn't be much reason for them to be slow, and in any case that doesn't explain why GM games still run smoothly on them. It is true that GM games also display some stuttering on the same computers, but it's usually not as noticeable as the stuttering with Java.

2) My code. Of course I may have just written faulty code, but I think, if that were the problem, there probably wouldn't be so many existing discussions about the issue, would there? (Because people would just need one or two resources of this kind to solve their problem, and wouldn't have had these discussions for so long.)

EDIT: I am kind of a novice, though. I've been building my program from portions of various examples and tutorials; if there is an error in my code, it may be pretty likely that it comes from faulty implementation of the code from these various sources. Maybe I made an error in fitting all the different pieces into my target framework?

3) Sleeping and timers. This is the kind of problem discussed in this thread. The idea is that sleep() is unreliable, and/or that the precision of available timers is insufficient. Wasn't this latter problem solved by System.nanoTime(), though?

    a) Potential solution: Running a thread in the background the whole time. I've seen this work on at least one computer, but I think I've also seen it not do much another computer, and in any case it seems a bit hacky to me...

4) Something to do with waiting for vertical retrace. Here are some links related to this topic:

Quote

    a) Potential solution: A request for enhancement. I think some of us have heard that there are or were people trying to incorporate vsyncing capabilities (or something similar) into Java itself:

Quote

But as far as I know this hasn't been achieved yet. Do any of you know where this effort currently stands?

    b) Potential solutions with native code. The following links, one of them a JGO thread by Kevin Glass, claim to provide native methods to solve this:

Quote

But I haven't tried the first solution (I don't really know how to make it work...), and I suspect that the second one might be outdated. Does anyone know how to properly implement these solutions, or know if any current, equivalent solutions have been made, or could be made?

    c) Potential solution provided over in the XNA forums. Someone has apparently experienced similar problems with XNA, and has provided a supposed solution:

Quote

This may be a solution that can get around not having access to vsync, but I've had trouble understanding some of the XNA-specific code provided in the link. Does anyone know enough XNA to be able to try an equivalent solution in Java?

A Potential General Non-Solution: Maybe we're just being too sensitive to stuttering? Someone in the aforementioned XNA-related link commented:

Quote
Ignore the GPU clock, and let the CPU clock control the update frequency. Sure, this means you will occassionally have dropped or doubled frames, but as long as the clocks are roughly close, this will be rare, and the results are fine for many games. Especially, people tend to notice the time drift in very simple test apps where they are doing things like just moving a box across the screen one pixel per tick, so they freak out about this, but the artifacts tend to become less obvious as the game becomes more complex, so they are often no problem at all in the finished product. The nice thing about this mode is that it keeps your update logic nice and simple, which is why this is the XNA Framework default (we call it fixed timestep mode).

This sounds kind of plausible,  but I think there's one thing this doesn't account for: GM running more smoothly than Java.

Sorry for the long post! So, where does the future of this issue lie?
« Last Edit: November 30, 2012, 09:29:14 PM by lasttea999 » Logged

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


View Profile Email
« Reply #1 on: October 03, 2011, 06:10:32 PM »

I've never gotten things to look greater using java's built in renderer.  I would highly recommend slick if you want to use java...

http://slick.cokeandcode.com/

It's a 2d accelerated library built on LWJGL.  It's very simple and very fast since it means all the rendering is done on the graphics card.  It ran great even on my 5 year old laptop.
Logged
lasttea999
Level 2
**



View Profile
« Reply #2 on: October 03, 2011, 06:19:32 PM »

Thank you for your feedback. I have looked at Slick, and if I remember correctly the timing was similar to my program. And I've already mentioned that LWJGL rendering didn't seem to be much of an improvement... So maybe Slick does a better job of implementing those features in some fashion that I've overlooked?

I guess I'll have to test a game made with Slick. I wonder if it lets you adjust the number of logic updates per second, though; that's something I'd like to be able to do. Again, if I remember correctly, LWJGL's built-in features don't let you do that, so I used LWJGL rendering while using my own timing mechanism.
Logged

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


View Profile Email
« Reply #3 on: October 03, 2011, 06:30:28 PM »

Yeah I saw you had tried LWJGL but it's more complicated so there's more room to mess up.

I can give you something simple I made in slick+java a while ago if you want and you can see how that runs.  Probably easier then whipping up something yourself and you can figure out if rendering is the problem or not.
Logged
lasttea999
Level 2
**



View Profile
« Reply #4 on: October 03, 2011, 07:02:35 PM »

Thanks, that'd be great! Please note that detecting stuttering is easiest (at least as far as I can tell) when something moves horizontally at a constant rate.
Logged

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


a fool with a tool is still a fool


View Profile WWW Email
« Reply #5 on: October 04, 2011, 02:55:22 AM »

It's because of the fixed timestep. Smoother GameMaker games are looking more smoothly because they are not using vsync. If you run your game in variable step this problem will be solved immediately. Also there were recently threads around this issue some steps below, I recommend you to look them up.
Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
lasttea999
Level 2
**



View Profile
« Reply #6 on: October 04, 2011, 08:02:23 AM »

It's because of the fixed timestep. Smoother GameMaker games are looking more smoothly because they are not using vsync. If you run your game in variable step this problem will be solved immediately. Also there were recently threads around this issue some steps below, I recommend you to look them up.

Actually, I have been looking them up (and struggling to understand some of it), ha ha. I've been seeing your posts; I thank you for your feedback.

By variable step, do you mean that all movement is interpolated with a delta value? Come to think of it, (if that is what you're referring to) I think the guy who created (?) Slick2D does that too. Hmm.
Logged

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



View Profile WWW
« Reply #7 on: October 04, 2011, 08:33:01 AM »

The first thing I would do is to try and make an application that renders the minimal thing you need to notice stuttering. If there is no stutter there, then you need to profile\optimize your engine.
The second thing is, you need to learn how to profile\optimze a non native program. I don't know how to do it, but I know there are differences from C++ for example.
Logged

Master of all trades.
lasttea999
Level 2
**



View Profile
« Reply #8 on: October 04, 2011, 09:34:51 AM »

The first thing I would do is to try and make an application that renders the minimal thing you need to notice stuttering. If there is no stutter there, then you need to profile\optimize your engine.

Thank you, that sounds like it'd be illuminating. This will probably be an image moving back and forth at a constant rate.

The second thing is, you need to learn how to profile\optimze a non native program. I don't know how to do it, but I know there are differences from C++ for example.

Unfortunately I'm too much of a novice to have known that there was such a difference between C++ and Java. Does that have to do with higher- and lower-level programming languages, or something along those lines?
Logged

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


The Magical Owl


View Profile
« Reply #9 on: October 04, 2011, 10:04:36 AM »

Truthfully, you're asking too wide a question: "why is my graphics stuttering?". It can't be answered because it depends on the techniques you're using and the constraints of your platform, language and frameworks.

The best thing to do is look up the basic concepts and standard techniques behind computer animation and see if that helps, helps with tracing down the issue, or helps you ask more specific questions.

Especially look up:
* double buffering
* vsync
* java garbage collection
* hardware acceleration
Logged

\\\"There\\\'s a tendency among the press to attribute the creation of a game to a single person,\\\" says Warren Spector, creator of Thief and Deus Ex. --IGN<br />My compilation of game engines for indies
PompiPompi
Level 10
*****



View Profile WWW
« Reply #10 on: October 04, 2011, 12:26:09 PM »

I am afraid stuttering is not that straight forward to deal with. It can be quite complicated.
For instance, you might have "bursts" of CPU usage eventhough your overall CPU usage is well bellow 100% if you look at the task manager.
Logged

Master of all trades.
ஒழுக்கின்மை
Level 10
*****


Also known as रिंकू.

RinkuHero
View Profile WWW Email
« Reply #11 on: October 04, 2011, 12:45:04 PM »

just as a side note, vsync in game maker does not work. you actually get less screen tearing (and the game runs faster) if you leave vsync off. no GM game should every have vsync turned on
Logged

lasttea999
Level 2
**



View Profile
« Reply #12 on: October 04, 2011, 02:32:43 PM »

Thanks for the feedback, everyone!

It's because of the fixed timestep. Smoother GameMaker games are looking more smoothly because they are not using vsync. If you run your game in variable step this problem will be solved immediately.

just as a side note, vsync in game maker does not work. you actually get less screen tearing (and the game runs faster) if you leave vsync off. no GM game should every have vsync turned on

Wait, so variable time step => no vsync? I guess I haven't researched vsync enough to know exactly what it is, although I have seen it pop up quite often in discussions... Doesn't that only come into play when dealing with fullscreen graphics, though? Also, I had thought vsync was supposed to be helpful, but here it sounds like that's not quite the case?

Also, it seems like the majority of articles I've read about fixed and variable time steps tend to favor the fixed option over the other (EDIT: kinda hard to tell). Could it be possible that my problem lies not in the time step itself, but in the interpolation of graphics?

Truthfully, you're asking too wide a question: "why is my graphics stuttering?". It can't be answered because it depends on the techniques you're using and the constraints of your platform, language and frameworks.

Good point. I do know that at least one of my builds (and I think the other build may be using it under the hood (?), too), and I think Game Maker also uses double buffering. Still trying to figure out vsync, as seen above.

The reason I haven't been more specific, by the way, is that I didn't want to get too far into the Java details on a forum that deals not with Java in particular but with games in general... which may lead you to ask why I'm posting here at all, and the answer to that is that I didn't really want to bring up Game Maker and game loops in general in a Java-specific forum. Also, I'd like opinions from outside the Java community.
« Last Edit: October 04, 2011, 09:05:50 PM by lasttea999 » Logged

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


a fool with a tool is still a fool


View Profile WWW Email
« Reply #13 on: October 04, 2011, 03:18:56 PM »

You can use vsync in variable step. The speed of your game-loop will be locked to your screen. This is ideally the best thing you can do to achieve silky smooth movement and a clean (not teared) picture in addition. Nearly all the big shooters are running in this game-loop, the main reason to turn off vsync is to give the game significantly better performance in worst case situations.

However note that a 120hz screen is not a 60hz screen. Your game will potentially run faster the higher the refresh-rate of your screen. It means that you need to scale all the movement in the game according to the elapsed time between each gameloop-call to keep the game-speed constant.

The problem is obviously just the fixed timestep, no garbage-collector, no performance...
simply because its rate can never exactly match the screen-refresh-rate, from time to time either a game-frame is overjumped (running faster than refresh-rate) or the same game-frame is drawn twice (running slower than refresh-rate). Whenever (usually frequently) one of these situations occur you see a jump, that's all there is to it.
« Last Edit: October 04, 2011, 03:28:37 PM by J-Snake » Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.

Super Metroid Tournament: http://forums.tigsource.com/index.php?topic=38039.0

TrapThem: http://steamcommunity.com/sharedfiles/filedetails/?id=222597670
lasttea999
Level 2
**



View Profile
« Reply #14 on: October 04, 2011, 05:26:50 PM »

The problem is obviously just the fixed timestep, no garbage-collector, no performance...
simply because its rate can never exactly match the screen-refresh-rate, from time to time either a game-frame is overjumped (running faster than refresh-rate) or the same game-frame is drawn twice (running slower than refresh-rate). Whenever (usually frequently) one of these situations occur you see a jump, that's all there is to it.

I certainly hope this is the case. What's your opinion on fixed time steps with graphical interpolation, though?

By the way, GM seems to offer a level of predictability that I think is based on a fixed time step--- the user deals with "step events", and I've rarely seen a delta value being used with movement. I've never used one myself, and my GM games seem to run just fine.
Logged

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

Theme orange-lt created by panic