fps expected for platform game

[TheAnalogKid]

Hi everyone,

I'm developing a 2d platform game and I was wondering what should be the expected fps for an average pc?

What is the fps in modern 2d and 3d games developped by professional game developpers?

I remember Jazz Jack Rabbit 2 which used around 75 fps but which graphics mode was it running?

The game I develop is running in 640x480x32 and I intend to set fps to 80.  Is it enough, too high?

I must also mention that I try to acheive very smoot side scrolling.

Thanks in advance.

[princec]

50, no more, no less.

Cas

[leknor]

Anything less than about 35 and I start to dislike the frame rate. If you're trying to dynamicly adjust quality or cap cpu usage, why not let the user set their perference.
Worse than a slow frame rate is slow input processing. I think many people overstate the importantance of a really fast framerate because often input processing is tied to each frame. The worst is a slow game where the player can build up a queue of inputs which create increasing lag as the user tries to get conrol over his character again.

Games published by our own members! Check 'em out!

[Orangy Tang]

Don't cap it or anything freaky like that, just do time based movement instead of tick based movement. I really can't see why anyone would prefere the latter on a modern game (consoles being an obvious exception to this rule)

The only problem this can cause is slightly more complicated collision logic, and the annoyances that gc glitches can cause long delays between updates. But both can be fixed by splitting up large update times into several smaller time slices, although really you should address the root cause - get better collision detection, and stop discarding objects on the fly...

[Abuse]

just do time based movement instead of tick based movement.

A simple sentence, which encapsulates a great deal of knowledge. I believe a large number of ppl would benefit from elaboration on this concept.

any1 wanna volunteer?
(I would, but It would be better coming from 1 of you more experienced ppl)

[princec]

DON'T do time based movement in a 2D game.
There, that's elaborated.
Probably cause an argument, but I don't mind having one when I'm right

Cas

[Orangy Tang]

Aw come on Cas, you can do better than that  
Time based allows smooth fps for machines that can handle it, yet gives slower machines a chance to run at full speed. If you want the same with fixed fps logic but unlimited graphical fps, then you've got to do annoying interpolation between logic updates (case in point: Quake1, with logic @ 10fps, and godawful animation).

Fixed update also complicates networking, since you've got to try and keep the ticks in sync more than time based approaches.

2d vs. 3d should make no differences, its just that with 2d these hacks will be less noticable.

[TheAnalogKid]

Thanks everyone for your recommandations!

Orangy Tang, could you give more explanations on time based fps?  I don't really get the picture.  Maybe you could provide an algorythm or a snipet of code of your own?

Here is what I do in my rendering loop to handle fps:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42

// Render the animation.        Graphics g;         try {             while (alive) {                 startTime = System.currentTimeMillis();                 // Update the frame rate every second.                if (totalTimeElapsed >= 1000) {                       fps = frameCount;                       frameCount = 0;                       totalTimeElapsed = 0;                 }                 g = bufStrategy.getDrawGraphics();                 do {                       paintFrame(g);                 } while (bufStrategy.contentsLost());                 render();                 // Put the offscreen image to the screen.                bufStrategy.show();                 g.dispose();                 // Update the count of frames.                frameCount++;                                 // Sleep the required time according to the last frame duration.                timeElapsed = System.currentTimeMillis() - startTime;                 if (timeElapsed < frameDelay) {                       Thread.sleep(frameDelay - timeElapsed);                 } else {                       Thread.sleep(5);                 }                 // Update the total time elapsed in the rendering loop.                // This counter is reset every second.                totalTimeElapsed += (System.currentTimeMillis() - startTime);             }         } catch (InterruptedException e) {               DisplayManager.getInstance().restorePreviousDisplayMode();               e.printStackTrace();         }

princec, why no more, no less than 50 fps?

Thanks a lot guys!

[princec]

Actually I should clarify this specifically:

By all means cap the frame rate but don't attempt to adjust movement and animation by taking time into account: always use ticks. It looks terrible in 2D games.

50's what we had on the C64, and 50 was just perfect. Anything less looks un-smooth, anything more's a waste.

Cas

[TheAnalogKid]

Ok thanks but all the examples I saw to handle frame rate were based on the snipet of code I showed in my previous example so why they are not so good?

Games published by our own members! Check 'em out!

[princec]

Well, apart from being a non-portable solution - ie. it's a hack, it does in fact cap the frame rate, which is all well and good. But from then on what you do with the elapsed time is where the mistake is made. I strongly urge counting elapsed frames as per normal, set a capped frame rate to match your minimum specification JVM/HW/OS combo, and tuning your animation to work at this capped rate, and tuning your application to ensure it doesn't drop below this rate.

