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: hlcoders@list.valvesoftware.com >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: hlcoders@list.valvesoftware.com >>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: hlcoders@list.valvesoftware.com >>> 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: hlcoders@list.valvesoftware.com >>> >>> 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
