Introduction to javafx game development efficiency

Disclaimer: the original articles of this blog are all personal originals and are copyrighted. For more information, see http://blog.csdn.net/ml3947. for more information, visit http://www.wjfxgame.com.

I haven't written a blog for a while, but everything is going on in an orderly manner.

The efficiency of the javafx-based game engine wjfxgameengine has been optimized during this period of time (examples of personal blogs have not been uploaded again), simple 2D games, the fastest running speed on my PC can reach-FPS. The following is a brief introduction to some basic issues in javafx game development.

Anyone who has read the official javafx game example brickbreak can find that the game's rendering and logic are carried out in timeline. Based on my experience, the timeline in javafx is not very efficient and will be very slow if there are too many timeline instances. In my game engine, the current simple animation is implemented using timeline and will be changed in the future.

In addition, in the previous tutorial, the simple game framework of javafx is also about timeline. This is actually a serious problem. This is misled by official javafx examples.

Currently, my change is to use dual threads, one thread to process plotting, and one thread to process update operations (this is also a common practice of many game engines, such as android game engine andengine ). Of course, the painting process must be run in javafx mainthread, so we use platform. runlater to call the painting operation. Although it is still executed in the main thread, the update drawing speed is significantly faster. In the previous javafx game examples, bullet freezing and other scenes often appear, but not now.

The following is the sample code:

drawThread = new Thread(new Runnable() {@Overridepublic void run() {while (isRunning) {try {Thread.sleep(waitTime);} catch (Exception e) {}Platform.runLater(new Runnable() {@Overridepublic void run() {draw(getGraphicsContext2D());}});if (fpsMaker != null) {fpsMaker.makeFPS();}}}});updateThread = new Thread(new Runnable() {@Overridepublic void run() {while (isRunning) {try {Thread.sleep(waitTime);} catch (Exception e) {}update();}}});

This is the code in my wscreen class.

When the thread waits for a lower waittime, the faster the FPS.

Another problem arises when the FPS is faster. Because of the frequent update operations, if you still use the move (4) method in the update and other operations, you will find that the speed is very fast.

In addition, because FPS is not stable, we will find that the running conditions on different computer configurations vary greatly. In this way, we will use another concept of deltatime.

Deltatime records the time from the last update. Every time we move the speed * deltatime, we can move at a rate not affected by the frame rate.

Of course, deltatime has this concept in almost all game engines or frameworks, such as the Microsoft xNa game framework I used before and the unity3d development I am working on.

You can see that the FPS reaches 751, and the same example has better solved the choppy problem caused by previous efficiency.

Due to my limited level, this part is for reference only. Graphics can be encapsulated at a layer. In the future, if the efficiency is insufficient, other OpenGL and other packages can be used.

Reprinted please indicate the source: http://blog.csdn.net/ml3947