Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  fps expected for platform game  (Read 10097 times)
0 Members and 1 Guest are viewing this topic.
Offline TheAnalogKid

JGO Coder


Projects: 3



« Posted 2002-12-17 20:13:47 »

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.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2002-12-17 20:54:20 »

50, no more, no less.

Cas Smiley

Offline leknor

Junior Member




ROCK!!!


« Reply #2 - Posted 2002-12-17 21:20:45 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #3 - Posted 2002-12-17 22:20:55 »

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #4 - Posted 2002-12-18 00:09:53 »

Quote

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

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2002-12-18 12:14:49 »

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 Smiley

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #6 - Posted 2002-12-18 13:23:42 »

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #7 - Posted 2002-12-18 15:55:21 »

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!

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2002-12-19 09:43:58 »

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 Smiley

Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #9 - Posted 2002-12-19 12:32:17 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2002-12-19 13:06:23 »

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 Smiley

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #11 - Posted 2002-12-19 14:00:39 »

Ugh, sleep timer uglyness  Shocked

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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #12 - Posted 2002-12-20 15:57:02 »

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

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2002-12-21 07:56:51 »

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 Smiley

Offline Orangy Tang

JGO Kernel


Medals: 51
Projects: 11


Monkey for a head


« Reply #14 - Posted 2002-12-21 08:04:18 »

Quote
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  Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2002-12-21 11:34:19 »

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 Smiley

Cas Smiley

Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #16 - Posted 2002-12-21 12:31:18 »

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) Roll Eyes

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,

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2002-12-21 15:02:18 »

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 Smiley

Offline Captain-Goatse

Junior Member




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #18 - Posted 2002-12-22 13:35:16 »

You can never have enough FPS, for real.
Offline leknor

Junior Member




ROCK!!!


« Reply #19 - Posted 2002-12-22 23:45:16 »

Quote
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.
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #20 - Posted 2002-12-23 05:44:49 »

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

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2002-12-23 10:59:18 »

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 Smiley

Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #22 - Posted 2002-12-23 16:35:41 »

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.


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

Quote
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?

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


memories are always forgiving when it comes to fps Wink

Quote

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

Cas Smiley


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

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2002-12-23 16:54:12 »

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

Cas Smiley

Offline Contrast

Junior Newbie




where's the beef?


« Reply #24 - Posted 2002-12-23 17:47:42 »

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. Grin

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.
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2002-12-23 22:37:56 »

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 Smiley

Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #26 - Posted 2002-12-24 01:28:55 »

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

Cas Smiley


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  Cheesy

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2002-12-24 07:54:35 »

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 Smiley

Offline elias

Senior Member





« Reply #28 - Posted 2002-12-24 08:16:35 »

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 Sad((. 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

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2002-12-24 09:52:00 »

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 Cheesy

Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (15 views)
2014-04-15 18:08:23

BurntPizza (13 views)
2014-04-15 03:46:01

UprightPath (27 views)
2014-04-14 17:39:50

UprightPath (12 views)
2014-04-14 17:35:47

Porlus (29 views)
2014-04-14 15:48:38

tom_mai78101 (51 views)
2014-04-10 04:04:31

BurntPizza (110 views)
2014-04-08 23:06:04

tom_mai78101 (211 views)
2014-04-05 13:34:39

trollwarrior1 (179 views)
2014-04-04 12:06:45

CJLetsGame (185 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!