Essentially plan everything in number of seconds it should take. Whenever you do anything you multiply the amount you would move in a second by tpf to get the amount you should move that frame.
Using framerate to control gameplay used to be common in 80s/90s games but as hardware moved on and became more varied the limitations became obvious and no serious game works that way these days.
hmm this is giving me some headache… why isnt it good to use Empires method, to update based on time ?
All my game is procedural, the animations are procedural and frames are built frame by frame. Every normal game frame is a new animation frame, example of an animation:
http://code.google.com/p/the-dungeon/source/browse/trunk/Epics/src/Animation/Animations/ChestBounce.java
So to solve this i would need to remake all the animation system, or to use a if(isTimeToUpdate()) on the simple update method. I can say every X milisecs i update, but this wouldnt work on slower times that ive build in… dang !!!
i liked the animation system, ill try making animations have a circle runtime… idk
So what that means is if I would run that game of yours I would most likely be incapable of playing because of high frame rate. I have a GTX 480 Hyperclocked, The higher the FPS, the faster your game will “play”.
This explains the problems with various game loop strategies and isolates the one you should never do (which is the one you are using).
http://www.koonsolo.com/news/dewitters-gameloop/
The other strategies are all valid and have their place. The article is selling the benefits of one strategy but tbh they all have their merits. The important thing is that your animations should play in constant time whatever your games frame rate is. Taking one step/opening a door/jumping/etc all takes the same amount of time whether it is displayed over 50 frames or 1 frame.
1 Like
very very good article ill try it later !! But now ill have to work for a little ! ill be back onto JDK later hehe
Really, check our wiki and read it start to end, its a great path we cut into the game development jungle for you with lots of links into deeper woods on it.
doing it, thanks
I know this is a dead topic but also along with using tpf. In my applets I use the constructor to set the settings of my application this would solve the 60 fps you said you are looking for.
[snippet id=“40”]
@skidrunner said:
I know this is a dead topic but also along with using tpf. In my applets I use the constructor to set the settings of my application this would solve the 60 fps you said you are looking for.
Just do not make your applications framerate dependent, its the most basic noob error in game coding really.
The problem is ( probably ) that you are running it with Vsync enabled when you launch it from the SDK, this is causing your FPS to be maxed at 60hz. Try to disable vsync on the start up screen when you launch your app - this will show you that there is no difference between your applet and your app.
And you really want to understand the example that Tumaini posted above, that’s where the magic happens.
Ps: I still remember when I was playing games as a kid on my parents 486. Most games didn’t compensate for TPF, it was AWESOME! Just turn off the PC’s “turbo”, and it was permanent bullet time - Oh yeah!
@nihal said:
Ps: I still remember when I was playing games as a kid on my parents 486. Most games didn't compensate for TPF, it was AWESOME! Just turn off the PC's "turbo", and it was permanent bullet time - Oh yeah!
Ninja Gaiden on 486 instant death. :)
@skidrunner said:
Ninja Gaiden on 486 instant death. :)
Yeah, "North and South" would only work properly on a 386/16MHz PC ^^ They were used to code for the C64 and Amiga500 xD As said, noob mistakes ;)