Classic link.
30 Frames per Second vs. 60 Frames per Second
http://www.daniele.ch/school/30vs60/30vs60_1.html
Maybe this article will explain why faster is always better PrinceC…
I think your religion is too strong though… 
Look, this is pointless. This has turned into a tearing vs. no tearing discussion. That’s really the bottom line here. We don’t all seem to be working off of the same definitions of “smoothness” or “quality”. These seem to be subjective terms in this thread.
Different rendering philosophies are going to persist because ultimately, even if we all understand the subject at hand perfectly well, some of us are willing to put up with visual tearing, and some of us aren’t.
BTW, when was this article written? 3dfx went out of business years ago! This article is so poorly written, and even less well supported by technical information, that the reader is forced to take the author’s word for it. The issues brought up in it (due to its lack of solid technical and logical backing) are absolutely debatable. It’s no more valid or invalid than the opinions raised in this thread by anyone.
Some of you will be glad to hear that this is definitely my last post on this thread. Nothing’s being accomplished.
Make better games, damnit! However the hell you decide do it!
[quote]Classic link.
30 Frames per Second vs. 60 Frames per Second
http://www.daniele.ch/school/30vs60/30vs60_1.html
Maybe this article will explain why faster is always better PrinceC…
I think your religion is too strong though…
[/quote]
Nothing new… well some of the explainations are a bit vague.
Motion blur is a sideeffect generated by the way we receive data - it’s asynchronous. We don’t see complete frames… instead it’s like updating random “pixels” at 7-15hz. It’s like having a back buffer and the new image-information is sprayed over it - therefore fast moving objects appear to be blurred (because not all “pixels” have been updated).
Another “funny” thing is that a quite huge part of the image we currently see is based on old data
If something moves within our ~170° fov we look at it (we are drilled to do so - it could be something dangerous)… so we look at it and our back buffer gets updated information about that area… we look back… and as long as there isn’t any motion our brain just asumes that everything in that area hasn’t changed. For that reason we hardly notice when our eyesight degenerates and it’s also the reason for the “tunnel view” effect (smaller fov) if you move at high speeds.
The article is definitely soft but it helps explain the complexities that arise with different display mediums.
The illusion (or real effect?) of motion blur is creatable by “static” computer graphics scenes if the update is fast enough.
We have done tests with 120 hz updates and motion blur begins to be percieved even though we know the individual frames are clear and sharp just like objects in reality.
However, actual technical studies would be much better if anyone knows off any, I think I am of to Google
[quote]Dear All,
In fullscreen mode, show() is tied to the vsync rate,
which can slow games down.
- Andrew
[/quote]
Are you serious ? Do you understand the meaning of your sentence ?
Your Monitor has a refresh rate ( for e.g. 60 Hz ), Hz means s ** -1, means every 1/60 second the beam of the CRT has finished drawing one screen.
In one second it will draw 60 screens, its your MONITOR which is slowing down your app.
“Do not ask what the app can do for you, ask what u can do for the app.”
Its like lightspeed, u cant go faster than light ( but it would be funny to follow the beam of a flashlight )