Following is an excerpt from GDAlgorithms-list (http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list) ================================================================================ From: De Boer (bertdb^iinet.net.au) Subject: [Algorithms] 60hz is the holy grail Date: Sat, 09 Aug 2003 12:38:06 -0700 On the framerate issue, I've read many differing views on what the eye can detect. PAL TV does about 25 fps and I think NTSC is about 30 fps. They seem smooth. I read somewhere that some cartoons (which appear smooth) used less then 20fps. I know already everyone seems to think 60fps is what everyone should do (and since you all have the experience then perhaps I should to). I know with screens etc that doing 60hz pretty much maximizes what you can get with hardware, but does the eye really detect the difference? Ive read many differing views on this, the subconsious may be able to detect higher fps and of course if you have a wheel moving at exactly the speed of the framerate it may appear to be still. I supose a character in a game that moves really really fast may appear to "teleport" across the screen since they move faster then the framerate. Is this ever a problem? But TV may have pretty fast cars/kung fu, maybe TV blurs though whereas games wouldn't. Now I suppose if you are doing stuff like physics/AI per frame the more frames per second the more other stuff you can do (which does make a difference), but if we are just talking about graphics is 60fps vs say 30fps really noticable to the eye? If you aim for 30fps it would piss you off if it dropped to 15fps, so I guess aiming for 60fps is better because then at the worst points it may only drop to 30fps. And since games really do have physics etc to worry about (TV doesnt) then 60fps may be the better option. I already think its strange when people say "quake3 runs at 200fps" wow I'm sure their eyes would detect that especially when its limited by screen refresh rate anyway. Maybe if I video captured the output of a fast fighting game at 25fps then I may be able to find out if I can see the difference. Is this a valid experiment? I remember killer instinct was extremely fast and I think they said it was 60fps. Camera movement is probably also an issue, I find the faster the camera moves the lower the fps I can get away with (I am assuming everything is in memory, I know this would not be the case if data had to be streamed or loaded dynamically etc, there are probably more assumptions too, physics would certainly stuff it up too..). I'm sure once a project reaches a certain size the faster the camera moves you need a faster framerate. -Ryan De Boer ================================================================================ From: "Ivan-Assen Ivanov" (assen^haemimont.bg) Subject: Re: [Algorithms] 60hz is the holy grail Date: Sat, 9 Aug 2003 22:50:25 +0300 > I already think its strange when people say "quake3 runs at 200fps" wow I'm > sure their eyes would detect that especially when its limited by screen > refresh rate anyway. Elite Quake players have always played with ultra-low resolution and quality settings to achieve the maximum frame rate. The reason is that not only the game world gets displayed 300 times per second (which your eyes might not see), but also the game samples your input 300 times per second, which, being a grandmaster with an insane mouse sensitivity, you'd definitely notice. Somewhat related to the framerate question: To achieve smoother motion with lower framerates, you need motion blur (just like to achieve smoother edges with lower resolution, you need antialiasing). Games got antialising for free due to a brute force hack done first by the drivers (I believe) - FSAA, and then later MSAA, done by the GPU which is actually more economical for the GPU. Maybe something like that can be done for motion blur? The problem is, the card will have to somehow buffer the entire frame to benefit from interframe coherence, which I somehow don't see happening anytime (or at all). But the drivers ARE buffering several frames. Maybe someone from the IHVs will point out how stupid that suggestion is? ================================================================================ From: "Jonathan Blow" (jon^number)-none.com> Subject: Re: [Algorithms] 60hz is the holy grail Date: Sat, 9 Aug 2003 15:08:03 -0500 > On the framerate issue, I've read many differing views on what the eye can > detect. There are many other interactivity issues, aside from what the eye can detect. If you're running at 30fps, then the amount of latency between when the user does something, and when he sees it happen in the world, is going to be between 33ms and 82ms, with the average being in the middle. 82ms is a lot, and the variance between 33 and 82 is a lot. In terms of interactivity, I would much rather be playing quake3 at 200fps than at 33fps. (I also wrote a gdmag article once where I traced through the i/o path of a client/server game and showed how in a lot of cases more of the lag is due to frame rates than network latency). That said, though, I can definitely see the difference between 30fps and 60fps. There's nothing subconscious about it. And if they're running right next to each other for you to A/B them, the difference is totally obvious. I think the "your eye can't see that much" is some kind of myth built on insufficiently-thought-about facts. But don't believe me, do the experiment yourself, just code up a tunnel app or something and put in a togglable option that limits its frame rate at 30. Cartoons appear smooth at 20fps because animators do all kinds of wacky stretch things to their characters to give the impression of motion between frames. If you look at any individual frame of a good cartoon, it is totally whack. There is a famous Disney book about how to do this or something. ================================================================================ From: Tom Hubina (tomh^vexxed.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Sat, 09 Aug 2003 13:26:05 -0700 At 12:38 PM 8/9/2003, you wrote: >But TV may have >pretty fast cars/kung fu, maybe TV blurs though whereas games wouldn't. This is more or less the reason. First, standard NTSC (480i) has 60 ~640x240 interlaced fields per second. The interlacing produces 30 frames of ~640x480 per second. When using progressive scan DVD players, they actually output high definition 480p .. which is, 640x480 at 60fps. There's also 720p and 1080i. I belive the XBox is capable of generating one or more these outputs on some games, with the proper cable. That said, a frame of television is typically gathered from film (or a video camera which emulates film). Each from of the film is exposed to the scene for X amount of time, during which time any motion is blurred across the film. When played back at the proper rate, all motion looks nice an continuous, though fast motion can look excessively blurry and bad. A game on the other hand, is a instantaneous snap shot of a scene that contains no blurring. To provide a smooth illusion of motion, you need to increase the number of samples in time (the frame rate). The higher the refresh rate, the better things look, especially fast moving objects. If you're on a display running at a 125Hz refresh and have a fast moving cheetah in the distance, you may not be able to distinguish the animals legs at each frame, but the blending your eyes and the phosphors will produce will look much more like real life, than having the cheetah discretely jump between different states at 60Hz. So while the human eye can't distinguish more detail, you're now putting the blurring into the eye and keeping the motion more like what we would see in real life. You could also render at 200fps or higher into an accumulation buffer and display at 60Hz and you'd end up with pretty much the same thing as TV. Now that we have higher resolution frame buffers, this starts to become possible. I can definitely see consoles in the future trying to do this after they max out super-sampled HDTV resolution and single scene quality since they're hard limited to 60 fps. Though that's probably going to be about 15 years down the line .. hehe ;) The other thing to mix into the pot is response times for input devices. When running at 60Hz, the max response time is 16.6ms, and at 125hz (or higher with vsync off) it's 8ms. Doesn't seem like much, but the super uber twitchy Quake players, well, they can feel the difference ;) Tom ================================================================================ From: De Boer (bertdb^iinet.net.au) Subject: Re: [Algorithms] 60hz is the holy grail Date: Sat, 09 Aug 2003 13:36:44 -0700 Actually I think now I've thought about it much more google is giving me better results. Eg: http://www.daniele.ch/school/30vs60/30vs60_2.html TVs do blur so I guess one of my predictions were correct. I wonder if this means PS2 games can then look better than equivalent PC games due to the TV blur at 30fps. Still games designed to play on TVs still aim for 60fps. I used to like how the TV blured really old games (for free) so pixelization weren't noticable. >the game samples your input 300 times per second Yes the input samples definitely an issue. It is a bit disapointing having to double from 30 to 60 because motion blur. Do PS2 games get motion blur for free on TVs? I wonder if drawing half as much and say reducing visual quality by half is worth the degredation in user interation. ATM some of the measures I have are: speed - frame time, fps quality - image metrics, #polys, #objects, texel/pixel ratio, #high detail/low detail objs "Interactivity" - I could measure from mouse movement from the API until the resulting frame drawn, but I think this will be very close to just frame time (no physics etc to increase time). I could get users to rate their interactivity see if they think 60fps is better. It would be nice to make a statement that 60fps increased interactivity by bla % but decreased visual quality by bla %. Any other important things I should measure? Maybe frame coherency by comparing differences between frames, but I think that might be too hard. -Ryan De Boer ================================================================================ From: Ken Paulson (ken^drunkenhyena.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Sat, 09 Aug 2003 16:09:42 -0500 At 03:08 PM 8/9/2003, you wrote: >That said, though, I can definitely see the difference between 30fps >and 60fps. There's nothing subconscious about it. >And if they're running right next to each other for you to >A/B them, the difference is totally obvious. I think the "your eye can't >see that much" is some kind of myth built on insufficiently-thought-about >facts. But don't believe me, do the experiment yourself, just code up >a tunnel app or something and put in a togglable option that limits >its frame rate at 30. There was a 3DFX demo that split the screen and updated one side at 30Hz and the other at 60Hz. It was designed to show just how significant a higher frame rate can be. IIRC it had a simple animation of a ball bouncing. ================================================================================ From: "Jurjen Katsman" (jkatsman^nixxes.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Sat, 9 Aug 2003 23:40:47 +0200 The blur Tom Hubina is talking about is different from the 'free' TV blur. That blur is really just that the display is crappy, and pixels aren't as sharp. It doesn't solve the framerate problem, is has nothing to do with it. It does make antialiasing less of an issue. (But then interlacing can make it more of an issue again..) The blur Tom was talking about is from how the data was created. Film is a continuous sampling of light values, and computers tend to produce a single snapshot at a certain time interval. Just reread what he said. - Jurjen ================================================================================ From: "Jonathan Greenberg" (jongreenberg^mindspring.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Sat, 9 Aug 2003 19:40:16 -0500 Basically, one way to think about this is that real world cameras allow exposure of the film over a certain chunk of time. So, if an object moves during the time that the film is being exposed, it will blur, because light is reflecting off the object differently as it changes position, orientation, etc. When you're in a game, you tend to render a frame (equivilent to exposing a frame of film) as if it were sampled instantaneously. So there's naturally no blur in games. Some games, like GTA, use feedback effects to fudge motion blur. More or less, the last frame is blended with the current frame to give a cheap impression of inter-frame blur. Ideally, as Tom points out, we'll eventually be able to spare the performance to fake motion blur by taking multiple samples of the frame and thus -to some extent- faking the way things are sampled over time on a real camera. Jon ================================================================================ From: "Nicolas Romantzoff" (nicroman^free.fr) Subject: RE: [Algorithms] 60hz is the holy grail Date: Sun, 10 Aug 2003 03:01:31 +0200 Just to add 2 eurocents to this... Some recent movies do present parts filmed at 50Hz, and restored "normally" at 25Hz (taking one frame out of 2). The result is a very "sharp" moving of everything, and I know some friends simply not supporting it (headaches), just like spending hours under stroboscope. Additionally, the monitor's resolution is very important... Especially with those very high contrast monitors we have now... I couldn't ever work on 1600x1200 resolution at 60Hz on any CRT monitor, though everything is ok at 75Hz (and even better at 82Hz). A 640x480 resolution however can be used at 50Hz without any problem. Nicolas ================================================================================ From: "Conor Stokes" (cstokes^tpgi.com.au) Subject: Re: [Algorithms] 60hz is the holy grail Date: Sun, 10 Aug 2003 14:37:00 +0800 > Just to add 2 eurocents to this... > > Some recent movies do present parts filmed at 50Hz, and restored > "normally" at 25Hz (taking one frame out of 2). > The result is a very "sharp" moving of everything, and I know some > friends simply not supporting it (headaches), just like spending hours > under stroboscope. > > Additionally, the monitor's resolution is very important... Especially > with those very high contrast monitors we have now... > I couldn't ever work on 1600x1200 resolution at 60Hz on any CRT monitor, > though everything is ok at 75Hz (and even better at 82Hz). > A 640x480 resolution however can be used at 50Hz without any problem. Working is slightly different though - if you're looking at a monitor displaying smallish text you get visible flicker at resoltions lower than 75hz or so - which makes your eyes feel like they're bleeding. 60hz monitor refresh for games, which generally use big text and are full of motion anyway, are less of a problem. Conor Stokes ================================================================================ From: Tom Forsyth (tomf^muckyfoot.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Sun, 10 Aug 2003 12:19:36 +0100 The flickering of a CRT is more to do with the persistence of the glowing phosphor dots. Televisions are tuned for 50Hz, so their phosphor/electron beam is tuned so that the dot stops glowing after a 50th of a second. Actually, since it's interlaced, they're tuned to stop glowing after a 25th of a second. Older monitors that only do 60Hz are tuned for that. New fancy monitors are designed so that the dots fade after only 100th of a second (or whatever speed they do). So giving them a 60Hz signal means that half the time, the dots aren't glowing at all. Which produces horrible flicker of course. Having said that, at lower resolutions low refresh rates do seem to be slightly more acceptable - presumably because of some cunning cirucitry inside the tube (guess - maybe they defocus the beam and ramp up the strength to make a bigger dot, and the beam moves slower so that each dot gets hit for longer and so glows longer?) There's four distinct effects: (1) Flicker. You can get this with a plain white screen - nothing to do with motion, everything to do with how much it flashes. A lot of people can't see flickering even at 60Hz, but many need to go up to at least 75Hz (that's me), and some people can see flicker even at 85Hz. (2) Smoothness of motion without blurring. 50/60Hz is the "holy grail". It's not that things at 30 look bad, it's just that they look better at 60. But for certain types of game (strategy style "god cams"), the difference is tiny, and if it means your game looks twice as good, then that's fine. (3) Smoothness of motion with blurring. Film has 24 frames per second (though note they show each frame multiple times - usually two to four times to avoid flickering from effect (1)), and people seem to think that's fine (though personally I hate it when films do a big scenic pan across glorious landscape - they judder like crazy). TV seems to work better because although it's a complete picture at 25/30Hz, the fields are interlaced so you do get some of the effects of 50/60. (4) Latency. Higher framerate = lower latency. Only relevant for interactive games of course - TV and movies don't care. I think that's most of the effects covered. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. ================================================================================ From: "Conor Stokes" (cstokes^tpgi.com.au) Subject: Re: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 02:18:01 +0800 There is actually an effect you left out - and this was the main one I was commenting on with reference to "small text". Each frame from a CRT is offset slightly from the last - which leads to "jumping" pixels. However, once your referesh rate is higher than 75hz or so, your eyes can't see the motion - it ends up as a blur. A lot of the eyestrain associated with low refresh rates comes from this problem. However, when you aren't focusing on a small area, it won't effect you. Conor Stokes ================================================================================ From: Kevin Ng (Kevin.Ng^warthog.co.uk) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 00:12:22 +0100 There may be applications for doing sub-frame renders for selected objects to approximate true (non-instantaneous exposure effect) motion blur. For example, in a snooker / pool game, it may be worth doing sub-frame renders of the balls in motion, as these are fast-moving objects, and doubly, shouldn't take too long to render. kev ================================================================================ From: "Michael Pohoreski" (MPohoreski^cyberlore.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 10:44:11 -0400 - The benefit from a higher framerate is one of exponetial fall-off. - I can tell the difference between 30 and 60. One is silky smooth. One is not. - I usually crank my monitor refresh up to 100 Hz because the image is *rock solid*, compared to a head-achey flickering 60 Hz. - You also need a super high frame rate, since TV's automatically have temporal aliasing. FSAA definately helps out on monitors. - You want shooters running excessively over 60+ because your frame rate WILL drop in the worst case: when you have 32 players in view all at once, with everyone firing their weapons, with all the weapon effects. ================================================================================ From: "Michael Pohoreski" (MPohoreski^cyberlore.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 10:48:48 -0400 If PC's are stuck with the same crappy PS2 textures (without mip-maps), then yes. ICO, and Vice City, do a ~3 frame-buffer blur. Looks really nice. Otherwise PC graphics make the PS2 look like the PSX. (Texture-Swimming is still hideous on the PS2.) ================================================================================ From: Troy Gilbert (TroyG^csl.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 16:40:46 +0100 > You also need a super high frame rate, > since TV's automatically have temporal > [anti-]aliasing. TVs may do a form of temporal anti-aliasing (afterglow of phosphors), but this is not a natural form of temporal anti-aliasing. True (and in my mind, useful) temporal anti-aliasing would work just like mutli-sampling anti-aliasing for the framebuffer: you have to render 2x to 4x the amount of information to reproduce the analogue equivalent (motion blur). Whoever posted previously about future video cards / consoles doing this internally is on the right track... In fact, I wonder if anyone has seriously investigated implementing temporal super-sampling on the GPU? I.e., for each frame actually render 3-4 frames and blend them? OR, would it be possible through VS/PS to actually directly render traingles/pixels that interpolated in both space and time? Hmm... Troy Developer Relations Criterion Software www.csl.com ================================================================================ From: Gareth Lewin (GLewin^climax.co.uk) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 17:00:52 +0100 > directly render traingles/pixels that interpolated in both space and time? Hmm... Careful there child, you mess with things that are better left to Nature... But seriously. you step thru your frames at 1/4th the elapsed time, and rendered offscreen, then blended the results, you could get a similar effect. Just not sure if it's worth the render time, although, in theory, you could run at a lower framerate ================================================================================ From: Tom Forsyth (tomf^muckyfoot.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 17:11:48 +0100 It's probably better to actually show those 4 frames at 120Hz rather than blur them together and show tham at 30Hz. Same argument for FSAA - better to actually show a 1920x1440 screen than do 3x3 640x480. The only time you really want this stuff is if your display device just doesn't go that high (telly or cheaper monitor) but your rendering speed is actually enormous. Things like multisampling do speed up FSAA in a way that doesn't translate directly to higher resolutions though, meaning that 4x4 800x600 may be just as fast as 1600x1200. In that case, there's a decent argument for using it. I guess the equiavlent of multisampling for temporal anit-aliasing is something like Kevin Ng suggested, though most of the schemes I can think of fall over when the camera moves, which it usually does. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. ================================================================================ From: "Jurjen Katsman" (jkatsman^nixxes.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 17:52:13 +0200 Texture swimming on the PS2?? What are you talking about? ================================================================================ From: "Alen Ladavac" I'd say that it is not as simple to do supersampling for > temporal antialiasing as it is for spatial. > For temporal antialiasing you can easily introduce holes > between two pictures of one object, if the > object is moving very fast (comparing its distance over frame > with its size). The end effect could > be worse than without any temporal antialiasing. This is true if you are rendering at a low framerate, but as long as your real output framerate holds 60, the eye will read these trails as a continuous motion rather than seeing them as separate instances of the object. If you have to choose between running at 30 fps with 2x temporal supersampling, or 60 fps without, you should obviously go for 60, but if you are already running at 60, additional sampling frames will make a big difference to the output quality. In fact, if you are running at 60 just blending in some amount of the previous frame is a useful effect. Lots of people like to make fun of this, but it works well in practice. Unlike true supersampling, this isn't adding any additional data to the output scene, making it the temporal equivalent of a fullscreen blur rather than antialiasing, but that can still be a valuable artistic effect if used at the right times (and if used at 60 fps: it breaks down badly at lower framerates). -- Shawn Hargreaves Climax Brighton ================================================================================ From: Brian Hook (hook_l^pyrogon.com) Subject: Motion blur was RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 13:58:25 -0400 > I took the liberty implementing this kind of thing and I must say > that results look absolutely amazing even at 2x but 3x the time > step gives by my opinion best results. I read that page, but didn't download the demo, but is this motion blur effectively just supersampling the time stream, rendering multiple subframes, averaging them together, and then displaying that? So, if I'm understanding this correctly, if you're running at a nominal 30Hz but doing 3x, you actually do a render as such: clear framebuffer clear Z render at time T, add to frame buffer at 33% clear Z render at time T + 11, add to frame buffer at 33% clear Z render at time T + 22, add to frame buffer at 33% display That's my naive first impression. Quantization artifacts might suck though. Brian ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: Re: Motion blur was RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 11:58:55 -0700 > clear framebuffer > clear Z > render at time T, add to frame buffer at 33% > clear Z > render at time T + 11, add to frame buffer at 33% > clear Z > render at time T + 22, add to frame buffer at 33% > display > That's my naive first impression. Quantization artifacts might suck > though. Hmm, you're going to need 3 buffers here; Screen, accumulation, render. Screen is display size. Accumulation is N*display size, for FSAA Render is the same size as accumulation, and has a z-buffer clear accumulation for (sub_frame = 1;sub_frame<=num_sub_frames;sub_frame++) clear render draw to render at t + (sub_frame/num_sub_frames) blend render with accumulation at 1/sub-frame // assuming an even blend over time copy accumulation to screen You can optimise out the first blend to accumulation, it you can move the z-buffer from buffer to buffer, and back again. Cheers, Phil ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 11:48:36 -0700 > You've never suffered texture swimming on the PS2?=A0 Lucky man ... > clipping is a killer for it =3D)=A0 There are ways round it, admittedly ... Like not having a crappy clipper? The textures should be fine, however, I do recall that the interpolated colour isn't perspective correct, and does 'swim' under clipping. Large triangles are particularly bad, but then they're display-cache-unfriendly as well, so should be avoided anyway. Plus, the smaller they are, the less likely they need to be clipped, which is always a win on the PS2. You are taking advantage of the guard band? Cheers, Phil PS Sub-frame rendering eh? I had wondered what we were going to do with all that fill rate coming down the pipe in the next couple of rounds of hardware. ================================================================================ From: "Rusch, Matthew" (MRusch^EA.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 13:31:49 -0700 ? You still clip in software on the ps2 right (with the exception of = the guard-band)? Why can't you make it perspective correct? Please = excuse my ignorance, I haven't worked much with the ps2. I know that = somewhat recent pc hardware did linear interpolation for colors, but = that has since been corrected (I think). ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 14:46:49 -0700 > You still clip in software on the ps2 right (with the exception of the guard-band)? Yes, which is why you go as far as possible to avoid doing it. > Why can't you make it perspective correct? You can, and do, except that the colour interpolation isn't perspective correct, but it only really shows up when you clip large polys (IIRC, certainly that was the case with early VooDoo cards, and they did the same thing). > Please excuse my ignorance, I haven't worked much with the ps2. I know that somewhat recent pc hardware did linear interpolation for colors, but that has since been corrected (I think). Yeah, that's pretty much the state of the GS. It's very very fast, but it's lacking in modern features. The vertex shader (aka VU1) however, kicks ass. If you get the opportunity, I highly reccomend checking out Mike Day's VUniverse demo from the SCEA/SCEE VU demo contest. Galactic flyby, and fractal terrain rendering with rippling water reflections and everything. Entirely on the VU. Old Skool Hardcore! Cheers, Phil ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 14:59:30 -0700 > If you get the opportunity, I highly reccomend checking out Mike Day's VUniverse demo from the SCEA/SCEE VU demo contest. Galactic flyby, and fractal terrain rendering with rippling water reflections and everything. Entirely on the VU. Old Skool Hardcore! Sorry, I should add that you're going to need a PS2 devkit to see it, and have access to the ps2-pro site to download it (search for vuniverse). Again sorry for the PS2-ness of this post. Cheers, Phil ================================================================================ From: Charles Bloom (cb^cbloom.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 15:09:33 -0700 At 11:48 AM 8/11/2003 -0700, you wrote: > > You've never suffered texture swimming on the PS2? Lucky man ... > > clipping is a killer for it =) There are ways round it, admittedly ... > >Like not having a crappy clipper? The textures should be fine, however, I >do recall that the interpolated colour isn't perspective correct, and does >'swim' under clipping. You can of course also clip colors perspective-correctly, but perhaps it's not worth the expense if you know your triangles are reasonably small. -------------------------------------------------------------------------------------------- Charles Bloom email "cb" http://www.cbloom.com ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 15:36:20 -0700 > Sorry, I should add that you're going to need a PS2 devkit to see it, and > have access to the ps2-pro site to download it (search for vuniverse). Apparently it's also availably on the ps2-linux site, so you'll only need a ps2 linux kit. http://playstation2-linux.com/projects/vudemocontest/ > Again sorry for the PS2-ness of this post. Again, and again. Although the package does contain a document describing how he did it, which may be of more general interest. Cheers, Phil ================================================================================ From: "Jurjen Katsman" (jkatsman^nixxes.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Tue, 12 Aug 2003 01:46:07 +0200 You can clip the color perspective correct, but per pixel that still aren't. In many ways that even means that clipping them NOT perspective correct often looks better. - Jurjen ================================================================================ From: "Bretton Wade" (brettonw^microsoft.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 22:58:47 -0700 I don't think this is a good idea for primary game elements. The problem is that people (the human visual system, not cameras) track moving objects in such a way that they don't blur. The net result is that motion blur makes interactive tasks and navigation more difficult in an unnatural way. Secondary objects and effects should definitely be considered for this treatment, but you won't want your entire frame architecture to be built around it. -- Bretton Wade (aka Noz Moe King) in Bellevue, WA ================================================================================ From: "Pallister, Kim" (kim.pallister^intel.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 23:02:32 -0700 To be pedantic, the dots don't "stop glowing" so much as they decay to a certain level deemed to need refreshing at that point. KP ================================================================================ From: "Pallister, Kim" (kim.pallister^intel.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Mon, 11 Aug 2003 23:02:32 -0700 I did a bunch of research on the 30vs60 issue a while back to settle a bet with someone at work. Turns out (surprise) there's a ton of military-funded, sim-related research into the subject. There are many many factors that affect the frame rate at which someone perceives discrete frames vs smooth animation. Some include: - intensity of different objects involved (black on white, grey on grey?) - color (yes, turns out the attack/decay of the light hitting your retina is different for different colors) - display type (someone mentioned this - phosphors on a TV tube will have a slower decay than a high-end monitor, and thus do a certain amount of 'motion blur' for you) - many others, plus, it varies per individual. Bottom line was that 20-25fps is generally good enough to get people to beleive what they are seeing is moving; between 45-60 most people can no longer distinguish deltas between frames for most stuff, and somewhere around 75 and up is rock solid, silky smooth for *most* content and most individuals. I say *most* because you can stare at a 75hz strobe light and it won't look constant, it'll have a flicker to it. I wish I could remember what the papers were. They had some nifty experiments they did to test this stuff. KP ================================================================================ From: "Jon Watte" (hplus^mindcontrol.org) Subject: RE: [Algorithms] 60hz is the holy grail Date: Tue, 12 Aug 2003 11:23:41 +0200 > On the framerate issue, I've read many differing views on what the eye can > detect. PAL TV does about 25 fps and I think NTSC is about 30 > fps. They seem TVs actually render interlaced fields at twice the frame rate. Thus, a NTSC TV will render odd-numbered scan lines 29.97 times a second, and then even-numbered scan lines 29.97 times in the same second, leading to a total field rate of 59.94 fps. It is quite plausible that a "60 Hz" game can look and feel snappier than a 30 Hz game which displays the same frame for odd and even frames. (Real video gurus: bear with me, I'm simplifying for the sake of clarity, OK? :-) In fact, it's been posited that viewers can tell the difference between footage shot on video (60 fields per second) or film (24 frames per second) mostly because some fields are "the same" as the previous field (owing to the 3:2 pull-down). Note that the fill rate is the same for a 60 fps and a 30 fps game: 60 fields of 240 (or 243) lines times 640 pixels across (or 704, or 720 :-) times 60 fields per second is the same as 480 (or 486) lines times 640 pixels times 30 frames per second. However, your geometry and game update loop of course takes twice the hit at the higher rate. > I already think its strange when people say "quake3 runs at 200fps" wow I'm > sure their eyes would detect that especially when its limited by screen > refresh rate anyway. The tournament Quake players claim that their wrists detect the frame rate drop when it goes from 200 fps to 50 fps. After all, it increases lag from 5 ms to 20 ms on input, and haptics is notorious for requiring really high frame rates to work well. This is just speculation, but I think there might be something in there. Cheers, / h+ ================================================================================ From: (Paul_Firth^scee.net) Subject: RE: [Algorithms] 60hz is the holy grail Date: Tue, 12 Aug 2003 10:55:17 +0100 >Note that the fill rate is the same for a 60 fps and a 30 fps game: 60 >fields of 240 (or 243) lines times 640 pixels across (or 704, or 720 :-) >times 60 fields per second is the same as 480 (or 486) lines times 640 >pixels times 30 frames per second. However, your geometry and game update >loop of course takes twice the hit at the higher rate. On two consoles at least you can take advantage of the fact that the screen is interlaced and render to fields of 640x256 at 50hz and thus reducing the fill rate requirement to half yet loosing no resolution over rendering full height buffers since the tv only samples every other scanline at 50hz. Of course, this relies on running at a constant 50hz and *never* dropping. Cheers, Paul. ================================================================================ From: "Jonathan Blow" (jon^number)-none.com> Subject: Re: [Algorithms] 60hz is the holy grail Date: Tue, 12 Aug 2003 10:12:58 -0500 Jon Watte wrote: > The tournament Quake players claim that their wrists detect the frame rate > drop when it goes from 200 fps to 50 fps. After all, it increases lag from > 5 ms to 20 ms on input I want to re-emphasize that there are several kinds of lag, there's "control lag" (how long it takes for your input to affect the world) and "feedback lag" (the time it takes you to see the result of your successful control action) and if you wind these into a loop you also get "perception lag" (the time between when something happens, and when it's displayed on the screen for you to see it). So if you are talking about someone playing a shooter, and trying to gauge how the game system feels in terms of responsiveness, you pretty much have to add (perception + control + feedback) lag. On average, perception lag is 1 frame + k, control lag is 0.5 frames, feedback lag is k, where k is 0.5 * monitor_refresh_time + C if you have vsync turned off. So for a 100Hz display, k is maybe 13ms... a 200fps game will give you an average cyclical lag of about 20ms, a 50fps will give you 43ms. That's pretty much the minimum, if the game is non-networked and well-coded (most games are not non-networked and well-coded). So whereas you might say "Hmm, 5 ms or 20ms, maaaaybe that makes a difference but it's probably not a huge deal", it starts to sound bigger in the 20ms-43ms case. A networked game will be worse than this, before you even add in physical network lag. These lag numbers jump around pseudorandomly from input to input, also, so the 200fps frame rate gives you more consistent response than the 50fps one does, in addition to shorter average roundtrip time. Probably this is important. - Jonathan. ================================================================================ From: Thatcher Ulrich (tu^tulrich.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Tue, 12 Aug 2003 23:29:35 -0400 On Aug 12, 2003 at 10:12 -0500, Jonathan Blow wrote: > Jon Watte wrote: > > > The tournament Quake players claim that their wrists detect the frame rate > > drop when it goes from 200 fps to 50 fps. After all, it increases lag from > > 5 ms to 20 ms on input > > I want to re-emphasize that there are several kinds of lag, there's > "control lag" (how long it takes for your input to affect the world) > and "feedback lag" (the time it takes you to see the result of your > successful control action) and if you wind these into a loop you > also get "perception lag" (the time between when something happens, > and when it's displayed on the screen for you to see it). > > So if you are talking about someone playing a shooter, and trying to > gauge how the game system feels in terms of responsiveness, you > pretty much have to add (perception + control + feedback) lag. On > average, perception lag is 1 frame + k, control lag is 0.5 frames, > feedback lag is k, where k is 0.5 * monitor_refresh_time + C if you > have vsync turned off. So for a 100Hz display, k is maybe 13ms... a > 200fps game will give you an average cyclical lag of about 20ms, a > 50fps will give you 43ms. If vsync is off, I disagree with your formula for k, for the case of tall (screen-height) objects or backgrounds. For objects like that, k can be close to 0. (Maybe you meant to say "if you have vsync turned ON"?) Anyway. Because monitors scan progressively from top to bottom, it's possible to perceive visual changes at the horizontal refresh rate. I suspect this is what those tuned-up Quake players are noticing. Thought experiment: lets say you could run your game at 28800 fps, on a 640x480 CRT display refreshing at 60Hz. 28800 == 60x480, so you're generating a new frame in time to display each of the 480 horizontal scan lines (roughly -- pardon me for ignoring the vblank interval). Let's say the player is moving the mouse sideways at a constant rate, so the camera is rotating in place. The image of a vertical object, like the edge of a wall, will actually slant sideways as the monitor scans from top to bottom, since the wall is changing position between each scan line. If you rendered this same scene at 60 fps with vsync turned on, the image of the wall would appear perfectly vertical, even when the camera is rotating. The amazing thing is, this effect is *easily* perceptible! The vsync'ed version looks demonstrably wrong! There's a UNC paper from 1995 that explains it all: http://www.cs.unc.edu/~olano/papers/latency/ The demo (from the paper) is really simple. Unfortunately I can't find the original video posted on the web, so I'll describe it (if someone is curious enough maybe they can code it up and post a demo): With conventional vsync'd rendering, show a tall object moving across the screen. Then, show the same thing again, but shear the object so that the bottom of the object is warped in the direction of motion. Getting the right shear involves a little algebra (see the paper). The unsheared moving object clearly appears sheared when displayed on a CRT, while the sheared object appears vertical. -- Thatcher Ulrich http://tulrich.com ================================================================================ From: "Jonathan Blow" (jon^number)-none.com> Subject: Re: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 00:39:11 -0500 > If vsync is off, I disagree with your formula for k, for the case of > tall (screen-height) objects or backgrounds. For objects like that, k > can be close to 0. (Maybe you meant to say "if you have vsync turned > ON"?) Well it was an ad hoc number, but what it's based on is "if the current scan line is in a random place, and the feature on the screen is in a random place, then on average they're half a frame away from each other, which is 5ms at 100Hz, add in a few extra milliseconds for like phosphor changes and the fact that your feature's size will not be 0 and you probably need to scan out a nonnegligible amount of it before it can be recognized". So I don't really know what the exact k would be, but the important thing is that it exists, and it fluctuates in the neighborhood of 0+epsilon to 10+epsilon for 100Hz. > Anyway. Because monitors scan progressively from top to bottom, it's > possible to perceive visual changes at the horizontal refresh rate. I > suspect this is what those tuned-up Quake players are noticing. Hmm, yeah that could be. So far I have just opted to ignore horizontal effects since my vertical numbers are pretty hand-wavy already. > The amazing thing is, this effect is *easily* perceptible! The > vsync'ed version looks demonstrably wrong! There's a UNC paper from > 1995 that explains it all: > > http://www.cs.unc.edu/~olano/papers/latency/ > > The demo (from the paper) is really simple. Unfortunately I can't > find the original video posted on the web, so I'll describe it (if > someone is curious enough maybe they can code it up and post a demo): Hey that is a really interesting reference... I will have to read it when I am not totally tired. I guess the moral of the story is, hey, making games is complicated. ================================================================================ From: "David Clyde" (dclyde^ameinc.com) Subject: Re: Re: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 03:16:03 -0400 From: "Jonathan Blow" (jon^number)-none.com> > Hey that is a really interesting reference... I will have to read it > when I am not totally tired. I guess the moral of the story is, hey, > making games is complicated. Funny, that seems to be the moral of nearly every story Ive read/written/experienced lately ;-) ================================================================================ From: "Pallister, Kim" (kim.pallister^intel.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 09:26:11 -0700 Yep, that was another one. Frame 2 (the "repeat frame" can interrupt the eye (& brain) trying to interpolate between frames 1 and 3. K ================================================================================ From: "Mat Noguchi \(BUNGIE\)" (matthewn^microsoft.com) Subject: RE: Re: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 10:22:17 -0700 You think that's bad, try working on game tools. A whole new slew of performance, usability, and stability issues to deal with. MSN ================================================================================ From: Tom Hubina (tomh^vexxed.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 12:06:25 -0700 At 09:26 AM 8/13/2003, you wrote: >Yep, that was another one. Frame 2 (the "repeat frame" can interrupt the >eye (& brain) trying to interpolate between frames 1 and 3. I remember Steve Baker posting on the OpenGL list about a similar thing along this line (maybe he'll repost it) .. but basically, when drawing a 60hz display with 60fps, and a 60hz display at 30fps (frame doubling) the perception of time by the viewer / player is affected. It's been a LONG time since the thread, but I seem to recall the example used was a flight sim where in both cases there was 60 seconds of footage and the pilot was asked to estimate how long the footage took. With the 60 fps version, they would say 60 seconds. With the 30fps one they would say 45 seconds (or something along those lines). I don't think it has much bearing on games (compared to flight training where it can matter a lot), but it's still a weird data point .. heh. Tom ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 12:49:52 -0700 > On two consoles at least you can take advantage of the fact that the > screen is interlaced and render to fields of 640x256 at 50hz and > thus reducing the fill rate requirement to half yet loosing no resolution Except that at on at least one of those consoles, fill rate isn't really the bottleneck. Looks really nasty if you ever drop a frame too. The VRAM savings, though not inconsiderable, do come at a high price. IMHO you're better off working on better texture uploading. Cheers, Phil ================================================================================ From: "jason watkins" (jason_watkins^pobox.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Wed, 13 Aug 2003 23:46:38 -0700 > Anyway. Because monitors scan progressively from top to bottom, it's > possible to perceive visual changes at the horizontal refresh rate. I > suspect this is what those tuned-up Quake players are noticing. I doubt this is the issue with quake players. Of far more interest is control lag, as well as flawed physics. Much of competitive quake dueling relies on nearly acrobatic movement to out position your opponant and control resources on the map. While it should not be the case, there are in fact, maneuvers that are impossible below a certain fps. Most of these take the form of a ledge that it's possible to reliably jump onto (just barely) at high fps, but nearly impossible to jump onto below a certain fps. This is because at lower fps somehow the collission sampling "misses" the tiny tip of the players jump parabola. From the perspective of a game developer, this means we should try to fix the simulation. From the perspective of a game player who wants to win with the code as is, it means you go get hardware that meets the fps you need to get on that dang ledge to get the megahealth before the other guy. > The amazing thing is, this effect is *easily* perceptible! The > vsync'ed version looks demonstrably wrong! There's a UNC paper from > 1995 that explains it all: > > http://www.cs.unc.edu/~olano/papers/latency/ Very interesting paper. However, we do not have sysetms capable of generating the "correct" image. I, like many people, absolutely abhor having vsync off. For whatever reason, tears on sillowette edges drive me crazy. Bottom line for a game: support either mode, because people do have clear and strong preferences. I recall someone on a website a few years back speculating on just in time pixel delivery implimented on a tiled, deferred rendering architecture such as PowerVR supporting this kind of scan synchronization. Seems the world has moved on to other things, but interesting to think of what might have been. jason ================================================================================ From: (cphillips^reflectionsinteractive.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 10:35:12 +0100 With conventional vsync'd rendering, show a tall object moving across the screen. Then, show the same thing again, but shear the object so that the bottom of the object is warped in the direction of motion. Getting the right shear involves a little algebra (see the paper). The unsheared moving object clearly appears sheared when displayed on a CRT, while the sheared object appears vertical. Most obvious 'real life' example of this is those scrolling LED signs that look italic when the text is moving but regular when it's stationary. -Virus scanned and cleared ok ================================================================================ From: (Paul_Firth^scee.net) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 09:14:12 +0100 >> On two consoles at least you can take advantage of the fact that the >> screen is interlaced and render to fields of 640x256 at 50hz and >> thus reducing the fill rate requirement to half yet loosing no resolution >Except that at on at least one of those consoles, fill rate isn't really >the bottleneck. Looks really nasty if you ever drop a frame too. The VRAM >savings, though not inconsiderable, do come at a high price. IMHO you're >better off working on better texture uploading. Depends on what youre doing. If youre drawing lots of particles and have lots of full screen effects like dof / heat haze / fog etc fill rate can be a factor. I've even heard of people drawing all their particles type alpha effects to a true half height buffer (fsaa usually means having a 640x512 for the back buffer and squashing it down to 640x256 per field) to save even more on fill rate. That vram saving is not to be sniffed at either, means you can have bigger render targets, nicer textures etc. If you already run at a constant 50/60, its a no brainer. The only minor thing is to be sure that you set up a vblank interrupt or similar when loading etc to make sure you don't drop to one field - which does look ugly as hell. Obviously we're talking ps2 here, but I believe theres at least one (rather nice) xbox game which does this trick released atm. Cheers, Paul. ================================================================================ From: "Joris Mans" (joris.mans^pandora.be) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 11:37:45 +0200 > when I am not totally tired. I guess the moral of the > story is, hey, making games is complicated. And 95% of gamers outthere wont even notice all this stuff ;) Joris ================================================================================ From: Tom Forsyth (tomf^muckyfoot.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 15:57:40 +0100 The Dreamcast had an even more extreme version of this. Since it was a scene-capture tile-renderer, you could have a mode where it only had a framebuffer big enough for two tile heights - IIRC that was something like 32 pixels. So your framebuffer was just two 640x32 pixel chunks, and while displaying one the other was being rendered to, and they swapped when the raster beam switched from one chunk to the next down the screen. Obviously if you dropped a frame or, more scarily, if one of the tile rows took too long to render, you went out of sync and got junk on screen. Now _that's_ scary edge-of-the pants rendering. Strangely enough, I never dared turn this mode on to try it, but apparently some games did. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 09:08:35 -0700 > > I guess the moral of the story is, hey, making games is complicated. > And 95% of gamers outthere wont even notice all this stuff ;) ...but the other 5% will bitch like hell if you get it wrong. Cheers, Phil ================================================================================ From: "Neil Stewart" (neil^steelmonkeys.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 16:11:46 +0100 > Obviously we're talking ps2 here, but I believe theres at least > one (rather nice) xbox game which does this trick released atm. Which one is it, if you don't mind me asking? And when you say it does this trick, are you talking about rendering fields directly, or the half res particle buffer, or both? - Neil. ================================================================================ From: (phil_wilkins^playstation.sony.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 09:50:25 -0700 (Paul_Firth^scee.net) : > Depends on what youre doing. If youre drawing lots of particles and have > lots of full screen effects like dof / heat haze / fog etc fill rate can > be a factor. I've even heard of people drawing all their particles type > alpha effects to a true half height buffer (fsaa usually means having > a 640x512 for the back buffer and squashing it down to 640x256 per field) > to save even more on fill rate. Yeah, I've got particle systems that can destroy fill rate, and we're hyper-concious of the number of full screen passes we're already doing. My concern would be that if you're unconstrained enough to get large full screen particle systems munching fill-rate, how are you going to be absolutely certain you don't trip over a frame? > That vram saving is not to be sniffed at either, means you can have bigger > render targets, nicer textures etc. If you already run at a constant 50/60, > its a no brainer. The only minor thing is to be sure that you set up a > vblank interrupt or similar when loading etc to make sure you don't drop > to one field - which does look ugly as hell. Nicer textures is a red herring, we're dynamically uploading textures during the frame, and that's not been a problem so far. Textures tend to be temporally coherent within the draw list, which makes them a ideal streaming fodder. Also, overly large and detailed textures are usually a sign that you've just hired an artist from the special effects industry who doesn't realise his 512x512x32 bit monsterpiece is only ever going to occupy approximately 32x32 pixels on screen (I generally refer to this as "pushing the envelope", where the envelope ideally contains a P45 ;). Larger off-screen buffers would be nice though. It does disqualifies you from turning on 480p, although quite how much of a selling point that is at the moment, is debatable. This is one of those risk/reward judgement calls. If you really can promise you're never going to drop to 30, then it could be worth it. There's certainly a lot of options to play with, and I don't think I'd reccomend one method over another without a strong understanding of the underlying game. Ha, that's another one of those generic game development answers isn't it? Cheers, Phil ================================================================================ From: Thatcher Ulrich (tu^tulrich.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 13:53:19 -0400 On Aug 13, 2003 at 11:46 -0700, jason watkins wrote: > > > The amazing thing is, this effect is *easily* perceptible! The > > vsync'ed version looks demonstrably wrong! There's a UNC paper from > > 1995 that explains it all: > > > > http://www.cs.unc.edu/~olano/papers/latency/ > > Very interesting paper. However, we do not have sysetms capable of > generating the "correct" image. I, like many people, absolutely abhor having > vsync off. For whatever reason, tears on sillowette edges drive me crazy. Actually, it should be totally feasible to reduce/eliminate the leaning-edges effect if you're locked at 60fps. For each object, predict the speed of visual motion of the object, and incorporate a compensating shear into the transform used to render that object. Obviously won't work for some situations, like speeding through a single-object tunnel, and of course it's just window-dressing; it does nothing for latency. For crazy people only, of course... (Come to think of it, aside from shear on sideways motion, there should be a squash/stretch effect for objects moving vertically...) -- Thatcher Ulrich http://tulrich.com ================================================================================ From: Tom Forsyth (tomf^muckyfoot.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 19:10:46 +0100 Actually, it could be made to work for the tunnel case. As long as the whole object has a uniform velocity, it seems that you can apply a linear transform (i.e. a matrix) to move the vertices along the direction of motion as required (top of the screen = -ve, bottom of screen = +ve). You need to do this shear in perspective space rather than world space, so it'll need some homogenous maths, but I think it might still work. Crazy people of the world unite! Rotation breaks stuff of course. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. ================================================================================ From: Tom Forsyth (tomf^muckyfoot.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 12:06:16 +0100 > This is > because at lower fps somehow the collission sampling "misses" > the tiny tip > of the players jump parabola. This is one of the reasons that doing variable-speed physics/gameplay is eeeevil. You want fixed timestep gameplay, and just render with interpolation as fast as you can. That way everyone has the same game, whatever their rendering speed. Actually, I thought QuakeN were all fixed timestep games. Maybe I'm mis-remembering. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. ================================================================================ From: Jay Stelly (Jay^valvesoftware.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 11:49:54 -0700 Quake's frames are variable rate. Also, this isn't exactly an accurate description of the problem. The problem is that the player's motion is linearized per frame. That seems to be true for every game's physics system I've seen. Collisions are continuous along this line, not sampled. But the position the player moves is a set of line segments that approximate the correct curve, so at higher framerates it becomes a closer approximation. To the best of my memory Quake limits the longest frame that it will simulate at 50ms (otherwise it cuts the frame in half and does two steps - at least for player physics). So the error is between the curve approximated at 50ms and the curve approximated at 5ms (if 200fps helps, for example). So a fixed sim rate would make this consistent. There's also issues with the integrator (euler) used for gravity. So the path due to gravity isn't exactly the same at each framerate - but that could easily be fixed with trivial code (we did that in Half-Life, probably other Quake licensees did as well). Fixing that part was enough to get good design bounds for jumping so we could design jumps that could always or never be completed regardless of framerate. Jay ================================================================================ From: "Tim Johnson" (tim^helixcore.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 20:22:17 +0100 I believe QuakeN is usually fixed timestep on the server, and has some maximum timestep on the client. The jump parabola problem was a lot of discrete integer maths and rounding errors. I think the reason this didn't hold up online was server-side physics for players being run at the client timestep! Apparently to ensure consistency due to exactly such cases. Not sure whether the moral here is authoritative servers or fixed timesteps. I don't think there are many fixed-timestep PC, at least, PC FPS, games. Tim ================================================================================ From: "Rusch, Matthew" (MRusch^EA.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 11:52:36 -0700 They are very fixed. Very much a client-server architecture, even if you are playing single player. People will cheat up a storm otherwise(they do anyway). ================================================================================ From: "Michael Pohoreski" (MPohoreski^cyberlore.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 15:56:07 -0400 In Quake1, the client could lie about the timestep, and the server would accept it. Result: A ton of "warp-speed" cheats, shortly after the Q1 source was released. That pretty much killed Team Fortress & MegaTF. Is there a "Game Physics List of Don'ts" anywhere? (aside from discussing older games :) ================================================================================ From: "jason watkins" (jason_watkins^pobox.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Thu, 14 Aug 2003 18:11:37 -0700 > at least for player physics). So the error is between the curve > approximated at 50ms and the curve approximated at 5ms (if 200fps helps, for > example). Exactly. And while you'd think that such a case would be rare, in truth it becomes rather common, specificly because the jump height of a player is likely to be specified as an integer constant relative to a grid of some sort (like say, "128 units"). Because of the coarseness of the grid, it becomes very likely indeed that map makers will end up putting in geometry features that are exactly at the dimensions of the limit case. I think that's a very useful generalization: extrodinary coincidences abound in authored data, so your algorthms should expect such cases to be much more common than might be intuative. jason ================================================================================ From: "Alen Ladavac" So the path due to > gravity isn't exactly the same at each framerate - but that could easily be > fixed with trivial code (we did that in Half-Life, probably other Quake What exactly did you do here? Alen ================================================================================ From: (Paul_Firth^scee.net) Subject: RE: [Algorithms] 60hz is the holy grail Date: Fri, 15 Aug 2003 09:07:19 +0100 >Which one is it, if you don't mind me asking? Heh, I'm in danger of being totally wrong here (ie. I don't know for a fact) but I'm sure that Kung Foo Kaos uses this trick. >And when you say it does this trick, are you talking about rendering >fields directly, or the half res particle buffer, or both? I was refering to the field rendering. Cheers, Paul. ================================================================================ From: George Warner (geowar^apple.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Fri, 15 Aug 2003 08:27:35 -0700 On Thu, 14 Aug 2003 11:37:45 +0200, "Joris Mans" (joris.mans^pandora.be) wrote: >> when I am not totally tired. I guess the moral of the >> story is, hey, making games is complicated. > > And 95% of gamers outthere wont even notice all this stuff ;) Unless you get it wrong! ;-) -- Enjoy, George Warner, Schizophrenic Optimization Scientists Apple Developer Technical Support (DTS) ================================================================================ From: George Warner (geowar^apple.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Fri, 15 Aug 2003 08:43:27 -0700 On Thu, 14 Aug 2003 15:56:07 -0400, "Michael Pohoreski" (MPohoreski^cyberlore.com) wrote: > Is there a "Game Physics List of Don'ts" anywhere? (aside from > discussing older games :) In Bourg's "Physics for Game Developers", he discusses the evils (truncation errors) of Euler's method (integrating acceleration => velocity => position) vs. the (true) Taylor series. See chapter 11 under the topic "Integrating the Equations of Motion". -- Enjoy, George Warner, Schizophrenic Optimization Scientists Apple Developer Technical Support (DTS) ================================================================================ From: "Michael Kelley" (kelley^RockstarSanDiego.com) Subject: Re: [Algorithms] 60hz is the holy grail Date: Fri, 15 Aug 2003 18:10:35 -0700 This discussion reminds of an interesting technique that UNC has been doing some research on: http://www.cs.virginia.edu/~gfx/Courses/2002/BigData/papers/Maintaining%20Interactivity/Frameless%20Rendering.pdf It would probably only be practical if you weren't CPU bound. ================================================================================ From: Jay Stelly (Jay^valvesoftware.com) Subject: RE: [Algorithms] 60hz is the holy grail Date: Fri, 15 Aug 2003 23:28:49 -0700 We just used a taylor series expansion for position. This doesn't fix the linearized path problem, but it does make the jump parabola (that the simulation is essentially sampling the player's position from) consistent. instead of pure euler: v += a * dt; pos += v * dt; we use a 2nd order taylor series for pos: pos += v * dt + (0.5 * a * dt *dt) v += a * dt or: v += 0.5 * a * dt; pos += v * dt; v += 0.5 * a * dt; So in a simple case where the player jumps at time t0, integrating the player's position (with no other forces) to a time t0 + K will always yield the same value regardless of the number or interval of the frames in between (because a 2nd order taylor series for a 2nd order function is exact). So by fixing a minimum simulation interval you can guarantee a bounds on the error of the apex of the jump regardless of how irregular the framerate gets - and a higher framerate will always get more points exactly on the curve. With an euler formulation you get more error as the framerate gets lower. We still have to linearize the path travelled between each frame because our collision detection doesn't let us trace out curves. Jay ================================================================================ From: "Alen Ladavac" Thanks for the very detailed explanation. Let's see if I get it right: > > When using simple Euler integrator, the error caused by low > framerate accumulates creating a jump > apex that is much lower than just the linearization error. > Using a second order integrator you limit > the error to the pure linearization error, and you are able > to predict how much that is going to be, > depending on framerate. You are still able to miss the real > apex, but because its time sample is > between two frames, when you miss it due to linearisation. Yes, exactly. Also, since your frames are always on the curve you could still insert a discontinuity (i.e. split any sim frame that crosses) at the time of the apex, and you'd always hit it. But the error is pretty small already (especially compared to the euler) - and probability helps out here too (average error is lower than max error). Jay ================================================================================