Tweet hints at FPS numbers

[Oryon22]

https://twitter.com/tomslick42/statu...41733933121538

Granted, we don't know the hardware specs or graphics settings... but still...

[headcrab13]

I'll buy whatever hardware it takes :D

[lolroflroflcake]

Well its an MMO so I would imagine it was designed to run on a wide array of machines, I don't know about triple digits but I would imagine most people would be able to run the game at a rate that is unnoticeable to the eye. Of course this is all assuming you don't have some crazy Ghost in the Shell cyborg eyes that can watch a humming bird's wings flap in slow motion and see into the ultra-violet and infrared spectrums, and I'm sure you weren't intentionally discriminated against if you do.

[headcrab13]

Originally Posted by lolroflroflcake

Well its an MMO so I would imagine it was designed to run on a wide array of machines, I don't know about triple digits but I would imagine most people would be able to run the game at a rate that is unnoticeable to the eye.

You're definitely right that they'll be trying to bring Planetside 2 to the largest number of machines possible, but I guarantee you it's going to take some SERIOUS hardware to run this baby on max settings at 60+ fps.

[Arius]

Originally Posted by headcrab13

I'll buy whatever hardware it takes

Not me. If Sony wants alot of people to play it, they better make mid range computers run it smoothly aswell.

[headcrab13]

Originally Posted by Arius

Not me. If Sony wants alot of people to play it, they better make mid range computers run it smoothly aswell.

Oh yeah, you'll definitely be able to play on a mid-range. As I said in my second post, this is an MMO and they need to appeal to the masses, hardware-wise.

The reason I'm building a machine specifically for PS2 is that I want to see what we're seeing in these max-settings screenshots, all the time and in fluid motion. I'm also going to take HD gameplay footage and put out fan videos to get even more people in on the action.

[RadioFIN]

Uh oh, another PS2 dev to follow. Thanks

[CrystalViolet]

I'd be happy with 30fps without any dropped frames. I've heard this is the limit of the human eye, but there are other factors at play with games.

[bjorntju1]

Originally Posted by CViolet

I'd be happy with 30fps without any dropped frames. I've heard this is the limit of the human eye, but there are other factors at play with games.

More than 60FPS and I don't see the difference. But I can clearly see the difference between 30 and 60 FPS.

Anyways sounds great. However I am curious what specs he has and on with settings.

[Goku]

Originally Posted by bjorntju1

More than 60FPS and I don't see the difference. But I can clearly see the difference between 30 and 60 FPS.

Anyways sounds great. However I am curious what specs he has and on with settings.

Get a 120Hz monitor and you may then. 60Hz won't let you notice anything above 60 FPS.

[Coreldan]

It isnt as simple as 30 FPS. Perhaps the secret is in the "dropped frames" or something, but I've yet to see a game where I wouldnt be able to tell a world apart in 30 fps and 60 fps. Beyond 50 I dont really see a difference personally.

[CrystalViolet]

I can see the difference as well. Interestingly though. I can't really see any choppiness in movies that were recorded at 24fps (the old standard). My guess is that since video game fame rates are never constant, it causes a conflict with your monitors refresh rate and thus drops a frame here and there.

Interestingly, nvidia's new cards advertise the ability to slow down frame rates when the hardware is overkill for rendering certain games. I wonder if this would make for a smoother looking 30fps if all frames were delivered at precisely that rate?

[kaffis]

Originally Posted by CViolet

I can see the difference as well. Interestingly though. I can't really see any choppiness in movies that were recorded at 24fps (the old standard). My guess is that since video game fame rates are never constant, it causes a conflict with your monitors refresh rate and thus drops a frame here and there.

Interestingly, nvidia's new cards advertise the ability to slow down frame rates when the hardware is overkill for rendering certain games. I wonder if this would make for a smoother looking 30fps if all frames were delivered at precisely that rate?

It's very simple. Video games don't motion blur. The camera movies are recorded with captures motion blur naturally. Motion without the appropriate amount of blur looks "choppy" to the human eye.

This is because your eye continuously accepts input, but doesn't process it continually. Instead, the brain perceives small slices of time, and it expects objects in motion to have made an impression on the nerves in the retina at all points between the start end end of that slice of time.

When a game renders crisp still images and puts them up on the screen one at a time, objects in "motion" don't move through the intervening space between their position in one frame and the next, no matter how fast the framerate is. Instead, what we do is try to speed up the framerate so you can cram multiple frames into each slice of time the brain actually processes, creating the illusion of motion.

Shot footage, on the other hand is recorded in such a way that each frame of a movie or video (whether it's digital or film) has that 1/24th (1/30th if it's designed for TV) of a second captured in the same frame. This is why pausing TV or movies, even on DVD, looks blurry if it's an action shot or a fast pan. It actually IS blurry, it's just blurry in a way that your brain expects when it's being shown one frame after another.


