My stuttering is gone :)
Jeff M
fps in Quake2 EQUAL to my refresh rate. I increased it by about 15fps and
the stutter went away. Weird thing is if I set the max fps back to where I
had it before I got my V3, which was 200fps, I get the stutter only if
triple buffering is enabled. I don't recall this happening with SLI.
Anyway, now I can leave triple buffering on, play at 1024x768x70Hz, set my
quake2 max fps to 85fps and online CTF is SUPER SMOOOOOTH. :)
Gary Tarolli
anything definitive yet that points to a bug. Below are some ideas that I
have. I welcome comments.
This stuttering seems like it might be the card changing from 60 fps to 30 fps
and back again, or whatever the numbers are for your refresh rate (e.g. at 85Hz
refresh it would be 85 and 43.5 fps). With Vsync ON, remember that the
swap must wait for a vertical retrace interval. If the game is running on the
hairy edge of the refresh rate, then it might be running at 60 HZ for a few
seconds and then 30 HZ. This will look strange. It may look like the game
is running fast and then slow and then fast again. One way to test if this is
the problem is to change the refresh rate and see if the problem goes away.
Or if you slow the game down to 30 Hz maximum. You can do this with
environment variables (e.g. set FX_GLIDE_SWAPINTERVAL=2).
Also note that at lower frame rates, 30 in this example, you will probably
see a double image - what people are calling RTS (retinal tracking syndrome).
Perhaps some people are calling this stuttering.
If you have triple buffering enabled another weird effect can happen. This
one is hard to explain. But I'll give it a shot. With double buffering if
the game is running a little slower than 60 HZ, it will either just run at 30
Hz
all the time (no visual problem), or it will run at 60 Hz some times and then
30 Hz at others, and these periods may last for a reasonable fraction of a
second or a few seconds.
But with triple buffering, something different happens. If the card is
rendering
at around 50 Hz, then it might swap every single vertical retrace for 4 frames
and then display the next frame twice (2 retrace intervals). This pattern
will repeat itself. Very strange. And it probably will look like stuttering.
Disable triple buffering to see if this is the problem. I am not sure if
FX_GLIDE_SWAPINTERVAL works with triple buffering, if it does,
you could also set this to 2 and see if this changes things.
Now with VSYNC off, you get tearing. I doubt people are reporting this
as stuttering.
Now why didn't this happen on Voodoo2? or SLI? Well, the performance
is different, the refresh rate is different, the other settings are different,
e.g.
triple buffering. Any or all of these could contribute to the card running at
slightly different frame rates, which could effect this problem.
Also, people are changing little settings in their system, like video BIOS
shadowing
or filtering settings, or refresh rates, or Quake maxfps, and noting that the
problem changes. To me this points to this: a slight change in frame rate
(which all
of these can cause) is making the stuttering appear or disappear. This backs
up my theory above.
Note that none of the things I mentioned above are "bugs", they are just
visual artifacts caused by uneven frame rates. This is why it is so important
to get a card that has excess performance - what you really want is a card that
can display well over 60 fps (or pick another number) and then set your refresh
rate to 60 Hz so the card never falls below that.
I'de be interested in hearing feedback from people. If you experience
stuttering,
try checking your settings, specifically refresh rate and triplebuffering, and
try changing them and see if that fixes the problem. Thanks.
L. Sin
>I am not sure if
>FX_GLIDE_SWAPINTERVAL works with triple buffering, if it does,
>you could also set this to 2 and see if this changes things.
This is a question I've had a for a while. I don't feel quite so ignorant
any more. :-)
Mark Crowley
Some information that I have come up with on the "stutter" issue
I have seen inconsistent framerates with several games: Need for Speed 3,
Quake2, and Unreal.
In the case of Need for Speed 3, the effect is more pronounced, as the
gameplay is more drastically affected by smaller framerate changes, so is
easier to spot. With Quake2, and Unreal, the framerate is most seriously
slowed when turning, but the effect appears to be more consistent, so was
observed by as a normal condition.
The effect is present on all three of my machines, each of which have
DIFFERENT 3D hardware. It is much more pronounced on the machines with the
faster hardware. I have observed this effect with the Voodoo2, Voodoo2 SLI,
and Voodoo3, along with the Riva TNT (especially with NFS3, as NFS3 gets a
big fillrate boost with the TNT).
I have managed to completely remove the effect on the Voodoo3 and single
Voodoo2 system by turning off vsync. This is especially effective on NFS3.
With the Voodoo3, there is very little visible tearing with all of the games
that I play. The voodoo2 is more pronounced. With the Voodoo2 SLI setup, I
get a NASTY "raking" effect on horizontal movement (I believe that it's
normal, as the SLI boards appear to use the Vsync signal to synchronize to
each other). The tearing effect with the TNT is too pronounced to suit my
tastes. I simply reduced the resolution so the stuttering effect is removed.
Personally, I believe that the "problem" is not caused by anything other
than vsync. As the boards slow down below the ability to complete the
displayable in time for the next displayed frame, the frame is held until
the following one, cutting the effective refresh rate in half. I have found
that the problem becomes small to nonexistant when I reduce the refresh rate
to 60 Hertz, but eyestrain becomes a problem. I have my Voodoo2 SLI setup
set to 72Hz for all resolutions, independant of the 2D refresh rates. This
works pretty well for me.
Unfortunately, the Voodoo3 does not afford me that luxury. I, for one, would
love to see a "Refresh Rate" override in the new drivers. This would
significantly aid in with this problem, IMO.
Mark Crowley
Mark Crowley
I thought we were talking about jumpyness with the video <grin>....
I have not experienced any sound related issues on the voodoo3, but I did
get a sound "stutter" with the Banshee that I had in the system, with Need
For Speed 3 and the Glide driver..... hmmmm..
I have the epox AT EX motherboard, bios v2.0, 128MB of RAM, Celeron 366
(@412.5 Mhz), Voodoo3 2000@166, Vortex1 Soundcard (Aureal), 100Mbit LAN
card. Does 78 fps, Quake2 DEMO1.DM2.
I have "Video Bios Shadowing" and "Video Ram Cacheable" turned off (no
noticeable difference either way), and AGP aperature at 16MB.
The AGP card is sharing it's IRQ with the USB bus. No devices connected to
USB.
Mark Crowley
Mark Rejhon
> But with triple buffering, something different happens. If the card
> is rendering at around 50 Hz, then it might swap every single vertical
> retrace for 4 frames and then display the next frame twice (2 retrace
> intervals). This pattern will repeat itself. Very strange. And it
> probably will look like stuttering. Disable triple buffering to see if
> this is the problem. I am not sure if FX_GLIDE_SWAPINTERVAL works
> with triple buffering, if it does, you could also set this to 2 and
> see if this changes things.
>
> Now with VSYNC off, you get tearing. I doubt people are reporting
> this as stuttering.
>
> Now why didn't this happen on Voodoo2? or SLI? Well, the performance
> is different, the refresh rate is different, the other settings are
> different, e.g. triple buffering. Any or all of these could
Good info in your post.
FYI, During my tests, I set both refresh rates the same (and verified
using my monitor's onscreen refresh rate/resolution display),
triple buffering enabled, tried several resolutions from 512x384
to 1024x768 for the Voodoo2 SLI and the Voodoo3. I didn't change
CMOS settings or Quake/Quake 2 settings. The Voodoo2's used to
be in this system before it moved. I never noticed the
characteristic stutter (that the V3 has) with triple buffering
enabled while I had the Voodoo2 in this system or the other.
Whenever triplebuffering is enabled on both, the Voodoo3 appears
to be less smooth than the Voodoo2 - especially pronounced in that
scene in Quake 1 that I illustrated, but can be very clearly and
easily reproduced in any scene where there are torches or
flickering lights. I found that the Voodoo2 locked at full 60fps
at 60Hz, while the Voodoo3 doesn't manage to do a smooth 60fps
(at 60Hz).
I will be experimenting some more, though. On the V2,
triplebuffering seems to makes things smoother. But on the V3, the
triplebuffering seems to makes things less smooth.
_______________________________________________________________________
____
Mark D. Rejhon WinNT.Linux.Win95 \ / mailto:ma...@ottawa.com
http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W
"A friend is someone who will be there without asking anything of you.
A friend is someone you know that knows you, and accepts you."
_______________________________________________________________________
Jon
news:371DE588...@3dfx.NOoooSPAaaaM.com...
All good points.
However, key problem with your ideas is that if you do a timerefresh in
Q2(say in the beginning spot just passed the broken pillar where all the
sparks are going off), the visuals are PERFECTLY smooth, on V2 or V3 w/
triple buffering or not.
It's when you are in-game and rotate or strafe in such areas that allows for
stuttering, BUT only with V3, not with V2!
It's as if there's some additional timing problem with V3, or it's more CPU
dependent....causing time-dependent stuff that's iterated in-game to stall
the V3.
-Jon
Mark Rejhon
> It's when you are in-game and rotate or strafe in such areas that
> allows for stuttering, BUT only with V3, not with V2!
>
> It's as if there's some additional timing problem with V3, or it's
> more CPU dependent....causing time-dependent stuff that's iterated
> in-game to stall the V3.
>
> -Jon
Exactly, same here...
Mark Rejhon
Jon
> Gary Tarolli <tar...@3dfx.NOoooSPAaaaM.com> wrote in message
> news:371DE588...@3dfx.NOoooSPAaaaM.com...
>
> All good points.
>
> However, key problem with your ideas is that if you do a timerefresh in
> Q2(say in the beginning spot just passed the broken pillar where all the
> sparks are going off), the visuals are PERFECTLY smooth, on V2 or V3 w/
> triple buffering or not.
>
for
> stuttering, BUT only with V3, not with V2!
I wasn't exactly clear...this is with triple buffering when in-game
w/vsynch. Double-buffer in-game is fine on V3!!
Gary Tarolli
to reproduce "stuttering" in Quake1 on both V2 and V3 systems. I am
convinced that the stuttering inside the "Easy Entrance" of Quake1 is just
uneven frame rates. We were able to duplicate the problem on both
machines and make it go away by simply changing refresh rates or
other performance parameters. The problem stems from the fact that
the rendering runs somewhere between 50 and 80 fps, so if the refresh
rate is 60 or 75, sometimes it will run at the refresh rate and sometimes
it will run at half the refresh rate. Triple buffering doesn't help a whole
lot. Setting the refresh rate to 85 makes it run at 42.5 fps all the time.
Or setting FX_GLIDE_SWAPINTERVAL=2 makes it run at 1/2 the
refresh rate all the time also, even at 60 Hz. SO..... I know what causes
you to see the stuttering.
Now the more interesting question is this: are there performance issues
with V3 that make it run slower than V2? I would be interested in where
people see these slowdowns - is it in areas of lots of triangles? or lots
of texture downloads? or animated textures? etc.?
>
Gary Tarolli
Gary Tarolli
Craig Luna
difference in Q2 by enabling host_speeds or having your boys (:>) compile a
special minigl to log each frames rendering time. I do think I've seen this
occur in Unreal timedemo with SLI and V3 now that you mention it.
Since timerefresh uses no mouse or keyboard input then I can understand it
not being a problem. However, since the stuttering is occuring with keyboard
input, a number of thinks could be occurring that resembles mouse
'stuttering'.The problem could be a keyboard buffer overflow or even the
same sync issue as the ps2 mouse has but because of keyboard int. rate
(approx or 24 char repeats per second for most configs) . The same way we
try to tune the rate of the ps2 port /mouse to the refresh, so too should we
do the same for keyboard input. Since I don't have any q2 keyboard input
code then this is only a guess but it is a possibility.
Other questions to ask: Is this happening with timedemo on or off? Does
this only happens with the AGP cards? Does the problem occur if the
keyboard is a USB vs DIN/PS2?
Craig Luna
Gary Tarolli <tar...@3dfx.NOoooSPAaaaM.com> wrote in message
news:371DE588...@3dfx.NOoooSPAaaaM.com...
>>>Mad Dog<<<
substituting console input for keyboard input :-)
--
>>>Mad Dog<<<
MD CFG: http://www.voodooextreme.com/3Fingers/maddog/
Craig Luna wrote in message <7flvbj$s4e$1...@news.3dfx.com>...
Craig Luna
do, +left ?
I guess the 3dnow opts must be preventing the framerate from dropping too
much to allow it to happen. Since I don't get the stutter, my K6-2 420 must
be doing its job (Well until the 7 550PIIIXeons with 21inch monitors we
just ordered come in. I guess my boss is finally making me use a 21 since
everyone else has one (two now ). I just haven't a clue how a 21inch
monitor, 2 17s , laptop and my developement digitizers will fit on my measly
desk)
Oh well Ill keep trying to make it happen. Try the host_speeds then and
ignore the rest of the garbage I wroth :>
Craig Luna
----- Original Message -----
> Keyboard input isn't a factor, we've already eliminated that one by
> substituting console input for keyboard input :-)
> >>>Mad Dog<<<
>
Gary Tarolli
refresh rate. If you know the approx rendering rate on a V2, then
set the refresh rate very close, you should be able to see stutter
as the rendering rate changes/varies from slightly faster to slightly
slower than the refresh rate (as the scene complexity changes).
With Vsync on this will cause a factor of 2 difference in the actual
frame rate. With Vsync off there will be hardly any difference.
With triple buffering on, you will get a weird effect as I described
before, where a number of frames will swap every Vsync but then
one will be displayed twice.
P.S. Timerefresh has very weird behavior, I wouldn't base any
conclusions on it.
Jon wrote:
> This isn't consistent with what Mark and I are seeing.
>
> In short, it only happens on V3 when triple buffering is forced. It's ok in
> every other case. This jerk-stutter doesn't happen with a V2. BUT,
> timerefresh is ok in either case, it's only IN-GAME rotation or strafing
> that makes it visible. So it's a time-dependent factor(i.e. timerefresh
> stops game-time) such as sparks with lots of little triangles or w/ flashing
> lights, or torches with rotating sparkles of polygons.
>
> --
> -Jon
Richard Hendricks
) ) )Reverend( ( (
like. That is, it's like, while in motion going forward/backwards and
side-to-side, it's fast, slow, fast, slow...on and on. Especially
noticeable (and irritating) when in enclosed small areas like hallways.
Another prime example of this is in Unreal's starting map, in the room
with water on the floor (where you like, erm, *glide* around instead of
walking/running properly...pun intended) and you have to jump and hit a
button overhead to get a protective suit. There's a small hallway with a
couple of boxes and a health pack in this room. Go back and forth to and
away from those boxes. Believe me, you'll notice the stutter.
On a more important note and possible solution to this, I'd just done a
little bit more experimentations regarding this devil.
I reverted to my old BIOS setting i.e. those that I thought were the
culprits for causing the stuttering :
1) Video BIOS ROM shadow "Enabled"
2) L2 ECC check "Enabled"
and started up both Unreal and Quake2. Well...to my amazement, the
stuttering was missing. This is just so god-damn weird. So, I did a cold
reboot...and the stuttering came back BIG. I'm shaking my head at this
point...I was about to throw up my hands. So I read up a bit on Gary
Tarolli's post. And did one last ditch effort.
In the V3 3dfxTweaks control panel:
1) *Checked* (i.e. enable) the "Force Triple Buffering" box
2) In GaryP's o/c control panel, *DID NOT* check the "Disable VSync" box
(i.e. enable VSync)
First of all, I set 1024x768@100Hz ,1280x960@85Hz and 1280x1024@85Hz
using HZTool so these would apply to all games.
In Unreal's Advanced Options, I changed the "DisableVSync" option to
"True" under the [GlideDrv.GlideRenderDevice] section of Unreal.ini in
\Unreal\System\. Started up the game...NO STUTTER!! Did more checking
about the RefreshRate in Unreal's Advance Options under the same render
section...didn't seem to matter what value I specify. This applies to
1024x768 and 1280x1024.
In Quake2, I :
i) set gl_triplebuffer 0
ii) set gl_ext_swapinterval 0
iii) set gl_swapinterval 0
loaded up the game...and NO STUTTER. This again applies to 1024x768 and
1280x960.
So, apparently the stutter comes down to *in-game*'s disabling
triple-buffering and/or disabling vsync. BE REMINDED that
triple-buffering *WAS ENABLED* in 3dfx's 3dfxTweak control panel for
both cases prior to launching both games, just that for Unreal, all I
did was DisableVSync in-game and in Q2's case, I disabled both Vsync
[via (ii) & (iii)] and triplebuffering [via (i)]. For Q2, both vsync and
triplebuffering must be disabled, not one or the other.
For Unreal, some slight tearing occurred. Again, this is with:
1) GaryP's o/c panel, enabled vsync ; but
2) Unreal's Advanced Option, disabled vsync.
For Quake2, absolutely no visible tearing. Image quality was *not*
compromised by disabling triplebuffering in-game (thru' its cvar).
So, for those that still experience stuttering even though they disabled
triplebuffering via 3dfxTweak's control panel, try the above two
solutions I found. And report here. And for those that got rid of *most*
of the stuttering by disabling triplebuffering thru' the same way but
still experienced *some* slight stuttering, again, try the above two
solutions and see if the stuttering completely disappears. Both, of
course, assumes that, in Quake2's case, you hadn't tried changing the
three cvars mentioned above.
Guys, and Gary Tarolli especially, explain, please.
--
)))Reverend(((
Shockwave|| http://www.voodooextreme.com/reverend/flash/Main.html
Regular || http://www.voodooextreme.com/reverend/Main.html
Jon
and do no more keyboard input and it rotates and you see the
jerk-stuttering.
timedemo is off, only happens with V3 w/ triple buffering enabled w/ vsynch
on.
--
-Jon
Craig Luna <cl...@noSpam.midsouth.rr.com> wrote in message
news:7flvbj$s4e$1...@news.3dfx.com...
Jon
In short, it only happens on V3 when triple buffering is forced. It's ok in
every other case. This jerk-stutter doesn't happen with a V2. BUT,
timerefresh is ok in either case, it's only IN-GAME rotation or strafing
that makes it visible. So it's a time-dependent factor(i.e. timerefresh
stops game-time) such as sparks with lots of little triangles or w/ flashing
lights, or torches with rotating sparkles of polygons.
--
-Jon
Gary Tarolli <tar...@3dfx.NOoooSPAaaaM.com> wrote in message
news:371E5399...@3dfx.NOoooSPAaaaM.com...
Jon
CPU problem. If you disable vsynch and do timerefresh it consistently
rotates and gives ~100fps on a mesely P2-333 V3-3k.
--
-Jon
Craig Luna <cl...@noSpam.midsouth.rr.com> wrote in message
news:7fm5lj$1gb$1...@news.3dfx.com...
Mark Rejhon
> Now the more interesting question is this: are there performance
> issues with V3 that make it run slower than V2? I would be interested
> in where people see these slowdowns - is it in areas of lots of
> triangles? or lots of texture downloads? or animated textures?
> etc.?
It occurs in parts where there are dynamic lightmaps, such as
torches or flickering lights in Quake 1 or Quake 2...
The Voodoo2 seems to do triplebuffering with scenes containing
dynamic (flickering) lightmaps better than the Voodoo3 does, from
my observations. But turn off triplebuffering, and the stutter
is gone on the V3.
In summary, triplebuffering benefitted the smoothness of the
game on V2, triplebuffering seems to be counterproductive in
these particular situations (ie, triplebuffering introduces
additional stutter that didn't exist on the V2) where there
are flickering lights.
Since flickering lightmaps involve texture downloads, it must be
during periods where there are lots of texture downloads!
There may be other situations, but this is what I have noticed.
Hope this helps!
Gary Tarolli
at bus speeds, ie. as fast as one could hope for. This was on AGP.
Since V2 doesn't run on AGP, V3 texture downloads are about twice
as fast. So it doesn't make sense that they would cause this. But I
will keep checking into it.
Perhaps triple buffering was not really enabled on V2? Can you
run V2 with and without triple buffering and verify that triple buffering
runs faster? If not, then it's probably not really enabled and V2 is
just running double-buffered and perhaps slower than V3 and thus at
a consistent frame rate (e.g. always at 30 Hz). Believe it or not,
always running at something like 30 Hz can look smoother than
running at 60 Hz for 1 second and then 30 Hz for the next
second.
Mark Crowley
On NFS3, forcing triplebuffering had NO effect, except in causing the screen
to blank periodically when the track loads.
The graphical stuttering effect that I saw was most apparent on NFS3, but
also was pretty obvious with Unreal (during the flyby sequence). The
interesting thing, tho, is that Unreal was running in GLIDE mode, and NFS3
was running D3D!!!
I will describe in as much detail what I saw so that I know that we are all
talking about the same thing:
After installing the Voodoo3, I tried all of the games. I ran a timedemo on
Quake2, and got 43FPS. Too low. I then went in the options, and turned on
triple buffering. Timedemo: 78fps!! Better. Ran unreal - Got rainbow
textures, and the demo would pause occasionally. I chalked that up to a
driver problem.
I ran 3Dsetup, and was forced to use Direct3D as the renderer (there was no
choice for the Voodoo3, and I have a purchased version, as I got a V3 2000,
without the pack-in NFS3). When I ran the game, I noticed something
strange - The game ran jerky! It was almost like the game would shift to a
FASTER framerate, and get "stuck" there for a split-second, then go back to
the normal slower framerate.
I then started fiddling with resolution, and settings in the control panel.
I also attached a fan to the heatsync on the 2000, and got the overclocking
control panel (V3OC1300), and bumped the speed all the way to 166MHz. The
board speed made the most difference, but in a curious way. @ 166, the game
ran in "Fast" mode more often than @ 143 Mhz, but was less consistent
(changed too often). the "sweet spot" of the card seemed to be around 155
Mhz. I figured that the Motherboard might be causing the problem, so I tried
the board on a totally different Brand/chipset Mobo. No difference.
I then noticed, in the Overclock control panel, the Enable/Disable Vsync
options for Glide, and for D3D, and I turned them off. The game then ran
TOTALLY SMOOTH!!!.
I have since tried this on all of the other games, and I am getting the same
results with them, as well.
I also found a way to switch the game into Glide mode, and have seen the
exact same effect. After disabling VSYNC, the board runs great at any speed,
and better (smoother) at 166 on all games.
I have also noticed the same effect, although much less pronounced, on my
Voodoo2 SLI rig, and on the TNT. I have not disabled Vsync on the Voodoo2s,
because of the "Raking" effect that I get. On the TNT, I cannot disable
Vsync, as I am running MS Certified drivers (and it is my Brother's
computer, and he needs it reliable).
I hope this explains what I saw.. My speculation is that the problem was
exactly as Gary described it, where the game causes the board to shift to
1/2 of the original framerate because of a missed frame...
BTW: Gary, I cannot easily change the refresh rates on the monitor, as the
only other selection than 75Hz, is 60Hz, for EVERYHTING (PnP monitor).
Mark Crowley
Jon
--
-Jon
Gary Tarolli <tar...@3dfx.NOoooSPAaaaM.com> wrote in message
news:371ECDE5...@3dfx.NOoooSPAaaaM.com...
> I personally benchmarked texture downloads on a V3 and they ran
> at bus speeds, ie. as fast as one could hope for. This was on AGP.
> Since V2 doesn't run on AGP, V3 texture downloads are about twice
> as fast. So it doesn't make sense that they would cause this. But I
> will keep checking into it.
>
> Perhaps triple buffering was not really enabled on V2? Can you
> run V2 with and without triple buffering and verify that triple buffering
> runs faster? If not, then it's probably not really enabled and V2 is
> just running double-buffered and perhaps slower than V3 and thus at
> a consistent frame rate (e.g. always at 30 Hz). Believe it or not,
> always running at something like 30 Hz can look smoother than
> running at 60 Hz for 1 second and then 30 Hz for the next
> second.
We understand such issues. But when we speak about V2 not having problems
with TB being on, we see the V2 as *perfectly* smooth in these cases. That
is, without vsynch you timerefresh and get 100+fps with a consistent
rotation. So that's not what's going on.
See my 3dfx: "short notes" post at the bottom for details on this.
Jon
> My theory is that you can get it to happen on a V2, just at a different
> refresh rate. If you know the approx rendering rate on a V2, then
> set the refresh rate very close, you should be able to see stutter
> as the rendering rate changes/varies from slightly faster to slightly
> slower than the refresh rate (as the scene complexity changes).
Problem with this theory is that the V3 is just fine without triple buffer,
it's *perfectly* smooth in rotations(i.e. locked at 60Hz w/vsynch on), just
like V2 in any case in these places we speak about.
We are running the refresh rates at 60Hz on both V2 and V3. Both show a
timerefresh that's comparable w/ vsynch off in Q2. So the V3 must have a
timing problem causing CPU loss with certain effects(torches w/ rotating and
small polys, sparks-small polys, etc.).
> With Vsync on this will cause a factor of 2 difference in the actual
> frame rate. With Vsync off there will be hardly any difference.
> With triple buffering on, you will get a weird effect as I described
> before, where a number of frames will swap every Vsync but then
> one will be displayed twice.
I understand how TB works, but again the framerate is clearly NOT going
below 60fps w/ vsynch on at 60Hz refresh on V2 OR V3, except on V3 w/ triple
buffering.
See my 3dfx: .."short" notes... post at the bottom for a detailed time/frame
example of what the "jerk-stutter" is like. It's not RTS alone(i.e. running
at 30fps w/ 60Hz w/ or wo/ triple buffer), like you describe.
> P.S. Timerefresh has very weird behavior, I wouldn't base any
> conclusions on it.
In Q2, it's simply stopping game-time(i.e. no new positions for polys as you
rotate), and rotating at a fixed frame/angle, then it takes how many
frames(fixed) divided by how long it took to rotate 360 degrees, giving an
FPS.
In Q1 the timerefresh is known to be broken with torches in the
vis_range(otherwise it's ok), so in that case I agree it's not useful for
figuring out what's going on here.
Nice thing is the behavior is the same for Q1 and Q2 with respect to V3
producing jerk-stutter w/ Triple buffering.
-Jon
Jon
news:7fnkbc$jgu$1...@news.3dfx.com...
> Jon,
>
> On NFS3, forcing triplebuffering had NO effect, except in causing the
screen
> to blank periodically when the track loads.
>
> The graphical stuttering effect that I saw was most apparent on NFS3, but
> also was pretty obvious with Unreal (during the flyby sequence). The
> interesting thing, tho, is that Unreal was running in GLIDE mode, and NFS3
> was running D3D!!!
What CPU do you have? It's possible you are just seeing RTS if you don't
see any change with triple buffering.
> I will describe in as much detail what I saw so that I know that we are
all
> talking about the same thing:
>
> After installing the Voodoo3, I tried all of the games. I ran a timedemo
on
> Quake2, and got 43FPS. Too low. I then went in the options, and turned on
> triple buffering. Timedemo: 78fps!! Better. Ran unreal - Got rainbow
> textures, and the demo would pause occasionally. I chalked that up to a
> driver problem.
What refresh rate are you set at? I suppose 85Hz, since 78fps would only be
consistent with 78Hz refresh or higher.
> I ran 3Dsetup, and was forced to use Direct3D as the renderer (there was
no
> choice for the Voodoo3, and I have a purchased version, as I got a V3
2000,
> without the pack-in NFS3). When I ran the game, I noticed something
> strange - The game ran jerky! It was almost like the game would shift to a
> FASTER framerate, and get "stuck" there for a split-second, then go back
to
> the normal slower framerate.
What you are describing isn't exactly like what Mark and I see in Q1/2.
There we see it's *fast* mostly and goes SUPERslow for about 1/20 second,
only fitting on frame into that amount of time, or worse.
> I then started fiddling with resolution, and settings in the control
panel.
> I also attached a fan to the heatsync on the 2000, and got the
overclocking
> control panel (V3OC1300), and bumped the speed all the way to 166MHz. The
> board speed made the most difference, but in a curious way. @ 166, the
game
> ran in "Fast" mode more often than @ 143 Mhz, but was less consistent
> (changed too often). the "sweet spot" of the card seemed to be around 155
> Mhz. I figured that the Motherboard might be causing the problem, so I
tried
> the board on a totally different Brand/chipset Mobo. No difference.
>
> I then noticed, in the Overclock control panel, the Enable/Disable Vsync
> options for Glide, and for D3D, and I turned them off. The game then ran
> TOTALLY SMOOTH!!!.
If you are seeing vsynch off -> smooth results, that's normal. You'll see
tearing, or RTS related issues, but that's normal.
Deal is if it's consistent, then that's normal, even if not perfectly
smooth. What game/situation/act are you talking about here?
> I have since tried this on all of the other games, and I am getting the
same
> results with them, as well.
Obviously not all the games can be perfectly smooth, so your notion of
perfect fluidity may not be accurate.
Try the test Mark mentioned w/ triple buffering enabled and see if you can
now tell the difference between that and turning triple buffering off.
Test:
Q1:
1) go through difficulty portal from beginning
2) enter square room with choice of episodes, place yourself at center
3) use keys to rotate.
Is it *perfectly* smooth or not? Compare TB and DB cases at 60Hz refresh.
Remember there are cvars for triple buffer in Q2, kill them in your autoexec
and config in Q1 dirs.
Q2:
1) go down to the lower part of the first "room" past left of broken pillar
where all the sparks are flying and a dead body is already on the ground.
2) position yourself at center and rotate with keys.
Turn TB off and on and compare, again at 60Hz refresh. Again make sure
cvars aren't activated for TB.
-Jon
Mark Crowley
on that machine, I am running a Celeron 366 Slot1 at 75Mhz bus speed (412.5
Mhz), 128MB Ram.
The effect that I described with NFS3 had nothing to do with
Triplebuffering, as the game doesn't use triplebuffering.
Also, Q2 deathmatching over the LAN was smoother on this system up to
1280x1024 than it was on a similar system with a single Voodoo2. I have the
people trained to let me know about any problems, as that is an indicator of
difficulty with the system. In the 4 several-hour deathmatches that I have
run since the Voodoo3 was installed, No one has reported anything wierd.
One thing - If the board is using AGP 2X for texture transfers, then the
board has to be a busmaster. That being the case, you might want to look at
the latency timer settings in your bios. I have seen sound cards not release
the bus properly, causing operational pauses. Check this parameter out.
Mark Crowley
Anthony Wesley
Jon wrote:
> --
> -Jon
>
> Gary Tarolli <tar...@3dfx.NOoooSPAaaaM.com> wrote in message
> See my 3dfx: "short notes" post at the bottom for details on this.
Jon & Gary,
Be careful with your assertions - as someone who has worked in the IT tech
support business for a while, I can tell you that correctly diagnosing these
sort of problems is _hard_. There could well be several types of "stutter"
which can happen depending on your exact hw/sw setup. It seems to me that Gary
may be correctly diagnosing one of these types - but there may be others,
including what Jon is seeing on his system.
I personally think it's terriffic to see 3dfx active on this group, and I'd
like to encourage Gary and the others to continue in this way. We must be
careful not to get too assertive or demanding when we are chasing one of these
annoying problems - again experience says that it is very hard to do this sort
of remote tech support.
We should also make sure that we are talking about the same thing when we talk
about "stutter". There may be more than one kind. Short of recording some sort
of movie, I don't know how we can really show the 3dfx people _exactly_ what it
looks like. Suggestions?
I have a non-stutter related problem of my own which I have been beating on
after purchasing a v3 a few days ago - I no longer have access to 640x480 or
800x600 modes on my monitor (at any depth or refresh). If this sounds a bit
strange, then part of the explanation is that I have a 20" Sun workstation
monitor which can't operate below about 60kHz hsync. I am used to not seeing
the bios boot screen or text modes, but I had all the other modes working on my
creative labs banshee before I upgraded. I was able to do 640x480 @120Hz
vertical and 800x600@ 100Hz vertical and they worked just fine. (I can also do
1024x768,1152x864,1280x1024 etc and they still work ok on the V3).
I had sort of assumed that the banshee would be electrically the same as the v3
(same output drive characteristics), but apparently there is something not
quite the same which is causing me pain. I'd appreciate it Gary if you could
pass this note onto someone who can help me. I'll attach a CRO and have a look
at the sync pulses if it will help, but I guess you guys can do that just as
easily as me.
Cheers, Anthony
Hardware Systems engineer, Acquerra pty ltd
Canberra, Australia
awe...@acquerra.com.au