Comments on: “Frames per second” is not relevant

By: Bruce

Bruce — Wed, 19 May 2010 17:22:38 +0000

Agreed. I am glad I am not the only one thinking this. Sure 30 fps may chop a little with a very fast turn, but I cant see how anyone would notice anything more than 50 fps.

Really, people should now be concentrating on the quality of the content, not the frame rate.

By: Archiform 3D

Archiform 3D — Sat, 31 Oct 2009 14:41:47 +0000

Agreed. I am glad I am not the only one thinking this. Sure 30 fps may chop a little with a very fast turn, but I cant see how anyone would notice anything more than 50 fps.

Really, people should now be concentrating on the quality of the content, not the frame rate.

By: groby

groby — Fri, 30 Oct 2009 19:19:10 +0000

@Blacktiger: Actually, movies run at 72fps - they just run the same frame 3 times. And due to some weird physiological stuff, your eye likes that better than 24 fps.

Fast camera pans shouldn't cause tearing in movies, but motion blur. I'd be interested to see a movie that tears instead. (Digital FX, maybe?)

And in that same vein, if games actually did proper motion blur, they might very well get away with 30fps rendering. (You can still draw at 60 fps if you keep that independent from the 3D rendering)

By: Blacktiger

Blacktiger — Fri, 30 Oct 2009 18:54:50 +0000

You are absolutely right, games need to separate the rates for drawing, physics, and input. I don’t know if it is the same for everyone, but I find that 30fps looks choppy when there is a lot of motion on the screen. Movies run at 24fps in theaters which looks fine when there isn’t much motion on the screen, but as soon as the camera pans too fast you get visual tearing. 60fps will allow for a smooth picture no matter how fast the camera moves. For some games, there isn’t enough motion to need a 60fps rate.

By: groby

groby — Fri, 30 Oct 2009 18:06:22 +0000

@anon: Ooops. Sorry. Fixed.

@Matt:

You need to be careful with asynchronous processing. As I alluded to in the last paragraph, you will create aliasing artifacts if different subsystems run on desynchronized clocks. That's why I'm think modelling a game using signal theory might not be the worst idea. Searching for research, nothing found yet.

As for the PS3: It's not threading that's hard, per se. It's the fact that it's a new paradigm, and that Sony always manages to make their hardware hard to develop for. I personally think they do it so titles can increase in quality over lifetime of console.

As for the middleware - they will all need a threading solution. And if they all have a separate one, I can't wait to see the fun that ensues when you connect them ;)

We might very well see some consolidation in that space.

By: Matt

Matt — Fri, 30 Oct 2009 17:36:49 +0000

I've been a professional developer working in systems level software for servers for years. I recently began getting into game development, and honestly don't understand why (on PC based games) there is still a lock-step with framerate for processing of the game components. With so much of the rendering pipeline taking place on the GPU, even without a multi-core CPU, you can do the actual game logic in a separate thread from the rendering loop and have a dramatic increase in frame rate and responsiveness.

The amount that developers compalin about the PS3 seems to indicate a resistence to this type of processing model, yet the only explainations I hear from people is that threading is hard. I imagine in the future there will be middleware libraries available that implement all the necessary locking internally so that the developers won't need to worry about whether the engine multi-threaded, multi-process, or a monolithic game loop.

By: Anonymous

Anonymous — Fri, 30 Oct 2009 17:35:57 +0000

Mick West*