Hi there. Ive built my project as an applet, but its FPS is running ultra fast , but it runs normally when i execute it via jMonkey.
is there anything i can do ? Im using GameApp for my main class.
Thanks alot for the help !
1 Like
First time I hear someone complain about a game running too fast. 
“jMonkey” you mean SDK maybe?
it is running faster propably becouse of build scheme. FPS could run faster too, if you use assets while loop
when you run it via SDK it load assets from folder(not jar) as i good know, but i might be wrong.
applet/distribution versions have assets in jar, and it depends how this assets are compressed/etc.
so i think this is it 
yh quit ur bitching
Is it just that the FPS count is high, or are you not using tpf as you should be for animations/movement?
ty for the attention
im using the standard update() method from GameApplication, and using simpleUpdate() to update graphics
so , i dont think im using tpf… im still a newbie i want the game to run on a normal 60 fps
@Ziden said:
so , i dont think im using tpf... im still a newbie i want the game to run on a normal 60 fps
use tpf.. or use LittleBigPlanet to create your game.
1 Like
your game will run at different speeds on different machines. (faster hardware, etc.)
That is why there is a Time Per Frame float passed into the update methods. This is measured in seconds since the last frame. You use it to control your movements/animations.
So if you have something with a moveSpeed of 3, then each frame when you move it, you multiply moveSpeed by 3 (moveSpeed*3). This ensures that it is relatively the same visually on all machines you run your game on.
Sorry i dont got it 
Any tpf tutorials ?
Best to get a book on basic game design and how game engines work. It is fundamental to developing a game.
This tutorial (http://www.hub.jmonkeyengine.org/wiki/doku.php/jme3:beginner:hello_main_event_loop) might help, but I do suggest reading more on the subject.
1 Like
@Ziden: Maybe it sounds harsh but the guys are right. You should read some tutorials about real-time-engines. This is not jme-specific. Every movement, every turn, every progress has to depend on your Time-per-Frame-counter. Otherwise your game will run unpredictable on every machine.
Ive read something about it. Ive understood the time per frame is going to change, so i have to perform frames in a slower/speedyer rate, but how im going to work this around with my code ? Couldnt find a plain solution.
Will i change every movement action ? Thanks alot guys for giving attention for tha noobie
ive read those tutorials, didnt got what to do
i was searching for a simple snippet so i can understand what u are talking about.
ty for the attention
Example pseudo code:
[java]// Speed in units per second
Vector3f moveSpeed = new Vector3f(1,0,0);
[…]
public void simpleUpdate(float tpf) {
if(moveForward) {
Vector3f newPosition = player.getLocalTranslation().add(moveSpeed.mult(tpf));
player.setLocalTranslation(newPosition);
}
}[/java]
That way the player model moves as far as the set speed would take it during the time elapsed that is described by tpf (time per frame).
1 Like
Tumaini said:
Example pseudo code:
[java]// Speed in units per second
Vector3f moveSpeed = new Vector3f(1,0,0);
[...]
public void simpleUpdate(float tpf) {
if(moveForward) {
Vector3f newPosition = player.getLocalTranslation().add(moveSpeed.mult(tpf));
player.setLocalTranslation(newPosition);
}
}[/java]
That way the player model moves as far as the set speed would take it during the time elapsed that is described by tpf (time per frame).
.. as explained in tutorial 4 :D
hmmmmmmmm ill try it
this would make me remake aloooooooot of classes… ive build an animation system based on frames, dang.
sry double
The hacky way would be to get
At start of loop
start = System.currentTime()
end of loop calculate the missing time to archive 60fps and sleep for that long.
The game would slowdown then on slower than 60fps hardware however.
@Ziden said:
this would make me remake aloooooooot of classes… ive build an animation system based on frames, dang.
get used to it, having to rewrite a part of the code during the process is normal. ...and don't take that suggestion from Empire serious ^^