Doom3world

Care to explain the effects of that CVar here?...

http://wiki.doom3reference.com/w/index. ... ction=edit

on my ATI I don't see a difference when it's 1 or 0 at all.

the description says "runs one game tick every async game update"

that id's way of saying it keeps things synced up? That doesn't mean it's not a hardware problem... if it works fine with ATI then Nvidia has something wierd on their card (maybe). Maybe it's a memory/buss speed thing.

There are two threads running in Doom 3, the main thread, and the 'async' thread. The main thread runs the game code, networking, physics, renderer, etc... The async thread takes care of sound if com_asyncSound is 1 or 3 (windows & linux), it also takes care of input if com_asyncInput is 1 (it defaults to 0).

The async thread wakes up every 16 milliseconds (60fsp) to run an update. If more than 16ms have ellapsed since the last update, it will run multiple updates to catch up (for example if 51ms have elapsed, it will run 3 updates). Similarly, if the update is called too soon, it gets ignored. When com_preciseTic is set to 0, it skips this bit of logic and always runs a single update no matter what.

I'm not sure why this would cause a frame skip, as sound mixing is pretty speedy, even if you're doing 5.1. The only reason we run it in a seperate thread is it's time sensitive (missing the mix window will cause artifacts in the sound output).

wow that is weird, so does this command do anything to the games performance in synching or is it not important cause it seems to work for me telling it 0, but im just wandering

this realy is something to look at though, maybe it is hardware

Interesting. Setting the com_preciseTic cvar to 0 really seems to get rid of the problem...

Actually, there is still a frame drop, but instead of happening with every step, it happens maybe once every seven seconds, and, while still noticable, is much less distracting than the constant juttering I was seeing before.

Apparently setting com_preciseTic to 0 screws with game physics, but I have yet to play the game long enough to see what kind of effect it has other than solving (for the most part) our problem.

Exactly what i see with this cvar set to "0"....but on an Radeon 9600!
Yes, my Radeon 9600 at my workplace shows exactly the same stuttering we are talking about all time!

So the "Nvidia only" myth just evaporated...sorry guys, its also ATI!

I don't see the problem why Doom 3 can't run fluidly with 60fps @ 60Hz?
John, are you there? John Carmack to the rescue please!

a faster machine would be nice, but we all dont have that kind of money, now it would be a nice dream to have the fasted INTEL GAMING RIGS we can allways dream

But it's not all about a faster machine! My roommate owns an ATI All-In-Wonder 128MB video card and Doom 3 runs just fine without all the jerks we're seeing elsewhere. And his machine is just an AMD 2200 I believe.

I have an ATI AIW 9600 & don't have any stutering. Sure it's not something else?



hopefully not. you'd have to do what china did & basicly start the machine from scratch to say that (fresh OS & no hardware on up). I doubt your boss would let you do that. Worth a shot though.

I haven't got the most up to date rig, but I ran D3 on a P3-667 with a Radeon 8500 with 128mb DDR & it didn't do this stuttering. It also didn't do it when I had an AMD XP 1800 (with 9600) & doesn't do it on my current AMD 64 3000 (with 9600).

It seems to happen with everyone who has nvidia, at least who'd piped up here.

Yeah, but Burrito says his Radeon 9800 shows the same problem, so my theory about this being a strictly NVidia problem is right out.

Also, reformatting a machine won't fix this problem, so don't even try it. It's not worth it. I wish I had saved myself the trouble of trying that one long ago...

Have you ever seen this problem on any machine yet so you know how it looks if it happens?

I don't know anyone around me who has D3 & a geforce card, so no. But, I've spotted errors in images on my monitor before so if there is one I'm certain i'd find it.

I switched that com_precisetic between 0 & 1 and had no difference while playing for a few minutes.

since it's happening on all types of cards now it's quite possible that it's not a PC related thing at all, but could be caused by power lines, telephone lines, broadcast towers...

does everyone here live in an urban/dense village area or in an apartment?

This problem is not solely a problem on GeForce powered systems as we know now.
Its also not about some errors in images - the individual rendered frames show now anomalies. Its the timing of the frames that is off somehow fubar and causes these motion artifacts.


You don't need to play for a few minutes to see this problem.
Just look straight down or face a wall and strafe to left and right with constant speed to see the judder effect.


I don't believe in esoterics, sorry.
This problem happens on otherwise perfectly smooth running computers so i'd rule that one out.

that? That's what everyone is upset about? That's not a glitch! That's skipping frames so that the game is synced up. com_precisetic doesn't fix it because there's nothing to be percise to!