So, yeah. If game engines were written with shaders or something that could apply motion blur to individual frames, the quest for maximum framerate would be a lot less of a problem, and we could get away with movie/TV-level framerates (and lower! individuals who get bothered/notice even 20 fps when properly motion blurred are *rare* -- most people's perception limits are in the 15-17 range). The exciting thing is, I think GPU hardware is catching up to the processing requirements to make that a practical engine feature for real-time rendering, so we may actually see engines do this in the near future.

[CyclesMcHurtz]

Originally Posted by kaffis

... If game engines were written with shaders or something that could apply motion blur to individual frames, the quest for maximum framerate would be a lot less of a problem, and we could get away with movie/TV-level framerates (and lower! individuals who get bothered/notice even 20 fps when properly motion blurred are *rare* -- most people's perception limits are in the 15-17 range). The exciting thing is, I think GPU hardware is catching up to the processing requirements to make that a practical engine feature for real-time rendering, so we may actually see engines do this in the near future.

You should be even more excited - Motion Blur is not new technology for video games. It started appearing in around 2005 and has been in some games and not others. Gears of War, Sonic the Hedgehog, and Mirrors Edge are just a few of the better done ones (not referring to game-play, just motion blur).

[ Warning - technical content below ]

As for the quest for maximum frame rate ... it's really a matter of responsiveness. At 20fps the game is taking 50ms to display a frame. On your typical console (most are different in PC's in a key way, noted below) this results in about 100ms-110ms lag time between user input and action on screen. This is very noticeable.

[shoot] -> [ CPU work (50ms) ] -> [ GPU work (50ms) ] -> [ Display! ]

The reason I singled out consoles is because the typical PC these days has additional latency and measuring it for individual games is difficult. Most DirectX devices can queue up to 3 frames of graphics, resulting in 150ms (again, referencing 20fps only here) for just rendering lag, an additional 50ms for the game to figure out what to draw, resulting in a worst case of 200ms (substantially more). You can see this in your graphics control panel for your video card under something like "Manage your 3D settings --> pre-rendered frames". Most of the time this is set to 3. This can (doesn't always) turn into:

[shoot] -> [ CPU work (50ms) ] -> [ GPU queue 1 (50ms) ] -> [ GPU queue 2 (50ms) ]-> [ GPU queue 3 (50ms) ]-> [ Display! ]

This queue is designed to 'absorb' spikes in CPU time - the CPU is usually not the bottleneck and can quickly recover. High-quality coders know how to manage this latency well and can control it on the PC. The additional benefit to multi-GPU systems is you can reduce this time by half (if the CPU can keep up) because each video card can do work on a different frame which allows them to stagger over time. You can get up to about 90% increase in frame rate with these systems. Note 50ms was cut out, but the same number of frames were rendered below which means the FRAME RATE increased, but the LATENCY didnt' change:

[shoot] -> [ CPU work (50ms) ] -> [ GPU queue 1 (50ms) ] 
                                            -> [ GPU queue 2 (50ms) ]
                                                         -> [ GPU queue 3 (50ms) ]-> [ Display! ]

You can also have strange effects due to poor multi-CPU usage. If a theoretical n00b coder puts the game code into four distinct functions, each around the same time and runs them on four different CPU's, the frame rate may be fast but since each function depends upon the result of the previous function - and that's going to take four whole frames to process. The result is that if this theoretical system was running at our 20fps, then with the 3 pre-rendered frames queued up and the four-frame latency in place you are looking at (4 cpu + 3 GPU + 1 display)*50ms latency - almost a HALF SECOND from when you clicked fire to when the shot happens on screen. The frame rate is STILL 20fps, however.

[Input (cpu 1)] 
   -> [Game Logic (cpu 2)]
         -> [Physics (cpu 3)]
               -> [Render Magic (cpu 4)]
                     -> [GPU Queue 1]
                           -> [GPU Queue 2]
                                 -> [GPU Queue 3] -> [Display!]

Even a game running at 60fps would feel laggy with this (worst case) coding (4 cpu + 3 GPU + 1 display)*16ms = 128ms latency - looks like 60fps, feels like 8fps.

Fortunately, I haven't met any coders on FPS games who think this would be acceptable.

I now return you to your regularly scheduled troll... er, forum reading.

[Snipefrag]

Originally Posted by CyclesMcHurtz

You can also have strange effects due to poor multi-CPU usage. If a theoretical n00b coder puts the game code into four distinct functions, each around the same time and runs them on four different CPU's, the frame rate may be fast but since each function depends upon the result of the previous function - and that's going to take four whole frames to process. The result is that if this theoretical system was running at our 20fps, then with the 3 pre-rendered frames queued up and the four-frame latency in place you are looking at (4 cpu + 3 GPU + 1 display)*50ms latency - almost a HALF SECOND from when you clicked fire to when the shot happens on screen. The frame rate is STILL 20fps, however.

It adds a completely new level to coding when your working in a real time environment, I work in the broadcast industry on the software that controls tv channels (including some big ones over in America which i wont name) where the standard is 25fps, (40ms timeslices to process each frame or tick). A lot of time is spent making sure that we don't break through that 40 ms timeslice... If we do schedules for that station can slip, and it generally makes everyones jobs a bit harder. Some of our systems have upwards of 15 tv channels and all of their real time devices (think video playout, logos, graphics, up/down scaling, audio processing) running on a single server, so it can be a challenge at times.

I guess making a game is similar in that respect, intelligent use of threading (and not just threading for the sake of it) must play a vital role.

One question i have is with regards to frame rate, in my job i KNOW that i'm going to be afforded 40ms for all the framework, drivers and components to process everything for that frame. We have a purpose built scheduler tailored around this fact, in a game engine such as forgelight my guess is that your client side scheduler will try and be as greedy as possible with regards to framerate like a normal FPS game, taking as much CPU as possible to give the highest framerate you can.. Is this scheduling solely a reactive thing client side, or is the data received from the server (such as when you are just about to fly over a base with 300 troops in) used to project and smooth out these spikes that might cause things to slow down?