jME3 Oddity on specific system

Hello!



I mostly do development on a laptop running on a Core 2 Duo with nVidia Quadro 1600 FX graphics. Everything I run on the laptop seems to run correctly and without issue (or at least, without issues with jME3 ;p). However, sometimes I decide to mess around on my home desktop with the same code and get strange results with some of the calculations. The desktop is a Core 2 Duo with nVidia 8800GT graphics, running the latest drivers (thought that would fix it because I was running a set of drivers that was several months old, but no change), and the latest nightly build which would’ve been Nov21 when I last tested this.



The issues I’m having on my desktop are a little hard to describe. It’s most obvious when using the flycam. Most of the time, the flycam will move extremely slow, however the mouse looking aspect of it is unchanged and operating the same as the laptop. Now, when I say extremely slow, I mean that the default movespeed of 1 is literally a crawl in comparison to movespeed 1 on my laptop. I had to set it to over 100 and it was closer to the normal rate. Now, to be more specific when I say “most of the time,” occasionally (less than 10% of the time) the flycam will start to move the correct rate. It happens in little bursts but it’s noticeable if you spend enough time moving around.



Somewhat related, is that most of the time the desktop is pushing ~1600 fps according to the standard on-screen statnode. Again, most of the time, I can’t tell for certain, but it spikes up to double that occasionally, and it might be related to the bursts of speed stated above.



For the mostpart, all I can tell is that it affects the flycam. There was some strangeness with one of my programs with the tpf making one of my movement vectors really small and it was also causing some issues there, but I’m not sure if it’s related or not.



I’m sorta lost as to how to debug this. I thought for a moment that maybe the tpf float is just getting REALLY small and causing calculation problems, but then why am I the only one with this issue (that I’m aware of, didn’t catch it on searches). My desktop is hardly what I would call fast by today’s graphic standards, so it must be something else.



Any ideas would be appreciated!



~FlaH

When the FPS goes above about 1500 or something it might be the tpf value gets inaccurate which might result in different behaviour.

I’m guessing it would be wise to throw in frame rate caps on everything then to keep it below ~1500? I think the usual for my laptop is around ~1100 so that could explain it.



Or make tpf a scary double! (Ya right) =p



~FlaH

Well, fps capping is always good manner to not overuse the system (especially for low profile games where it can do high fps)

Yeah, I’d planned to eventually use it everywhere anyway once I settled on a good number. I was flipping it on and off in a few programs while I was learning to keep spatial movement independent of the framerate. Though, now that I’ve got a handle on that, I should just start making it a habit to fps cap programs.



Also saves my ears since I can actually hear the transistors resonating on the board when it’s running full blast! =p



Thanks!

~FlaH

tehflah said:
Also saves my ears since I can actually hear the transistors resonating on the board when it's running full blast! =p

If thats really true your system is doomed to die soon ;) I hope for you its the vents ^^

Its kind of strange since on my PCs I go over 1500 fps regularly. I am guessing it might have something to do with the high-precision timer, if its not really as accurate in representing time as it claims to be you might have speed changes with the flycam.