change com_fixedtic from 0 to 1. 0 lets it update when it can, but if your system can't keep up it doesn't update (use com_showtics 1 to view the tics). If you use com_showtics you'll see that it skips frames occationatly.
1 FORCES it to be completly synced. This stops the "juddering" BUT it will slow the system down to a crawl when it can't keep up. Why? because EVERY frame MUST be shown. no excuses. So, you don't always get 60fps, you can get a constant 20 & everything will move in slo-motion. With this set to 0 you can get 60 because it's skipping frames.

should of used that "stair straight at a wall & wlak left/right look up/down" description in post 1. That would of ended this thread on page 2 at latest.

most people most likely don't notice it because (like I did after I first noticed that soon after I got thegame) they focus on the monitor's screen & not the background in the game.

i was actuatly thinking of the frquency used in electical current. The USA & Japan use 60hz & in europe I belive you use 50hz. that causes noise in audio stuff, thought maybe the same thing could be happening here.

Despite your confidence that this behaviour is normal i still can see no reason why it shouldn't be perfectly smooth to the human eye when running on a fast machine @ 640x480 + vsync, facing a wall.

It makes no sense to have motion judder under these conditions.

What could cause this?
A) A bug in id Software code
B) A windows bug
C) A driver bug
D) A design decision by John Carmack that nobody explained to us yet.

it's not a bug & your display isn't perfectly smooth. that's the problem. there's so much going on it must skip an occational frame.

this has been explained (well, not this specificly this, but why they did certain things). It's a compatability/performance trade off. this could be on all the time & everyone would be playing in matrix-land for 1/2 the game. not one frame would be skipped, no judders, but it wouldn't be much fun.

the tradeoff was to deal with the fact that no matter how fast a computer is, there is always a slight delay, and this results in the occational frame skip, or judder. each frame is drawn in 0.016 seconds. doesn't matter the max FPS you can achieve, unless you can get the frame to the monitor in 0.016 seconds it will have to skip. if it takes 0.01601 seconds to draw a frame, every 50th frame would be skipped because that would add up to 0.00050 seconds off. that would round the drawing routing up to 0.017, & in turn skip that frame. Turn off v-sinc will ignore this but then the frame will be drawn whenever it happens to show up. andyou can still skip frames.

it happens in Quake 3 & UT2k4 too (but much MUCH less in Q3A) so if it's a driver problem, it's most likely a MS DirectX problem & not an ATI/Nvidia problem (hard to belive they both would make the same error).

but when you have v-sync off in DX (which is normally not accessable) you can't see it. That could be the reason it's not normally an option, but it is there in UT2K4.

a possible solution would be to limit all FPS to 30. that would sitll be on the refresh rate of 60hz but wouldn't need to skip because all would be doubled.

the same thing happens in TV & movies on TV too. NTSC TV uses 29.97 fps because 30 fps was impossible to achive when color TV was invented. The audio would always be off. 29.97 worked perfectly. Movies on a TV double a frame every certain # of frames to convert from 24 to 29.97.

chinagreenelvis, it's DoomUK from http://www.tech-forums.net. You posted about this problem about a month or so ago, and after my recommendation to doom3world, here you are! I never even noticed the thread before lol...

Anyway, I haven't read through the thread properly yet, but from what I gather there is no real answer to the 'frame skipping' yet. It happens to me in various games; Q3A, BF2, NFSU2....

Specs:-

AMD 64 3500+
Asus A8N-SLI Deluxe
2GB Kingston DDR400
Gigabyte 7800 GTX (w/ Forceware 77.76 BETA)
AG Neovo 19" TFT LCD (@1280*1024 60Hz)

Sooo, it could just be a bizarre DX bug then? Has anyone here run Doom 3 (or anything else) in Linux? Maybe the answer lies there...

the answer in Doom 3 is using "com_fixedtic 1". For other games it's most likely not fixable because it' not an error, but the engine working around hardware limitations.

a fix for most people is don't focus on the moving objects in the game, but your monitor itself. works for me (remember, the monitor isn't a window, it's a flat 2d surface, so there's no need to focus on a spefic part in a game: it's all at the same depth).

That was from page one, first post. And on pages two and three there are several more people basically saying "Anyone who wants to see this problem for yourself, look at a wall and strafe." The Happy Friar is just late on the gravy train.

Anyway, he's totally right about the slowdown in game. It's kind of funny to play it like that, though, it's totally like Matrix Mode. Too bad that's the onlyl way to keep it from skipping frames. The most effective solution remains to be setting com_preciseTic to 0.