-- [ 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