Cas

[Orangy Tang]

Ugh, sleep timer uglyness  

IMHO, the following is much nicer:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

while(!gameOver) {   float delta = calculateTimeDelta();   world.update(delta);   world.render(); } public float calculateTimeDelta() {   float delta;   float currentTime;= System.currentTimeMills();   delta = currentTime;- m_fPreviousTime;   m_fPreviousTime = currentTime; }

Simple update code would look something like:

1   2   3   4   5

public void update(float delta) {   xCoord += xSpeed*delta;   yCoord += ySpeed*delta; }

At the very least try both, and pick which works better for you..

[TheAnalogKid]

Cas,

what do you think about the Sleep based timer hack posted in the Shared Code forum?  Is this algorythm the same thing compared to what you explained in your previous message?


Orangy Tang,

how do you determine the value of xSpeed or ySpeed in your update method if for example you would like a fps of 50?

Thanks

[princec]

Without native trickery, the sleep based timer hack as seen in various forms here will cap your frame rate OK. If you set the cap at a realistic level then you can simply adjust your animation to look best, tick-by-tick, to that rate. I reckon that'll look fine.

Cas

[Orangy Tang]

if for example you would like a fps of 50?

Thats the beauty of the technique - you don't pick a speed for a fps, you pick a speed based on your internal measurements. Being a physics guy, I like to keep everthing in SI units as much as possible - so i'll convert the time delta into seconds and have my speeds in meters per second.

Btw, I found out recently that the above method is also used in high-end millitary/comercial simulators, so its definatly a tried and tested technique  

[princec]

Yeah, but I can't stress the difference between a physical military simulation and a game more strongly!

I suggest you try a very simple experiment: write a game that involves jumping from one platform to another using physics. Cap the frame rate at successively lower rates, and see how easy it is to make the jump, or how good it looks.

Then try the tick-based tuning method and tell me which one feels like a slick game and which one feels like it's got network lag

Cas

[Abuse]

im behind Orangy Tang on this 1, a variable timeScale is so much more elegant. (and the fps will only be limited by either the speed of the computer, or the minimum timer resolution of the underlying OS)

1 other, vaguely related issue.
In quake3, at exactly 75 and 125 fps, it was possible to jump slightly higher/further (q3dm13 you could jump upto the mh, q3dm7 you could jump across to the rg)

anybody got any thoughts on the exact cause of this?
(was it a floating point rounding issue?,
or was it some hack in the code,
where by when the fps and the tickrate were very close,
the game would merge the 2 together?)

abu,

[princec]

Elegance shmelegance! It will suck for a 2D game. You *have* to try it to prove it to yourself though, and it's probably a worthwhile thing to prove too.

Cas

[Captain-Goatse]

You can never have enough FPS, for real.

[leknor]

You can never have enough FPS, for real.

How about this situation: I have an el-cheapo computer and it came with a soft-modem (aka: WinModem) and I'm playing a network game. If the game I'm playing eats all the cpu it can in an effor to provide 600 fps the network performance will suffer because a software modem will be starved of cpu cycles and the network play aspect of the game will be percieved to be crappy because of that.

[Matzon]

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!!!

[princec]

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

[Abuse]

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.

Can't disagree with that, now where is that Thread.wakeOnVblank().

And 50 seems to be what's needed

but, you just said fps should be capped at monitor refresh, so why would you want to cap it at 50?

for that ultra-slick smooth feel of the C64 and Amiga.

memories are always forgiving when it comes to fps

Hey, anyone remember Gods? That ran at half frame rate :/ Beautiful graphics but didn't half feel slow after all the other games...

Cas

can't say I ever played that 1, /me trundles off to an abandonwares site....

[princec]

Whoops, forgot we're all at 60Hz these days
50's what us Europeans got.

Cas

[Contrast]

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.

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.

[princec]

No! No! No! No! No! Must I explode before anyone understands!c[size=72]You do NOT WRITE MULTITHREADED RENDERING CODE![/size] I dunno whether I can be arsed to explain it again so I think I should write a FAQ about it. Hehe.

Cas

[Abuse]

Whoops, forgot we're all at 60Hz these days
50's what us Europeans got.

Cas

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  

[princec]

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

[elias]

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

1   2   3   4   5

while (true) {  synchronized (this) {    Renderer.display(this)  } }

to have itself rendered. The Renderer in turn does this

1   2   3   4   5   6

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

[princec]

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