nope - game should have lower priority than any device drivers.
Games should be high priority, and drivers realtime (soft).
Besides - winmodems is something satan spawned - they must be slayed!!!
FPS should always always always be capped to monitor refresh rate at the most, as any more is simply wasting power because no-one can actually see it. And 50 seems to be what’s needed for that ultra-slick smooth feel of the C64 and Amiga.
Hey, anyone remember Gods? That ran at half frame rate 
Beautiful graphics but didn’t half feel slow after all the other games…
Cas 
[quote]FPS should always always always be capped to monitor refresh rate at the most, as any more is simply wasting power because no-one can actually see it.
[/quote]
Can’t disagree with that, now where is that Thread.wakeOnVblank().
[quote]And 50 seems to be what’s needed
[/quote]
but, you just said fps should be capped at monitor refresh, so why would you want to cap it at 50?
[quote]for that ultra-slick smooth feel of the C64 and Amiga.
[/quote]
memories are always forgiving when it comes to fps 
can’t say I ever played that 1, /me trundles off to an abandonwares site…
Whoops, forgot we’re all at 60Hz these days
50’s what us Europeans got.
Cas
first lemme say that i’ve seen a literal 160fps, and when objects move quickly it really isn’t a waste. maybe i just thought it was cool. ;D
ok. the unreal engine has always used time-based updates since its early days. i’m in favor of time-based updates because, although they might make physics shakier if managed badly, everything gets asymptotically more accurate as framerate increases. and that’s just the easy way to do it. if acceleration is taken into account and velocity is viewed as inconstant over a period of time (an elapsed frame), then the only difference between a high framerate and a low framerate is how often the game is affected by the user and the AI.
the other end of this is that tick-based updates will always behave the same because fps is not a factor. if frames can’t be drawn fast enough, then you can skip some, and the game still behaves the same.
i wonder, though, if maybe a threaded approach might work best? if the world was updated at a high rate like 100Hz, and the renderer was a separate thread that just fetched its updates when it was ready, you could have tick-based gameplay and an arbitrary framerate.
No! No! No! No! No! Must I explode before anyone understands!cYou do NOT WRITE MULTITHREADED RENDERING CODE! I dunno whether I can be arsed to explain it again so I think I should write a FAQ about it. Hehe.
Cas
[quote]Whoops, forgot we’re all at 60Hz these days
50’s what us Europeans got.
Cas
[/quote]
umm - are you talking TV or monitor?
I assume you are talking TV, cos the last time I used a monitor that had a refreshrate <70Hz, it gave me a headache 
Both TVs and monitors back in them days were 50Hz! And yes, they’re pretty evil on the eyes. Strange how you only notice when you try and use one again.
Cas
Cas: I’m currently having a thread for each triangle in my 3d shooter. Each triangle is then given a dynamic priority depending on how close it is to the camera. Then all triangles will do
while (true) {
synchronized (this) {
Renderer.display(this)
}
}
to have itself rendered. The Renderer in turn does this
synchronized (this) {
if (num_triangles < MAX_TRIS_PER_FRAME) {
gl.makeCurrent();
tri.render();
}
}
That way I can control how many triangles is rendered, and by using threads, I’m assured the maximum throughput (every triangle renders as fast as they can, no more waiting for a traditional single threaded rendering loop to render it).
However, I might be forced to redo this in C++ as the JVM is really bad at handling threads :(((. My approach only gives me about 1-2 fps for a quake modelviewer test. My guess would be that using C++ would give me about 60-100 fps. Do you think I should file a bug report to SUN or are they too lazy to respond to serious game programmers like me?
- elias
Ah, elias, what you want to do is have a single thread per vertex, which will then cope with having some polygons with one vertex very close to the camera but other vertices further away.
And you might need to move the threading code into straight C. I suggest an add-on to the LWJGL to do vertex thread handling as Java can’t cope with more than about 2 threads.
Cas
/me chuckles
I thought it was Christmas day, not April fools day ;D
It is christmas - as a present you get to hear cas speak positively about threads. And never again…
- elias
I think that Cas is very happy about threads - they just have to be used right…
I myself have one time thought of doing a world with one thread, and then another thread that captures the world state and renders it. Never actually implemented, but seemed like fun idea - especially with the world being run in another process - or another computer…
Sounds a bit like quakeworld. Why aren’t you drunk yet?
Cas
Hi guys!
I just want to tell you that I implemented the concept explained by Orangy Tang and WOW, it work very well!
Thank you Orangy Tang!
My scrolling is by far smoother than using my sleep timer kind.
Sorry for the delay about this news but I was very busy.
Cas, your algorythm seems well too but I preferred using Orangy Tang’s algorythm.
Thanks to all.
AnalogKid,
Would you be so kind as to post an example of the code change you made? I’d like to compare your original version on page 1 with what you have now.
The reason is that I still don’t fully understand the difference between tick and time based animations as discussed so far, and how the sleep-timer hack fits in.
Your solution may be the very thing I’ve been looking for.
Thanks.
OK
Let say that your hero runs at a maximum of 100 pixels/second (according to its acceleration). To respect this constraint, you must determine how many pixels your hero will move each frame.
So if your machine can achieve 80 fps then we can say that each frame takes 12.5 milliseconds (1000 / 80). What time does it represents in seconds?
12.5 / 1000 = 0.0125 second.
Remember that our hero moves 100 pixels/second maximum so to move him in the current frame we increment his x position by:
100 * 0.0125 = 1.25 pixels
Now imagine that your game runs on a slower machine and the fps drop to 50 fps. No real problem here because your hero will still move at 100 pixels/second but the animation will be less smoother:
1000 / 50 = 20 milliseconds/frame
20 / 1000 = 0.02 second/frame
100 * 0.02 = 2 pixels/frame
And the other great thing about this is that your animation will be as smooth as the fps your computer can achieve! So if your game can run at 100 fps then your animation will be smoother!
But to implements this algorythm succefully you must store the x position (and also y) of your hero as a float or double value because his position is incremental using floating point values.
Here is the code of my rendering loop:
public void run() {
alive = true;
createBufferStrategy();
Graphics g;
long startTime;
float frameDuration;
int frameCount = 0;
long fpsStartTime = System.currentTimeMillis();
running = true;
// Render the animation.
while (alive) {
// Store the start time of the frame.
startTime = System.currentTimeMillis();
// Render all animation stuff.
render();
// Paint the frame and render it.
g = bufferStrategy.getDrawGraphics();
do {
paintFrame(g);
} while (bufferStrategy.contentsLost());
// Put the offscreen image to the screen.
bufferStrategy.show();
g.dispose();
// Update the frame rate every second.
frameCount++;
if (System.currentTimeMillis() - fpsStartTime >= 1000) {
fps = frameCount;
frameCount = 0;
fpsStartTime = System.currentTimeMillis();
}
// Calculate the time elapsed for the frame.
frameDuration = System.currentTimeMillis() - startTime;
animationContext.setFrameDuration(frameDuration / 1000.0f);
}
running = false;
}
You can see that I use a class called AnimationContext. This class is used to store the duration of the current frame in seconds. This instance is instancied by another class and is accessed by all the actors that need it to calculate the number of pixels to move.
I hope this helps.
Good luck.
Oh. Wow. Duh.
I did this too, only I locked it to a particular fps and did not readjust the rates to account for any drop/increase in rendering ability.
I must re-evaluate that position; it might smooth things out.
In my system, I move 64 pixels per second, and locked fps at 32 fps to guarantee 8 pixels per frame.
I think this might be foolish. I think I should use this way better, to simply guarantee 64 pixel movement per second.
Now here’s a question: let’s say the machine drops below a certain fps needed to draw all eight frames of animation I have, what then? As in, what happens if for some ungodly reason I can do 2 FPS … in what position is the actor left standing? More programmatically speaking, what animation frame is displayed?
Are we dropping frames to suit fps?
You could determine which animation frame to display based on the distance moved since the last frame.
You give your character a stride length, and an array of animation frames, and do
arrayIndex += ( int ) ( distanceTraveled / strideLength );
arrayIndex %= animFrames.length;
displayFrame( animFrames[ arrayIndex ] );
As long as the sprites are designed with a particular stride length in mind, this would also stop the character from skating instead of walking.
This is all off the top of my head, so is probably fatally flawed in some way…
Analogkid’s solution seems like a lot of extra work just to compute the physics for a 2d game.
We use 3 threads in our game. One for drawing (low priority), 1 for game communications with our server, and 1 for physics. We set the drawing threads priority to low because it is the least important process. Physics and Server comm are vital to keeping your game in sync. Setting the drawing thread priority to low doesn’t mean you are going to kill your frame rate either. I’ve noticed no difference unless I have CPU hungry applications running.
I don’t see a reason for setting a frame rate at all. What if you have scrolling text or some animation that only looks good at certain speeds? are you going to adjust the framerate for this? you might have 2 things that need to run at different speeds on the same screen. Treat everything that has to do with physics in your physics thread and simply draw at fullspeed. With the low priority of the Drawing thread other applications running on your system should find time to share the cpu as well.