Try the same with a simple window, in 85Hz and 150Hz. Even with no motion,
the extra refresh is clearly visible just by looking across a bright screen.
At 85Hz, I can clearly see refresh with simple, normal eye movement; at
150Hz, it’s much more subtle, coming closer to the solidity of an LCD.
It’s just as easy to distinguish a CRT at 150Hz from an LCD.
Anyhow, we’ve both probably had this debate before, so let’s drop it;
it’s off-topic anyway. People reading this can try the above and draw
their own conclusions for their own eyes and their own hardware.On Tue, Apr 08, 2003 at 02:28:08PM -0700, Andy Ross wrote:
No, you can’t. You probably won’t believe me that you can’t, (just
like audiophiles who swear they can hear the 16 bit quantization
errors in CD audio) but you can’t. You just can’t. Really. People
aren’t built that way. Even the phosphors in most CRTs have a decay
rate less than that.
Get someone to do a blind test on you, or write a script that selects
a mode at random. Play a game of Quake for 10 minutes in each and
rate them for “solidity” and “smoothness”. Repeat a few times.
You’ll be surprised.
No, you can’t. You probably won’t believe me that you can’t, (just
like audiophiles who swear they can hear the 16 bit quantization
errors in CD audio) but you can’t. You just can’t. Really. People
aren’t built that way. Even the phosphors in most CRTs have a decay
rate less than that.
Whether it is subjectively possible to see the difference between 85Hz and
150Hz is irrelevant to my concerns. There are times that I need a fast but
very exact multiple of a given frequency, as I plan to show the same
stimuli over multiple frames.
In one experiment, we need to lock a screen at either 120Hz or 150Hz – we
don’t really care which, as in one case we’ll show the same stimulus over
4 frames, and in the other we’ll show it over 5 frames. The important
thing is that we know exactly (to the nanosecond, if possible) when
stimuli go on the screen.
Maybe it’s true that normal humans playing games can’t tell the difference
between 85Hz and 150Hz – that’s not something my lab researches
However, we do have a clear and compelling use for high frequencies.
Yes. I’ve seen windows games select ridiculous modes like 1024x768
@ 150Hz. Beyond being an absurd choice (anything over about 80Hz
is undetectable to the human nervous system), it confuses monitors.
The image ends up squashed or stretched or very off-center.
Monitors have builtin mode calibrations for typical choices, but
they don’t understand 150 Hz, even if they can display it.
Nope. I can tell the difference between 85Hz and 150Hz (it’s much
more “solid”, and FPSs that can maintain that framerate are
smoother), and my monitor can do it just fine in lower resolutions.
I can’t differentiate the 150Hz 320’240 from 100Hz if there is no big
contrast difference in the picture and the picture is just a still
image. But if there is movement it can be seen instantly, because the
motion blur makes the difference. The higher max vertical refresrate
your monitor have the easier it is to see the difference, becasue the
decay of high vertrefresh monitors needs to be quite small. This has
some anoying side efect in smaller vertrefresh rates the monitor will
blink that’s why there really can’t be that big refresh scales.
There might be other reasons that the game runs much smoother in lower
refreshrate though. Like the fact that skipping one frame makes my head
dizzy in 150Hz refreshrates. that’s because human eye also takes in to
account the motion blur, and skipping frames makes the movement jumpy.
That’s quite funny that I haven’t seen really smooth scrolling since the
Amiga days… even the David’s smoothscroll demo doesn’t seem smooth
enough.
I’d be very irritated if software decided for me that I didn’t want
to take full advantage of my hardware because someone thought it was
"absurd" or “undetectable”.
If X is doing this, X is buggy.
No it’s not. It only filters those modes that it auto scans. You can set
your own modelines to the Xconfig and it wont touch those.On Tuesday 08 April 2003 23:57, Glenn Maynard wrote:
On Tue, Apr 08, 2003 at 11:43:22AM -0700, Andy Ross wrote:
Nope. I can tell the difference between 85Hz and 150Hz (it’s much
more “solid”, and FPSs that can maintain that framerate are
smoother)
Sigh. I knew when I wrote that that someone would call me out on it.
No, you can’t. You probably won’t believe me that you can’t, (just
like audiophiles who swear they can hear the 16 bit quantization
errors in CD audio) but you can’t. You just can’t. Really. People
aren’t built that way. Even the phosphors in most CRTs have a decay
rate less than that.
There is some missunderstandings about hearing too. Ordinary people have
the ‘normal’ hearing range from about 20Hz to 20000Hz allthough
musicians can have much wider range like my wife who can hear under
20Hz sounds 100% realiably in hearing test, where you need to say from
which side the sound comes. Same for the upper bound.
And if I play her brother 24 bit sampled DAT or 16 bit CD audio he can
give in blind test the difference and many musicians can tell the
difference from that DAT to real voice, because part of their hearing
comes from touch sense too.
Get someone to do a blind test on you, or write a script that selects
a mode at random. Play a game of Quake for 10 minutes in each and
rate them for “solidity” and “smoothness”. Repeat a few times.
You’ll be surprised.
From 3D game the refreshrate is not that easily dishtinguishable,
because the image change in totally different fashion than in 2D.On Wednesday 09 April 2003 00:28, Andy Ross wrote:
Josh Fishman wrote:> On Tue, 8 Apr 2003, Andy Ross wrote:
No, you can’t. You probably won’t believe me that you can’t, (just
like audiophiles who swear they can hear the 16 bit quantization
errors in CD audio) but you can’t. You just can’t. Really. People
aren’t built that way. Even the phosphors in most CRTs have a decay
rate less than that.
Whether it is subjectively possible to see the difference between 85Hz
and
150Hz is irrelevant to my concerns. There are times that I need a fast
but
very exact multiple of a given frequency, as I plan to show the same
stimuli over multiple frames.
In one experiment, we need to lock a screen at either 120Hz or 150Hz
– we
don’t really care which, as in one case we’ll show the same stimulus
over
4 frames, and in the other we’ll show it over 5 frames. The important
thing is that we know exactly (to the nanosecond, if possible) when
stimuli go on the screen.
Maybe it’s true that normal humans playing games can’t tell the
difference
between 85Hz and 150Hz – that’s not something my lab researches
However, we do have a clear and compelling use for high frequencies.
Yes, and you’re not alone. Our lab studies motion detection in flies,
which certainly can see even the flicker at “typical” refresh rates of
85Hz and above. Therefore, I use a refresh rate of 200Hz for my
experiments and that’s only because it’s the fastest I can get on a
conventional monitor. I’d love to go faster. (BTW, shameless plug:
the Vision Egg uses SDL/OpenGL to draw visual stimuli for experiments: www.visionegg.org )
To sum up, I think we all agree: It would be fantastic if SDL let you
specify your framerate (where possible). It would be terrible if SDL
restricted your choices. Without requesting a particular frame rate,
SDL should pick something sensible (“sensible” may be hard to define,
but this probably isn’t too important if the first two points are taken
into account.)
And of course all of this should work for multiple displays, too!
No, you can’t. You probably won’t believe me that you can’t, (just
like audiophiles who swear they can hear the 16 bit quantization
errors in CD audio) but you can’t. You just can’t. Really. People
aren’t built that way. Even the phosphors in most CRTs have a decay
rate less than that.
Whether it is subjectively possible to see the difference between
85Hz and
150Hz is irrelevant to my concerns. There are times that I need a
fast but
very exact multiple of a given frequency, as I plan to show the same
stimuli over multiple frames.
In one experiment, we need to lock a screen at either 120Hz or 150Hz
– we
don’t really care which, as in one case we’ll show the same stimulus
over
4 frames, and in the other we’ll show it over 5 frames. The important
thing is that we know exactly (to the nanosecond, if possible) when
stimuli go on the screen.
Maybe it’s true that normal humans playing games can’t tell the
difference
between 85Hz and 150Hz – that’s not something my lab researches
However, we do have a clear and compelling use for high frequencies.
Yes, and you’re not alone. Our lab studies motion detection in flies,
which certainly can see even the flicker at “typical” refresh rates of
85Hz and above. Therefore, I use a refresh rate of 200Hz for my
experiments and that’s only because it’s the fastest I can get on a
conventional monitor. I’d love to go faster. (BTW, shameless plug:
the Vision Egg uses SDL/OpenGL to draw visual stimuli for experiments: www.visionegg.org )
To sum up, I think we all agree: It would be fantastic if SDL let you
specify your framerate (where possible). It would be terrible if SDL
restricted your choices. Without requesting a particular frame rate,
SDL should pick something sensible (“sensible” may be hard to define,
but this probably isn’t too important if the first two points are taken
into account.)
And of course all of this should work for multiple displays, too!
I just wanted to re-iterate; the patch I’m working on will restore X 4.3
to X 4.2 functionality. That is, you will get the highest refresh rate
for each resolution. It can be disabled by an environment variable to
give you everything that X 4.3 gives you.
Any further subselection (ie, specific refresh rates) will have to be
added later. For now, I’m concentrating on restoring SDL functionality.
It will be almost trivial to add support for specific stuff LATER.
SteveOn April 8, 2003 11:48 pm, Andrew Straw wrote:
Does anyone know the difference between a scan-doubled vs. non
scan-doubled mode? Either one have an advantage over the other?
For example, if I have a resolution of 640x480 with 85Hz non-scan-doubled,
and 170Hz scan-doubled, which is preferable? Both will be displayed at
85 Hz by the monitor.
Well, if I try 640x480 non-scan-doubled in my 21"er, I get 480 think
horizontal stripes with lots of black between them. Doublescan
improves it a great deal, but you really need to get to some 1600
lines to completely get rid of the striping effect.
Most monitors these days will do fine with anything above 900 lines or
so, but 480 is really low, and will cause striping and loss of
light intensity.
As a sidenote, the original reason for the doublescan feature is the
old low resolution modes like 320x200 and 640x200. What you get is
really 320x400 and 640x400, which happens to result in the exact same
frequencies as the 640x400 mode. That way, you could have those low
resolutions without forcing non-multisync monitors to support them
explicitly - and you avoided striping and loss of intensity as an
extra bonus.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 09 April 2003 21.48, Stephen Anthony wrote:
Does anyone know the difference between a scan-doubled vs. non
scan-doubled mode? Either one have an advantage over the other?
For example, if I have a resolution of 640x480 with 85Hz
non-scan-doubled, and 170Hz scan-doubled, which is preferable?
Both will be displayed at 85 Hz by the monitor.
Most people don’t install their monitor drivers (not really drivers, just
info files), and therefore, Windows thinks that the monitor is capable of
a lot more than it probably is. A properly installed monitor will report
its max refresh rates, but such thing is very rare ( ‘plug&play’ monitor
driver works for most monitors, so its used as a general solution)
My cursor flickers badly or disappears when I use any color mode except 24
bpp. I would appreciate any advice on why or what I can do. Here is my sdl
related code and information:
If this matters: I am getting 95 fps at 16 bpp, 65 fps at 24 bpp, and 80 fps
at 32 bpp with this code. I would like to use 16 bpp, if I could fix the
cursor problem, and find a graphic editor that can edit 16 bpp bitmaps.
well, since no one else seems to be responding ill take a wild guess…
im guessing that you are arent using double buffering? You might try adding
in double buffering and see if that helps. Im guessing this is a double
buffering or VSync problem…you know in some games how when things get
readrawn it looks flickery? Well, this is caused by the video memory being
written to while the monitor is refreshing. If your drawing a box on the
screen but only get half way done before the monitor refreshes, it only
shows half the box for that frame, then the next time the screen refreshes
the whole box is there, but since there was that step in between it apears
flickery. Im thinking thats what is happening with your mouse cursor.
At 24bpp where you arent having the flickering issue, you also have the
lowest FPS, im thinking it flickers at all bpp but that since its a lower
FPS, it isnt noticeable since with lower FPS, the image remains on the
screen longer without being refreshed.
im not 100% sure this is the issue but im guessing it is…try double
buffering and if that doesnt help, look up info on VSync and if that doesnt
help…id say ask again w/ your new found knowledge :P> ----- Original Message -----
From: blaketnc@yahoo.com (Blake D)
To:
Sent: Wednesday, April 09, 2003 11:42 PM
Subject: [SDL] Disappearing cursor in 8, 16 and 32 bpp
Hello,
My cursor flickers badly or disappears when I use any color mode except
24
bpp. I would appreciate any advice on why or what I can do. Here is my sdl
related code and information:
If this matters: I am getting 95 fps at 16 bpp, 65 fps at 24 bpp, and 80
fps
at 32 bpp with this code. I would like to use 16 bpp, if I could fix the
cursor problem, and find a graphic editor that can edit 16 bpp bitmaps.
I think in 24 bpp it doesn’t flicker, because he most likely can’t get
HW surface and thus the view is already buffered. This also explanes
why it have lower frame rate.On Thursday 10 April 2003 21:08, Atrix Wolfe wrote:
At 24bpp where you arent having the flickering issue, you also have
the lowest FPS, im thinking it flickers at all bpp but that since its
a lower FPS, it isnt noticeable since with lower FPS, the image
remains on the screen longer without being refreshed.
24 bps is supported by HW however since it is not double word aligned, it is
slower to do writes and such which is why theres the lower FPS.
thats my understanding atleast.> ----- Original Message -----
From: sn.ml@bayminer.com (Sami Naatanen)
To:
Sent: Thursday, April 10, 2003 12:12 PM
Subject: Re: [SDL] Disappearing cursor in 8, 16 and 32 bpp
On Thursday 10 April 2003 21:08, Atrix Wolfe wrote:
At 24bpp where you arent having the flickering issue, you also have
the lowest FPS, im thinking it flickers at all bpp but that since its
a lower FPS, it isnt noticeable since with lower FPS, the image
remains on the screen longer without being refreshed.
I think in 24 bpp it doesn’t flicker, because he most likely can’t get
HW surface and thus the view is already buffered. This also explanes
why it have lower frame rate.
Careful: you can’t say “supported by hardware” without saying what hardware
you’re talking about. (My wristwatch doesn’t support 24bpp.)
Some hardware probably supports it, and you’re probably right that a lot
of hardware may support it but be slower due to alignment.
Some hardware doesn’t do 24bpp at all; just padded 32bpp.
In either case, you almost never want to ask for a 24bpp mode; the only case
I’d expect it to be useful is if hardware handles it, you really need full
color and you really can’t afford the extra memory for 32bpp.On Thu, Apr 10, 2003 at 12:38:29PM -0700, Atrix Wolfe wrote:
24 bps is supported by HW however since it is not double word aligned, it is
slower to do writes and such which is why theres the lower FPS.
24 bps is supported by HW however since it is not double word
aligned, it is slower to do writes and such which is why theres the
lower FPS.
thats my understanding atleast.
Some hardware probably supports it, and you’re probably right that a
lot of hardware may support it but be slower due to alignment.
Well most that support are old cards when memory was expensive and they
really work quite good in that mode.
Some hardware doesn’t do 24bpp at all; just padded 32bpp.
Like all modern GFX cards.
In either case, you almost never want to ask for a 24bpp mode; the
only case I’d expect it to be useful is if hardware handles it, you
really need full color and you really can’t afford the extra memory
for 32bpp.
And if you ask SDL to give you 24 bit surface SDL literally gives you 3
byte per pixel mode as Sam has stated earlier in this ML. This I think
should be changed to use 32 bit padded mode in the SDL2. I think Sam
had same kind of thoughts too back in that mail I refer.On Thursday 10 April 2003 23:36, Glenn Maynard wrote:
On Thu, Apr 10, 2003 at 12:38:29PM -0700, Atrix Wolfe wrote:
My cursor flickers badly or disappears when I use any color mode except 24
bpp. I would appreciate any advice on why or what I can do. Here is my sdl
related code and information:
You probably need to hide SDL’s cursor and draw the cursor yourself.
When you are writing directly to video memory, SDL can’t really manage
a cursor for you.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Thank you. That is what I ended up doing and it worked well.
Blake
You probably need to hide SDL’s cursor and draw the cursor yourself.
When you are writing directly to video memory, SDL can’t really manage
a cursor for you.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> ----- Original Message -----
From: sdl-admin@libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of Sam
Lantinga
Sent: Friday, April 11, 2003 9:01 AM
To: sdl at libsdl.org
Subject: Re: [SDL] Disappearing cursor in 8, 16 and 32 bpp
Hello,
My cursor flickers badly or disappears when I use any color mode except
24
bpp. I would appreciate any advice on why or what I can do. Here is my sdl
related code and information:
I wonder if there’s any way to get this in OpenGL/D3D modes in Windows.
Lots of games look just fine in 640x480, and extra framerate often does
a great deal more to make a game look better than extra resolution–except
for those black stripes, which makes 640x480 look horrible.On Thu, Apr 10, 2003 at 12:34:21AM +0200, David Olofson wrote:
Well, if I try 640x480 non-scan-doubled in my 21"er, I get 480 think
horizontal stripes with lots of black between them. Doublescan
improves it a great deal, but you really need to get to some 1600
lines to completely get rid of the striping effect.
Most monitors these days will do fine with anything above 900 lines or
so, but 480 is really low, and will cause striping and loss of
light intensity.
I can’t seem to get the following sdl defines to do their job for me,
although I defined them right before including sdl.h:
// Print all SDL errors to stderr.txt #define SDL_DEBUG
// Print number of SDL Surfaces not freed to stderr.txt #define CHECK_LEAKS
I intentionally generate errors and create unfreed surfaces, but still no
luck. I don’t know what other detail I can give. Thank you in advance for
any insights.
You have to define CHECK_LEAKS on SDL-<VERSION>/src/video/SDL_leaks.h and
then recompile the SDL library. Otherwise it won’t work.
Bye!
Eduardo.On Saturday 12 April 2003 21:22, Blake D wrote:
hello,
I can’t seem to get the following sdl defines to do their job for me,
although I defined them right before including sdl.h:
// Print all SDL errors to stderr.txt #define SDL_DEBUG
// Print number of SDL Surfaces not freed to stderr.txt #define CHECK_LEAKS
I intentionally generate errors and create unfreed surfaces, but still no
luck. I don’t know what other detail I can give. Thank you in advance for
any insights.
