[SOLVED] Sim-eth-es frametime stutter / rendering hiccup

I couldn’t find a solution here on the forums, so here goes:

In my game, I experience rendering hiccups, or frametime stutters. It’s based on Sim-eth-es - and the hiccup is there in the version on Github without modifications (picture from @pspeed’s Simsiilica example):

Any idea what’s causing this? I tried profiling but did noget get anything to show for it. It becomes increasingly noticably when you move around.

When you say “or” could you verify the latter via logging?

Without thinking: stuttering and freezing screams garbage Collector freezes

I’d agree with the GC cause. But I wouldn’t know how to ‘fix’ it. There’s nothing going on in the Example game except the game loop. There’s no logic, no creating things :slight_smile: I’m new to optimizing java applications - what key words do I google ? :smiley:

How would I tell the two apart by logging - I dont know what to log - do you mean a printout of the tpf on client?

The stutter is in the tpf as well (not sure what that tells me though - here taken from the ModelStateView)




Both and or one at a time I guess. Maybe even set the logger level to debug or something. Knowing Paul he already did the hard work.


Well, ask the right things to get the right answer :stuck_out_tongue:

  1. Run the Memory Profiler and see what the memory does. Most of the time this is resolved by setting a higher heap size (-Xmx) so the GC has to be run lesser times.
  2. If this doesn’t help (the stuttering only occurs later / rarer) you would have a memory leak, in Zay-ES this always is not calling the .cleanup() on an EntitySet
  3. You could change the GC to an implementation which does not stop the program from executing (ConcurrentSweepGC), however that is much work to fine tune stuff which might not help if 1. or 2. are the cause

Keywords would be GC Freeze or something

Tried creating a gradle.properties in project folder and setting:

org.gradle.jvmargs=-Xmx3g -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

no luck.

That’s a server side issue, right?

Normally I would say a networking issue… but then I wouldn’t expect to see jumps in JME’s tpf like that.

The other thing would be GC as folks have mentioned… but GC shouldn’t be an issue in this app and others seem to run it fine, I guess. (Some even base whole games on this starting example.)

Next thing I guess is just to verify that something else isn’t stealing CPU from your app periodically. As a last resort, you can try rebooting the OS or something to see if that fixes it.

Wait… I may have made in incorrect assumption. Which tpf were you logging?

The client side inModelViewState

Saw a thread here that mentions the same issue (though without the picture its hard to say for sure):

Also tried without luck:

applicationDefaultJvmArgs = ["-Dgreeting.language=en -XX:+UseConcMarkSweepGC -Xmx4000m -Dfile.encoding=UTF-8 "]

in the build.gradle file.

Did I include debugging HUDs in sim-eth examples? I know you can popup the normal JME GPU stats (from that other thread) but I don’t know if I included any network graphs.

…the original app I based this on used to have a frame timing graph for the networking.

Edit: looks like “not”.

Edit: looks like “not not”… F7 will open the network timing debug view.

Yes, I included a picture in my opening statement :slight_smile:

Perhaps not surprising, the issue is more apparent on larger resolutions.

All of the graphs seem to indicate that it is rendering related… and this kind of confirms it. I wonder if other JME games exhibit the same issue at high resolutions if you are micro-watching the frame timings.

Sim-eth examples will be sensitive to render burps because of how it’s timing things, I guess.

Sorry… I missed it because it was clipped in the forum-included part and super tiny.

Do you have an nvidia card by chance?