Why do gamers chose frame rate of 30f/s for their games?
Author
Why do gamers chose frame rate of 30f/s for their games?
Recomend me some beginers books on programming 3d games please.
cheers
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.
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.
Quote:Original post by xDS4Lx
A decent explanation can be found here: 30fps vs. 60fps
Interesting article there.
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.
Are there any published articles on this stuff I could read? Its a fascinating subject.
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.
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.
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();};#endifIt 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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
