In the base SDK there are only a few areas where realtime is used. None of them should really be important, but I changed the non-perf related ones to curtime for consistency in:
c_baseanimating.cpp hl2_player.cpp I left the perf ones as realtime in: perfvisualbenchmark.cpp vgui_fpspanel.cpp The main thing would be to not realtime for anything important. Ideally the SDK header would document it as such... At 2006/05/14 04:07 AM, Garry Newman wrote: >-- >[ Picked text/plain from multipart/alternative ] >I always use curtime.. I've only really ever seen Valve use curtime and to >be honest I didn't know realtime existed. > >I've never had any problems with curtime. > > >On 5/14/06, Adam amckern Mckern <[EMAIL PROTECTED]> wrote: >> >> Well i ask becuase BK warns not to use realtime all >> but with perf testing, and then doubts himself with >> that. >> >> I am not on a MP mod team at this time, but am working >> on my own SP mod, based on the Nightfall game play >> engine that wrayith, and myself programmed. >> >> Adam >> >> --- Nick <[EMAIL PROTECTED]> wrote: >> >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > try it, see how well it works for you... LOL >> > >> > On 5/14/06, Adam amckern Mckern <[EMAIL PROTECTED]> >> > wrote: >> > > >> > > So BK, >> > > >> > > It would be best for all of us working on MP based >> > > mod's to find and replace every instance of >> > realtime >> > > with curtime? >> > > >> > > Adam >> > > >> > > >> > > >> > > --- [EMAIL PROTECTED] wrote: >> > > >> > > > FYI all, since dumping ->realtime in favor of >> > > > ->curtime I have not seen the serious form of >> > this >> > > > repro. The bug was intermittent, so it could be >> > > > luck, but it's been about 2 weeks, so it's >> > looking >> > > > like that was the only bug. >> > > > >> > > > Just a heads-up to anyone thinking of using >> > realtime >> > > > for anything other than maybe perf testing, >> > don't. >> > > > (And even that use is questionable.) >> > > > >> > > > -bk >> > > > >> > > > At 2006/04/18 06:42 PM, >> > > > [EMAIL PROTECTED] wrote: >> > > > >No, I do not need real time accuracy. I just >> > need >> > > > to know how the game thinks time is advancing >> > each >> > > > tick. To give an example, I'm using >> > > > gpGlobals->realtime to set a stamp and change >> > the >> > > > weird feature where you can switch weapons over >> > and >> > > > over almost limitlessly fast in HL2 DM. >> > > > > >> > > > >I left it running overnight with curtime and >> > didn't >> > > > get any odd curtimes (well, except for the level >> > > > changes, but that's ok.) Thanks again - this >> > seems >> > > > resolve the second biggest SDK issue I know of, >> > > > which has been a source of user complaints for a >> > > > quite a while. >> > > > > >> > > > >-bk >> > > > > >> > > > >At 2006/04/17 11:36 PM, Yahn Bernier wrote: >> > > > >>Yes. Curtime is the server's clock, which is >> > > > bounded by the tick >> > > > >>interval and smoothly increases in each call >> > to >> > > > GameFrame. If the >> > > > >>actuall time for a frame takes longer than one >> > > > tick interval, then you >> > > > >>can have multiple calls to GameFrame (with >> > > > advancing curtime) but only >> > > > >>get a single update to gpGlobals->realtime. >> > If >> > > > you need sub-frame clock >> > > > >>accuracy (only useful for perf. Analysis >> > really), >> > > > then use >> > > > >>Plat_FloatTime() which is independent of >> > > > gpGlobals->realtime and >> > > > >>->curtime. Otherwise, if you need a clock, >> > > > ->curtime is good enough, >> > > > >>but does reset between levels. >> > > > gpGlobals->realtime does not, but, >> > > > >>again, it only gets advanced at the start of a >> > > > frame (as opposed to each >> > > > >>tick). >> > > > >> >> > > > >>Yahn >> > > > >> >> > > > >>-----Original Message----- >> > > > >>From: [EMAIL PROTECTED] >> > > > >>[mailto:[EMAIL PROTECTED] >> > On >> > > > Behalf Of >> > > > >>[EMAIL PROTECTED] >> > > > >>Sent: Monday, April 17, 2006 8:16 PM >> > > > >>To: [email protected] >> > > > >>Subject: RE: [hlcoders] gpGlobals->realtime >> > > > standing still >> > > > >> >> > > > >>Thanks much. When you say curtime "will >> > reflect >> > > > the 0.015 increments >> > > > >>per tick", it sounds like you're saying that >> > > > realtime is broken in this >> > > > >>regard and I should use curtime instead? >> > That's >> > > > ok, but please confirm, >> > > > >>as I will need to do a lot of search and >> > replace. >> > > > >> >> > > > >>I've run a few tests and curtime always seems >> > > > consistent and monotonic, >> > > > >>however it seems that curtime doesn't start >> > moving >> > > > until the map loads, >> > > > >>and is reset on map load. Is that the >> > expected >> > > > behavior? >> > > > >> >> > > > >>-bk >> > > > >> >> > > > >>At 2006/04/13 12:33 PM, Yahn Bernier wrote: >> > > > >>>gpGlobals->curtime will reflect the 0.015 >> > > > increments per tick. >> > > > >>>Plat_FloatTime() will resample the high perf >> > > > clock. >> > > > >>> >> > > > >>>Yahn >> > > > >>> >> > > > >>>-----Original Message----- >> > > > >>>From: [EMAIL PROTECTED] >> > > > >> > >>>[mailto:[EMAIL PROTECTED] On >> > > > Behalf Of Jay Stelly >> > > > >>>Sent: Thursday, April 13, 2006 10:21 AM >> > > > >>>To: [email protected] >> > > > >>>Subject: RE: [hlcoders] gpGlobals->realtime >> > > > standing still >> > > > >>> >> > > > >>>Yahn found this one - realtime is only >> > integrated >> > > > once per sever frame. >> > > > >>>Game frame is called once per server tick. >> > When >> > > > you run something that >> > > > >>>uses 100% CPU the server gets starved, then >> > tries >> > > > to make up the time >> > > > >>>all in one frame. It's a little more complex >> > > > than that because there's >> > > > >>>a cap on the sim time it will try to execute >> > in >> > > > one frame, but ignoring >> > > > >>>that: >> > > > >>> >> > > > >>>The first GameFrame() has the complete update >> > to >> > > > realtime, then the >> > > > >>>subsequent calls don't change because you're >> > > > still running ticks to >> > > > >>>catch up. >> > > > >>> >> > > > >>>So in this example: >> > > > >>>> >odd realtime 11168195898843186 105.437195 >> > > > 105.486000 0.015000 >> > > > >>>> >odd realtime 11168195901330214 105.486000 >> > > > 105.486000 0.015000 >> > > > >>>> >odd realtime 11168195904200006 105.486000 >> > > > 105.486000 0.015000 >> > > > >>> >> > > > >>>Frame 2 has a 49ms jump in realtime, and >> > frame 3 >> > > > has the realtime the >> > > > >>>same because each tick is 15 ms, so you need >> > to >> > > > run multiple ticks to >> > > > >>>catch up. >> > > > >>> >> > > > >>>We can change it to make it more incremental, >> > but >> > > > you're not actually >> > > > >>>losing any time (at least I can't see any in >> > this >> > > > data). >> > > > >>> >> > > > >>>Jay >> > > > >>> >> > > > >>> >> > > > >>>> -----Original Message----- >> > > > >>>> From: [EMAIL PROTECTED] >> > > > >>>> >> > [mailto:[EMAIL PROTECTED] >> > > > On Behalf Of >> > > > >>>> [EMAIL PROTECTED] >> > > > >>>> Sent: Wednesday, April 12, 2006 9:06 PM >> > > > >>>> To: [email protected] >> > > > >>>> Subject: RE: [hlcoders] gpGlobals->realtime >> > > > standing still >> > > > >>>> >> > > > >>>> Oh yea forgot to say it's an intel p4 >> > single >> > > > proc with HT enabled. >> > > > >>>> >> > > > >>>> Here's one that repeated 6 times lasting 5 >> > > > ms... >> > > > >>>> >> > > > >>>> odd realtime 11172032919604142 1479.026855 >> > > > 1479.368408 0.015000 >> > > > >>>> odd realtime 11172032923627014 1479.368408 >> > > > 1479.368408 0.015000 >> > > > >>>> odd realtime 11172032926027614 1479.368408 >> > > > 1479.368408 0.015000 >> > > > >>>> odd realtime 11172032930865690 1479.368408 >> > > > 1479.368408 0.015000 >> > > > >>>> odd realtime 11172032932857506 1479.368408 >> > > > 1479.368408 0.015000 >> > > > >>>> odd realtime 11172032936032430 1479.368408 >> > > > 1479.368408 0.015000 >> > > > >>>> odd realtime 11172032937616626 1479.368408 >> > > > 1479.368408 0.015000 >> > > > >>>> >> > > > >>>> At 2006/04/12 10:45 PM, >> > > > [EMAIL PROTECTED] wrote: >> > > > >>>> >Using the 100% cpu method that always >> > breaks >> > > > rather easily, >> > > > >>>> I get results as follows, from the code >> > below. >> > > > It usually >> > > > >>>> occurs in groups of 2 or 3. The long-term >> > > > slowdown may take >> > > > >>>> several days to repro again. In this case >> > you >> > > > see realtime >> > > > >>>> being frozen for 2 milliseconds, calling >> > > > GameFrame 3 times >> > > > >>>> with the same value: >> > > > >>>> > >> > > > >>>> >odd realtime 11168195898843186 105.437195 >> > > > 105.486000 0.015000 >> > > > >>>> >odd realtime 11168195901330214 105.486000 >> > > > 105.486000 0.015000 >> > > > >>>> >odd realtime 11168195904200006 105.486000 >> > > > 105.486000 0.015000 >> > > > >>>> > >> > > > >>>> >----- >> > > > >>>> > >> > > > >>>> >void CServerGameDLL::GameFrame( bool >> > > > simulating ) >> > > > >>>> >{ >> > > > >>>> >#if defined(DEBUG) >> > > > >>>> > static float last_realtime = 0; >> > > > >>>> > if ( >> > > > >>>> > (gpGlobals->realtime - >> > > > last_realtime < >> > > > >>>> gpGlobals->frametime / 3) >> > > > >>>> > || (gpGlobals->realtime - >> > > > last_realtime > >> > > > >>>> gpGlobals->frametime * 3) >> > > > >>>> > ) { >> > > > >>>> > LARGE_INTEGER PerformanceCount; >> > > > >>>> > >> > > > >> > assert(QueryPerformanceCounter(&PerformanceCount)); >> > > > >>>> > Msg("odd realtime %I64d %f %f >> > %f\n", >> > > > >>>> PerformanceCount, last_realtime, >> > > > gpGlobals->realtime, >> > > > >>>> gpGlobals->frametime); >> > > > >>>> > } >> > > > >>>> > assert(gpGlobals->frametime >= 0.0); >> > > > >>>> > assert(gpGlobals->frametime < .03); >> > > > >>>> > last_realtime = gpGlobals->realtime; >> > > > >>>> >#endif >> > > > >>>> > >> > > > >>>> >At 2006/04/12 12:14 PM, Jay Stelly wrote: >> > > > >>>> >>The master game clock is driven by >> > > > >>>> QueryPerformanceCounter() on win32 >> > > > >>>> >>and gettimeofday() on linux. >> > > > >>>> >> >> > > > >>>> >>Still, we have had reports of clock >> > issues >> > > > with QPC() (not this >> > > > >>>> >>particular issue however) on AMD x2 >> > systems >> > > > that were fixed >> > > > >>>> by forcing >> > > > >>>> >>affinity. Also, for winxp/xp64 there is >> > a >> > > > chipset driver >> > > > >>>> update that >> > > > >>>> >>AMD recommends installing to address some >> > > > timing issues. I >> > > > >>>> don't have >> > > > >>>> >>the info from AMD handy, but someone has >> > > > written about it here (and >> > > > >>>> >>provides links to downloads): >> > > > >>>> >> > > > >> > > >> > >> >>http://ucguides.savagehelp.com/Quake4/FAQ_DualCore.htm#AMD >> > > > >>>> >> >> > > > >>>> >>RDTSC is used for the +showbudget panel. >> > > > There are some issues >> > > > >>with >> > > > >>>> >>that on AMD x2 systems, but that is >> > limited >> > > > to the profiling code. >> > > > >>>> >> >> > > > >>>> >>Jay >> > > > >>>> >> >> > > > >>>> >> >> > > > >>>> >>> -----Original Message----- >> > > > >>>> >>> From: >> > [EMAIL PROTECTED] >> > > > >>>> >>> >> > > > [mailto:[EMAIL PROTECTED] >> > On >> > > > Behalf Of >> > > > >>>> >>> Jeffrey "botman" Broome >> > > > >>>> >>> Sent: Wednesday, April 12, 2006 6:36 AM >> > > > >>>> >>> To: [email protected] >> > > > >>>> >>> Subject: Re: [hlcoders] >> > gpGlobals->realtime >> > > > standing still >> > > > >>>> >>> >> > > > >>>> >>> Jay Stelly wrote: >> > > > >>>> >>> > What platform? (linux/win32)? On >> > linux >> > > > realtime is just >> > > > >>>> >>> accumulating >> > > > >>>> >>> > changes from repeated calls to >> > > > gettimeofday() Have you compared >> > > > >>>> >>> > gpGlobals->realtime to the output of >> > > > Plat_FloatTime() ? >> > > > >>>> >>> Are they both >> > > > >>>> >>> > slow/stopped or just realtime? >> > > > >>>> >>> > >> > > > >>>> >>> > Has anyone else encountered this >> > problem? >> > > > >>>> >>> >> > > > >>>> >>> ...also, what CPU (Intel or AMD)? Are >> > you >> > > > running multiple >> > > > >>>> >>> cores and/or CPUs? I remember recently >> > > > reading about an AMD >> > > > >>>> >>> problem with multiple cores (or was it >> > > > multiple CPUs) where >> > > > >>>> >>> the RDTSC instruction's time wasn't >> > > > syncronized between >> > > > >>>> >>> CPUs/cores so when called once by code, >> > it >> > > > would return the >> > > > >>>> >>> ticks from core 0, when called again, >> > it >> > > > would return the >> > > > >>>> >>> ticks from core 1 (which could be >> > > > different). This would >> > > > >>>> >>> make the system appear to jump ahead in >> > > > time and/or go back >> > > > >>>> >>> in time. If HL2 is using RDTSC instead >> > of >> > > > >>>> >>> QueryPerformanceCounter(), it could get >> > odd >> > > > results on AMD >> > > > >>>> >>> multi-CPU systems. If memory serves >> > > > correctly, Windows >> > > > >>>> >>> forces QueryPerformanceCounter() to >> > always >> > > > run on CPU 0, so >> > > > >>>> >>> you don't get any discrepancy between >> > > > calls. >> > > > >>>> >>> >> > > > >>>> >>> -- >> > > > >>>> >>> Jeffrey "botman" Broome >> > > > >>>> >>> >> > > > >>>> >>> >> > > > _______________________________________________ >> > > > >>>> >>> To unsubscribe, edit your list >> > preferences, >> > > > or view the list >> > > > >>>> >>> archives, please visit: >> > > > >>>> >>> >> > > > >> > > >> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >>>> >>> >> > > > >>>> >>> >> > > > >>>> >> >> > > > >>>> >> > > > >> > >>_______________________________________________ >> > > > >>>> >>To unsubscribe, edit your list >> > preferences, >> > > > or view the >> > > > >>>> list archives, please visit: >> > > > >>>> >> > > > >> > > >> > >> >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >>>> > >> > > > >>>> >> > > > >_______________________________________________ >> > > > >>>> >To unsubscribe, edit your list >> > preferences, or >> > > > view the list >> > > > >>>> archives, please visit: >> > > > >>>> >> > > > >> > > >> > >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >>>> >> > > > >>>> >> > _______________________________________________ >> > > > >>>> To unsubscribe, edit your list preferences, >> > or >> > > > view the list >> > > > >>>> archives, please visit: >> > > > >>>> >> > > > >> > > >> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >>>> >> > > > >>>> >> > > > >>> >> > > > >> > >>>_______________________________________________ >> > > > >>>To unsubscribe, edit your list preferences, >> > or >> > > > view the list archives, >> > > > >>>please visit: >> > > > >> > > >> > >> >>>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >>> >> > > > >>> >> > > > >> > >>>_______________________________________________ >> > > > >>>To unsubscribe, edit your list preferences, >> > or >> > > > view the list archives, >> > > > >>please visit: >> > > > >> > > >> > >> >>>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> >> > > > >> > >>_______________________________________________ >> > > > >>To unsubscribe, edit your list preferences, or >> > > > view the list archives, >> > > > >>please visit: >> > > > >> > > >> > >> >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> >> > > > >> >> > > > >> > >>_______________________________________________ >> > > > >>To unsubscribe, edit your list preferences, or >> > > > view the list archives, please visit: >> > > > >> > > >> > >> >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > > >> > > > >_______________________________________________ >> > > > >To unsubscribe, edit your list preferences, or >> > view >> > > > the list archives, please visit: >> > > > >> > > >> > >> >http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> > > > _______________________________________________ >> > > > To unsubscribe, edit your list preferences, or >> > view >> > > > the list archives, please visit: >> > > > >> > > >> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> > > > >> > > >> > > -------- >> > > My Website http://www.ammahls.com >> > > Lead Programer NightFall >> > http://www.nightfallmod.net >> > > Developer of CST and ZHLT 3.0 >> > http://www.zhlt.info >> > > Team Lead - Prime - >> > http://www.nigredostudios.com >> > > >> > > __________________________________________________ >> > > Do You Yahoo!? >> > > Tired of spam? Yahoo! Mail has the best spam >> > protection around >> > > http://mail.yahoo.com >> > > >> > > _______________________________________________ >> > > To unsubscribe, edit your list preferences, or >> > view the list archives, >> > > please visit: >> > > >> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> > > >> > -- >> > >> > _______________________________________________ >> > To unsubscribe, edit your list preferences, or view >> > the list archives, please visit: >> > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> >> -------- >> My Website http://www.ammahls.com >> Lead Programer NightFall http://www.nightfallmod.net >> Developer of CST and ZHLT 3.0 http://www.zhlt.info >> Team Lead - Prime - http://www.nigredostudios.com >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >-- > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, please >visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
