Jump to content
  • Advertisement
Sign in to follow this  
TheMan22

Why do gamers chose frame rate of 30f/s for their games?

This topic is 3788 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Why do gamers chose frame rate of 30f/s for their games? Recomend me some beginers books on programming 3d games please. cheers

Share this post


Link to post
Share on other sites
Advertisement
If they choose 30 it's usually because they can't get their game to run at 60.

The reason 30 and 60 are most commonly used are that TV refresh rates are 60Hz (at least NTSC TVs), so if the framerate is locked to 60 or 30 the game refreshes in sync with the TV and prevents ugly artifacts like screen tearing.

Share this post


Link to post
Share on other sites
I firmly believe that mouse lag can be detected at framerates below 90, down to my own experimentation (asking friends if they can feel the difference before and after I press a button which switched teh framerate from 90 to 60. They had no idea what the button did, and the refresh rate fo the screen was 60hz so there would have been no noticeable drop in framerate). I've been unable to explain why, however, since if the refresh rate of the screen remains at 60, how can they see the difference?

Are there any published articles on this stuff I could read? Its a fascinating subject.

Share this post


Link to post
Share on other sites
Oh, well speciesUnknown, that should be fairly simple to sort out.
You may only see the response to your actions ever 1/60th of a second, but lets say you refresh input every 1/120th of a second.
That means that you can press a button exactly inbetween frames, and have the game update as if you did so.
I remember back in the days of playing fps's on the n64. everyone fought over first player, because the system appeared
to lump all input, then process in player order. So being the first to pull the trigger only counted if being first put your input
on a different frame. (may not have been what actually happened, but it felt like it)

I'd say it would make the most difference on games that don't sweep collisions. So in 1/60th of a second an object can move out
of the way of where you were pointing, but in 1/120th you could still graze the target.
So even though you have to wait to see the results of your actions, the actions respond to input better.

Share this post


Link to post
Share on other sites
Quote:
Original post by GMuser
Show us an example of this application, with source.


Erm, there are 56 source files. Here is the header file for my demo application:
[edit for typing mistake, its 56 not 156]

/*
* game_engine.h
* game_engine
*
* Created by gavin on 06/04/2007.
* Copyright 2007 __MyCompanyName__. All rights reserved.
*
*/


class game_engine;
#ifndef game_engine_class_h
#define game_engine_class_h 1

#include "g_maths.h"

#include "SDL_GL_include.h"
//OS generic includes for SDL and OpenGL

#include "input_control.h"
//input control class, which includes keyboard, and mouse input.

#include "MD2_manager.h"
#include "static_mesh.h"
//model formats. Currenltly, static mesh only loads AC3D files (.ac)

#include "character.h"
#include "human_player.h"
#include "character_manager.h"
//character system. characters are controlled by either human or Ai players.

#include "renderer.h"
#include "viewport.h"
#include "font_draw.h"
//OpenGL specific renderer.

#include "physics_demo.h"
//Newton GD based physics demo, currently under testing

#include "gavs_gui.h"
//custom GUI system.


#include <iostream>
#include <sstream>

enum internal_game_state{
internal_game_state_playing,
internal_game_state_exiting
};

class game_engine
{
private:
human_player * h;
character_manager * cm;
renderer * r;
static_mesh * s;
MD2_manager * test_model;
material_db * materials;
material * m;
font_draw * font;
physics_demo * d;
GUI_widget * gui_surface;
GUI_manager * gui_manager;
GUI_renderer_GL * gui_renderer;
GUI_event_queue * event_queue;
input_control * input_object;

internal_game_state state;
std::string title_message;
public:
game_engine();
~game_engine();

int initialize(int X, int Y, int D, int F);
void build_gui();
int initialize_renderer(int X, int Y, int D, int F);
int draw(float fps);
bool handle_events();
int update(float fps);
int main_loop();
};
#endif





It wasn't a serious test, and this is not serious code, just long code. The animated models were md2 meshes, the level geometry is from a 3d editor called AC3D. Physics are with Newton GD.

Share this post


Link to post
Share on other sites
Quote:
Original post by KulSeran
Oh, well speciesUnknown, that should be fairly simple to sort out.
You may only see the response to your actions ever 1/60th of a second, but lets say you refresh input every 1/120th of a second.
That means that you can press a button exactly inbetween frames, and have the game update as if you did so.
I remember back in the days of playing fps's on the n64. everyone fought over first player, because the system appeared
to lump all input, then process in player order. So being the first to pull the trigger only counted if being first put your input
on a different frame. (may not have been what actually happened, but it felt like it)

I'd say it would make the most difference on games that don't sweep collisions. So in 1/60th of a second an object can move out
of the way of where you were pointing, but in 1/120th you could still graze the target.
So even though you have to wait to see the results of your actions, the actions respond to input better.


Thanks, that's a nice explanation.

Share this post


Link to post
Share on other sites
Yeah, you don't necessarily have to link your input or simulation framerates to your rendering framerate. One approach would be to run input on a separate thread to rendering.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!