fps expected for platform game

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.

50, no more, no less.

Cas :slight_smile:

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.

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…

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? :smiley:
(I would, but It would be better coming from 1 of you more experienced ppl)

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 :slight_smile:

Cas :slight_smile:

Aw come on Cas, you can do better than that :stuck_out_tongue:
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.

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:


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

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 :slight_smile:

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?

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 :slight_smile:

Ugh, sleep timer uglyness :o

IMHO, the following is much nicer:


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:


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

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

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

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 :slight_smile:

[quote] if for example you would like a fps of 50?
[/quote]
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 ;D

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 :slight_smile:

Cas :slight_smile:

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) ::slight_smile:

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,

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 :slight_smile:

You can never have enough FPS, for real.

[quote]You can never have enough FPS, for real.
[/quote]
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.