Ok, so I installed latest JDK7 (x64) on my desktop (W7x64, i7-2600k, GTX570, so not netbook) and the speedtest only gets me about 880 typical (varies between 875-900) and I get VERY slight stutters at times (every 5-10 seconds really) when I move around. In the "shmup" I get solid 999-1000 obviously (disabling the sleep it goes from 1300-3500 or so.. which seems a bit weird to be honest), but even then I get some stutter that feels like a GC.. but testing with -verbosegc actually seems to indicate that (1) I get stutters (small ones) much more often than the GC actually runs and (2) GC doesn't actually cause any noticeable stutter on this system..
So I did a bit of debugging:
Code: Select all
private void update()
{
counter++;
// When this branch is taken, I get stutter for few frames
// it's a bit random how bad it is, but it's noticeable
if( (counter & 255) == 0 )
{
TurretBehavior turretRotateBehavior;
Note that I also tried running 3 of them next to each other, and they all run 1000fps next to each other, and all stutter on that branch (independent of each other).
Looking at the code, there's some allocations going. You might want to avoid creating turret behaviors (and turrets and enemies and so on) as separate classes and use static data arrays as much as possible, also for turrets and enemies and everything; yes it does make code less OOP and uglier, but it would avoid having to call "new" which is only "obvious" red flag that I see there (or in the methods called). I checked (well tried at least) with test code against Math.random() doing something stupid, and it seems fine and safe. Still, GC collections actually don't cause a stutter, so maybe it's not allocs but something else hiding there that didn't catch my eyes (rest seem like rather reasonable state setup code).
Anyway, depending on how fast you're planning to go with the bullet speeds, it's not necessarily terrible for a slower game. With current bullet speeds though, it's certainly annoying. Also no idea if this is the stutter that you are talking about, but.. it's certainly weird (pretty much only sensible explanation would be heap lock during Java2D's D3D backend thread JNI calls, or some such similar thing, but even that seems a bit far fetched). Tried various heap tuning command line options too, but couldn't get any improvement. "jstack" shows that's using D3D for rendering here.
Well, don't know if this was of any use.
