<!--quoteo(post=1796602:date=Aug 27 2010, 10:04 PM:name=Thaldarin)--><div class='quotetop'>QUOTE (Thaldarin @ Aug 27 2010, 10:04 PM) <a href="index.php?act=findpost&pid=1796602"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm not understanding this amazingly. Although, doesn't this mean console will be making super duper processors in order to produce this and just staying with the same poopy graphics?<!--QuoteEnd--></div><!--QuoteEEnd--> The idea is that a simple bit of image manipulation will take less CPU power then re-rendering the whole 3d environment
Essentially they are taking the already rendered frame, cutting the moving character out and re-pasting him back into the image some distance along his movement path and presenting this as a 'new' frame. It isn't truly, just a photoshop-esque edit of the last frame but this shouldn't be noticeable to the viewer. So now you are rendering new frames at 30 FPS but presenting unique frames to the viewer at a rate of 60 FPS.
<!--quoteo(post=1796602:date=Aug 27 2010, 07:04 PM:name=Thaldarin)--><div class='quotetop'>QUOTE (Thaldarin @ Aug 27 2010, 07:04 PM) <a href="index.php?act=findpost&pid=1796602"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm not understanding this amazingly. Although, doesn't this mean console will be making super duper processors in order to produce this and just staying with the same poopy graphics?<!--QuoteEnd--></div><!--QuoteEEnd-->
No. The main goal of the project was to do this with the existing hardware and not introduce lag. And somehow they did it. No extra hardware required.
Granted, it's a bit of a hack and not a true 60fps framerate, but it really does make a difference for your eyes.
PS, it's OK to not get/understand the details. Some is mostly just eye/ear candy for the graphic geeks among us.
This new bit of hardware whizz-bangery will sit at the end of the graphical pipe. It buffers a frame until it recieves a second frame. It looks at the buffered frame and the new frame it's recieved, and does a bit of jiggery-pokery to come up with another frame that looks like it could be in between the buffered frame and the new one.
It then sends out the buffered frame, followed by the interpolated frame 16.6 ms later. It buffers the new frame, and awaits the delivery of the next new frame. It's running 33.3 ms behind real-time to allow for the buffering. You don't get any extra detail, just extra perception of fluidity.
<!--quoteo(post=1796739:date=Aug 28 2010, 09:24 PM:name=Scythe)--><div class='quotetop'>QUOTE (Scythe @ Aug 28 2010, 09:24 PM) <a href="index.php?act=findpost&pid=1796739"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You don't get any extra detail, just extra perception of fluidity.<!--QuoteEnd--></div><!--QuoteEEnd-->
But why are we buffering frames to start with? A 1/3 second buffer seems excessive in reaction based games... or are we already doing this and in that case why the heck? I want my frames NOW!
Or wait a sec, you're saying it takes time to render a frame, and while this is going on we can take the time to fake this interpolated frame and insert it? In that case that's awesome. And simple. Cool.
<!--quoteo(post=1797437:date=Sep 3 2010, 11:33 AM:name=tjosan)--><div class='quotetop'>QUOTE (tjosan @ Sep 3 2010, 11:33 AM) <a href="index.php?act=findpost&pid=1797437"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->But why are we buffering frames to start with? A 1/3 second buffer seems excessive in reaction based games... or are we already doing this and in that case why the heck? I want my frames NOW!
Or wait a sec, you're saying it takes time to render a frame, and while this is going on we can take the time to fake this interpolated frame and insert it? In that case that's awesome. And simple. Cool.<!--QuoteEnd--></div><!--QuoteEEnd-->
Frame buffers are standard practice nowadays. In fact, there are some who advertise spiffy things like triple frame buffering!
The reason is to prevent tearing while generating the frame which degrades the image and causes nausea. Plus, we render each frame's pixels sporadically and out-of-order, while a monitor requires that the information be streamed in a very specific pattern. Also, for computers, if you're rendering slower than the refresh rate of the monitor, you need to keep an old frame around for the screen to fetch while it waits for the new one.
Also, the time spent in the buffer is very, very small. Remember, running at 30fps means, assuming a frame buffer depth of 1, only 1/30th of a second delay. That's 33ms. Most people don't even have internet that fast.
So, since everyone already agreed that frame buffers are good and everyone uses them, this project takes that little extra time while a frame is in the buffer to interpolate, generating a new frame to help smooth the picture on the slower console systems.
<!--quoteo(post=1797471:date=Sep 3 2010, 04:14 PM:name=tjosan)--><div class='quotetop'>QUOTE (tjosan @ Sep 3 2010, 04:14 PM) <a href="index.php?act=findpost&pid=1797471"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Any competitive FPS-player would tell you that the difference between having some 30 ms latency and 60 ms latency is definitely noticable.. :/<!--QuoteEnd--></div><!--QuoteEEnd-->
True. For a PC.
However, real competitive players use something called 60fps which has only 16ms delays. On a PC.
ETA: Reading a bit more carefully than the first skim through, I think I missunderstood what they're doing.
They extrapolating forwards from one frame and extrapolating backwards from the next, then merging the two to create the interpolated frame. They're not just extrapolating forwards as I believed.
<!--quoteo(post=1796494:date=Aug 27 2010, 08:46 AM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Aug 27 2010, 08:46 AM) <a href="index.php?act=findpost&pid=1796494"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm skeptical about this, because if it was as simple as rendering 30fps and then blurring between them, surely someone would have done it already.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's not what they're doing at all. Just bluring frames toghether with no further processing does nothing useful. They're rendering a velocity map and extrapolating the motion forwards from one frame, and backwards from the next; they use various cheap tricks to try and fix up artifacts, especially around players.
<!--quoteo(post=1796494:date=Aug 27 2010, 04:46 PM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Aug 27 2010, 04:46 PM) <a href="index.php?act=findpost&pid=1796494"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I don't think you can actually see much higher than that.<!--QuoteEnd--></div><!--QuoteEEnd--> I can see the difference between 100 and 120 FPS. Because of tearing I can also tell the difference between 200 and 120 FPS. You can fix that with VSYNC though but it'll add a bit of mouse lag, same thing with this console thingy because you need extra buffering. That's why many competitive players don't use triple-buffering and vsync but higher FPS to issue tearing.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->However, real competitive players use something called 60fps which has only 16ms delays. On a PC.<!--QuoteEnd--></div><!--QuoteEEnd--> I'd never play NS with 60FPS if I had a choice. That's just horrible. 200FPS is the norm at the moment.
In live music performance, you've to have audio lag less than 10ms, something like 2-4ms would be optimal otherwise it'll affect the rhythm.
Motion blur or sampling is used in frag movies to catch up the low FPS although it takes a lot of computing power. The idea there is to blur everything that's moving.
<!--quoteo(post=1798056:date=Sep 9 2010, 08:06 AM:name=Jiriki)--><div class='quotetop'>QUOTE (Jiriki @ Sep 9 2010, 08:06 AM) <a href="index.php?act=findpost&pid=1798056"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I can see the difference between 100 and 120 FPS. Because of tearing I can also tell the difference between 200 and 120 FPS. You can fix that with VSYNC though but it'll add a bit of mouse lag, same thing with this console thingy because you need extra buffering. That's why many competitive players don't use triple-buffering and vsync but higher FPS to issue tearing.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah. At the end of the day, you'd rather have uber fps and minimal lag for actually competitive stuff. Most people see into the 80+fps region. You're unique to reach 120fps on your eyes.
But, well, consoles suck like that and are capped at 30fps......
puzlThe Old FirmJoin Date: 2003-02-26Member: 14029Retired Developer, NS1 Playtester, Forum Moderators, Constellation
<!--quoteo(post=1798056:date=Sep 9 2010, 04:06 PM:name=Jiriki)--><div class='quotetop'>QUOTE (Jiriki @ Sep 9 2010, 04:06 PM) <a href="index.php?act=findpost&pid=1798056"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'd never play NS with 60FPS if I had a choice. That's just horrible. 200FPS is the norm at the moment.<!--QuoteEnd--></div><!--QuoteEEnd-->
But that's for entirely different reasons and well you know it, Jiriki. Modern engines do not have movement code so tightly coupled with the render path.
30fps is the norm for consoles because ATSC only defines HDTV up to 30fps ( the US standard ). DVB (euro) defines it up to 60fps, and most HD TV sets now support 60fps inputs. This discussion really has nothing to do with how PC gaming behaves, which is an entirely different discussion IMO.
<!--quoteo(post=1798056:date=Sep 9 2010, 03:06 PM:name=Jiriki)--><div class='quotetop'>QUOTE (Jiriki @ Sep 9 2010, 03:06 PM) <a href="index.php?act=findpost&pid=1798056"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I can see the difference between 100 and 120 FPS.<!--QuoteEnd--></div><!--QuoteEEnd-->
Comments
The idea is that a simple bit of image manipulation will take less CPU power then re-rendering the whole 3d environment
Essentially they are taking the already rendered frame, cutting the moving character out and re-pasting him back into the image some distance along his movement path and presenting this as a 'new' frame. It isn't truly, just a photoshop-esque edit of the last frame but this shouldn't be noticeable to the viewer. So now you are rendering new frames at 30 FPS but presenting unique frames to the viewer at a rate of 60 FPS.
No. The main goal of the project was to do this with the existing hardware and not introduce lag. And somehow they did it. No extra hardware required.
Granted, it's a bit of a hack and not a true 60fps framerate, but it really does make a difference for your eyes.
PS, it's OK to not get/understand the details. Some is mostly just eye/ear candy for the graphic geeks among us.
This new bit of hardware whizz-bangery will sit at the end of the graphical pipe. It buffers a frame until it recieves a second frame. It looks at the buffered frame and the new frame it's recieved, and does a bit of jiggery-pokery to come up with another frame that looks like it could be in between the buffered frame and the new one.
<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>
Buffered frame
_________
| |
| |
| * |
| |
---------
Next frame
_________
| |
| |
| * |
| |
---------
Interpolated frame
_________
| |
| |
| == |
| |
---------
</div>
It then sends out the buffered frame, followed by the interpolated frame 16.6 ms later. It buffers the new frame, and awaits the delivery of the next new frame. It's running 33.3 ms behind real-time to allow for the buffering. You don't get any extra detail, just extra perception of fluidity.
--Scythe--
Kouji wins this thread btw
Scythe and his breaking it down for the laymen....
WON.
Yeah. And at zero extra hardware cost.
<a href="http://www.google.com/images?q=ear%20candy" target="_blank">http://www.google.com/images?q=ear candy</a>
<!--quoteo(post=1796754:date=Aug 29 2010, 09:44 AM:name=That_Annoying_Kid)--><div class='quotetop'>QUOTE (That_Annoying_Kid @ Aug 29 2010, 09:44 AM) <a href="index.php?act=findpost&pid=1796754"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Kouji wins this thread btw<!--QuoteEnd--></div><!--QuoteEEnd-->
<img src="http://members.home.nl/m.borgman/ns-forum/smileys/dancing-banana.gif" border="0" class="linked-image" /> postcount +1 as well
Or wait a sec, you're saying it takes time to render a frame, and while this is going on we can take the time to fake this interpolated frame and insert it? In that case that's awesome. And simple. Cool.
Or wait a sec, you're saying it takes time to render a frame, and while this is going on we can take the time to fake this interpolated frame and insert it? In that case that's awesome. And simple. Cool.<!--QuoteEnd--></div><!--QuoteEEnd-->
Frame buffers are standard practice nowadays. In fact, there are some who advertise spiffy things like triple frame buffering!
The reason is to prevent tearing while generating the frame which degrades the image and causes nausea. Plus, we render each frame's pixels sporadically and out-of-order, while a monitor requires that the information be streamed in a very specific pattern. Also, for computers, if you're rendering slower than the refresh rate of the monitor, you need to keep an old frame around for the screen to fetch while it waits for the new one.
Also, the time spent in the buffer is very, very small. Remember, running at 30fps means, assuming a frame buffer depth of 1, only 1/30th of a second delay. That's 33ms. Most people don't even have internet that fast.
So, since everyone already agreed that frame buffers are good and everyone uses them, this project takes that little extra time while a frame is in the buffer to interpolate, generating a new frame to help smooth the picture on the slower console systems.
True. For a PC.
However, real competitive players use something called 60fps which has only 16ms delays. On a PC.
They extrapolating forwards from one frame and extrapolating backwards from the next, then merging the two to create the interpolated frame. They're not just extrapolating forwards as I believed.
<!--quoteo(post=1796494:date=Aug 27 2010, 08:46 AM:name=Chris0132)--><div class='quotetop'>QUOTE (Chris0132 @ Aug 27 2010, 08:46 AM) <a href="index.php?act=findpost&pid=1796494"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm skeptical about this, because if it was as simple as rendering 30fps and then blurring between them, surely someone would have done it already.<!--QuoteEnd--></div><!--QuoteEEnd-->
That's not what they're doing at all. Just bluring frames toghether with no further processing does nothing useful. They're rendering a velocity map and extrapolating the motion forwards from one frame, and backwards from the next; they use various cheap tricks to try and fix up artifacts, especially around players.
I can see the difference between 100 and 120 FPS. Because of tearing I can also tell the difference between 200 and 120 FPS. You can fix that with VSYNC though but it'll add a bit of mouse lag, same thing with this console thingy because you need extra buffering. That's why many competitive players don't use triple-buffering and vsync but higher FPS to issue tearing.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->However, real competitive players use something called 60fps which has only 16ms delays. On a PC.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'd never play NS with 60FPS if I had a choice. That's just horrible. 200FPS is the norm at the moment.
In live music performance, you've to have audio lag less than 10ms, something like 2-4ms would be optimal otherwise it'll affect the rhythm.
Motion blur or sampling is used in frag movies to catch up the low FPS although it takes a lot of computing power. The idea there is to blur everything that's moving.
Yeah. At the end of the day, you'd rather have uber fps and minimal lag for actually competitive stuff. Most people see into the 80+fps region. You're unique to reach 120fps on your eyes.
But, well, consoles suck like that and are capped at 30fps......
But that's for entirely different reasons and well you know it, Jiriki. Modern engines do not have movement code so tightly coupled with the render path.
30fps is the norm for consoles because ATSC only defines HDTV up to 30fps ( the US standard ). DVB (euro) defines it up to 60fps, and most HD TV sets now support 60fps inputs. This discussion really has nothing to do with how PC gaming behaves, which is an entirely different discussion IMO.
I laughed when I read this.
Jiriki is Jake 2.0