? But in your code render is always called, while update is called every n frames. That makes render faster. 
CopyableCougar4
So let me see if I understand this correctly, if the fps is 30, the logic should render at 30*1, or rather just thirty, and if it is 60, then it would be 60, and so on and so forth?
If you have a logic thread and a render thread, you can save yourself oodles of time.
For each thread, you call Sync.sync(fps for thread). The sync class I speak of is https://github.com/LWJGL/lwjgl/blob/master/src/java/org/lwjgl/opengl/Sync.java. I know this sounds weird, but I have tested it. I call Display.sync(fps) in my rendering thread and Sync.sync(fps) in my logic thread.
Example (trimmed down):
private Thread rendering = new Thread("Rendering"){
public void run(){
...
while(active){
...
Display.update();
Display.sync(Settings.RENDER_FPS);
} catch (OutOfMemoryError e) {
Log.print(e);
active = false; // If there's no memory left, stop the game.
}
}
System.exit(0);
}
};
private Thread logic = new Thread("Logic"){
public void run(){
while(active){
...
Sync.sync(Settings.LOGIC_FPS);
...
}
}
};
Just a thought
CopyableCougar4
See my edit.
[icode]n = desiredFPS / desiredUPS[/icode]
So, if FPS is 60, and you want logic to run at 30, then you run logic every other frame. (n = 2) If you want logic to run at 60, then itâs every frame. (n = 1)
If your FPS is 120, then double those n values.
Unless you donât know what to do and what to not do when multi threading, then you give yourself nightmares and hair loss.
This isnt true at all.
Really, youâre going to want to use as many separate threads as possible. Its the best way to take full advantage of the processor.
? Just creating as many objects as possible is useless. âIts the best way to take full advantage of the processor.â? Wouldnât you just waste time creating useless thread objects?
CopyableCougar4
Registered 16 mins ago.
So essentially, if logic at 60 and render at 60 = [icode]if (count == 60 / 60)[/icode]?
Try it out:
http://pastebin.java-gaming.org/f8efa97700a1c
Note that no matter the FPS set, the ball moves the same speed. (aka the update() method is called the same number of time per second)
You can use a delta time very well in your entity updates. Assuming delta is in miliseconds:
float delay = 1000;
public void update(float delta)
{
// Every second tick
delay -= delta;
if (delay <= 0)
{
// Move entity, or something that should be done every second (1000 ms).
delay += 1000;
}
}
This is the only workable solution, really. Making game world updates independent from graphics rendering speed (or the speed of your computer) is a quite difficult topic, but there are some basic solutions that work well as a starting point. R4king, for example, posted a nice loop some time ago:
http://www.java-gaming.org/topics/about-on-my-main-loop/26222/msg/229028/view.html#msg229028
Some good reading on this is the âFix Your Timestepâ article by Fiedler. It describes several ways from simple to complex to fix this problem.
[quote=âCopyableCougar4,post:23,topic:51057â]
What problem does your proposed solution solve? Using threading for something like this is generally a Very Bad Idea. In your solution the properties of entities may change while the rendering is performed, potentially leading to graphical glitches (rendering half the entity at one positon, the other half at another) and even worse, crashes (if some data is altered but other not yet leading to invalid state).
[quote=âGrunnt,post:31,topic:51057â]
Include a method in your entities to return the state of the entity at the time the method was called, call that method at the start of performing the render, and store all the returned values from the entities in an array.
If you donât want to create another array for all the entity states, try including a lock/unlock method in the entities, and call those methods at the start/end of the render loop.
[quote=âradar3301,post:32,topic:51057â]
Okay, I can see how that could work with some effort. However, this all sounds needlessly complicated and certainly not a performance gain: deep copying all entities each loop is not free, and rendering speed is mostly done on the GPU anyway.
[quote=âradar3301,post:32,topic:51057â]
So the update thread waits for the rendering thread and the rendering thread waits for the update thread. Which turns this into an extremely complicated way to do exactly the same thing as just a single thread performing update and render, or am I missing something here?
Also, neither solution solves the problem posed by the OP: how to make movement independent from framerate.
Well, I was thinking something more along the lines of
class Entity {
float x, y;
float lockedX, lockedY;
void lock() {
lockedX = x; lockedY = y;
}
void render() {
GraphicsObject.drawWhatever(lockedX, lockedY);
}
}
class RenderThread {
void render() {
for (Entity e : entities)
e.lock(); // lock the entity
for (Entity e : entities)
e.render(); // render the entity
}
}
I hope thatâs understandable. Looking at it now, I suppose itâs a rather unwieldy with the multiple for loops, but the locking code shouldnât take too long, and while rendering is happening, updates to the entityâs position can still occur without glitching the graphics.
Another thought I just hadâŚ
I was once trying to build a (somewhat accurate) physics simulator for projectiles/particles, but I was getting frustrated since the framerate dropped when I was rendering a lot of them. After thinking about it for a while, I decided upon this solution (forgive me if I didnât fully expand the threads properly, this was just a quick 10 minutes) :
http://pastebin.java-gaming.org/efa701a8c0714
Thatâs literally just a (messily done) deep copy.
Itâs still not thread safe at all.
To which snippet are you talking about?