I think GetTickCount() has worse accuracy than timeGetTime() even (perhaps also influenced by timeBeginPeriod() though). Another option I use on PC's is QueryPerformanceTimer(), but I can imagine those are a bit flaky on mobile or performance-tuning machines.
Cheers, Ruud On Mon, Oct 22, 2012 at 2:51 AM, Lee Salzman <[email protected]> wrote: > You can try replacing it with something like GetTickCount() in the code > instead of using the timeBeginPeriod/timeGetTime stuff and see what > happens... Really, I can't entirely predict how much this will break ENet's > timing or not, try and see... > > > On 10/22/2012 02:58 AM, Mike Kasprzak wrote: > >> (Hey Sven) >> >> Okay, then let me give a practical example so I don't get a "you >> should always use 1ms" response. ;) >> >> To meet Intel's Power Certification requirements, an application must >> idle (not run, but idle) with a timer period 15.6 ms. Basically, if >> you never call "timeBeginPeriod", then you pass. timeBeginPeriod >> changes the ms clock rate of all running applications on Windows, and >> the lowest period set will always have priority. Lower timer periods >> across all of Windows have an effect on power drain, and that is why >> they care. If you're the main in-focus application it's fine, but if >> you're minimized, it's "not neighborly" to be forcing other >> applications to run at a lower timer period when they don't need to. >> At least, that's the best way I can think of to explain that >> requirement. >> >> So the practical use: A game would want to set it to 1 ms due to >> broken vsync and better ping, but if the game is minimized then it >> doesn't need such a low rate. >> >> I found calls to "timeBeginPeriod" in SDL and enet. Again, it's right >> there in the win32 implementation of enet_initialize. >> >> Now sure, I can just go right in to win32.c and remove it. Easy. >> That's not the issue. >> >> The issue is if I do that, can anyone think of a reason enet will break >> on me? >> >> And with that in mind, should enet be doing this all the time anyways? >> SDL gives you the option of building the SDL library without timer >> support, which is a way of disabling it. >> >> I'm totally cool with it staying as a default and all, but should >> there be a "proper" way of disabling it besides editing source? Then >> it becomes my responsibility to set the timer period on Windows as I >> gain/lose application focus (or not at all). I'm just hoping there's >> not some reason enet will suddenly start losing data because my clock >> updates are 15ms slow. :) >> >> Thanks, >> >> Mike Kasprzak >> Sykhronics Entertainment >> www.sykhronics.com >> >> >> On Sun, Oct 21, 2012 at 6:57 PM, Sven Bergström<[email protected]**> >> wrote: >> >>> MIKE, what are you doing on my list! >>> >>> So, I think it's also implementation detail of the game itself, much like >>> ruud suggests. >>> Some games would not need lower precision, some games would. >>> >>> Though that doesn't mean I understand the full extent of the changes on >>> ENet >>> internals, >>> it doesn't appear to (by digging around in the code) change enough to >>> cause >>> problems. >>> >>> I'd wait for lee to weigh in, though. >>> >>> Sven >>> >>> >>> On Sun, Oct 21, 2012 at 7:49 PM, Ruud van Gaal<[email protected]> wrote: >>> >>>> I would say the time accuracy has an influence on ping time, where it >>>> helps to get millsecond accuracy instead of just 15ms. >>>> Resend times are big enough to probably not be influenced much. >>>> >>>> Still, any game quickly uses 1ms timing, if only for accurate fps >>>> timing. >>>> >>>> I think ENet will run, but just a bit more jerky than is needed. >>>> >>>> Ruud >>>> >>>> >>>> On Sun, Oct 21, 2012 at 6:06 PM, Mike Kasprzak<[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I have a bit of an overly technical enet implementation question, so >>>>> apologies in advance. >>>>> >>>>> Long story short, I've been going through and doing some work to make >>>>> an older game of mine pass Intel's power use certification tests. To >>>>> do that, you run Intel's Power Checker tool alongside your app/game: >>>>> >>>>> >>>>> http://software.intel.com/en-**us/software-assessment?&** >>>>> paneltab[tabs-28-main]=pid-**252-28#pid-252-28<http://software.intel.com/en-us/software-assessment?&paneltab[tabs-28-main]=pid-252-28#pid-252-28> >>>>> >>>>> The older game is totally single player game that doesn't use >>>>> networking at all. That said, I was investigating one of my fail >>>>> points (timer precision) by running my new games client and server, >>>>> where I noticed even the server (without any graphics at all) was also >>>>> using a 1ms precision. A bunch of digging later, I found a >>>>> "timeBeginPeriod (1);" call inside win32 implementation of >>>>> enet_initialize. >>>>> >>>>> My question is: How important is timer precision to enet's overall >>>>> implementation? >>>>> >>>>> I realize that's a vague question, so let me clarify. Raising (or not >>>>> changing) the timer precision means calls to timeGetTime() will simply >>>>> not return new numbers until the timer period has passed. So, if the >>>>> Windows default of 15ms is used, no matter how many times you call it >>>>> during those 15ms, it will not change. For reference, timeGetTime is >>>>> used inside enet_time_get and enet_time_set, so that's how it affects >>>>> enet. >>>>> >>>>> So a better question: What would a lower precision timer break in enet? >>>>> >>>>> Like, is the time used in any way that may delay packets? Or is it >>>>> purely statistical, like it will just ruin our frame of reference on >>>>> when a packet was sent/received? >>>>> >>>>> Thanks, >>>>> >>>>> Mike Kasprzak >>>>> Sykhronics Entertainment >>>>> www.sykhronics.com >>>>> ______________________________**_________________ >>>>> ENet-discuss mailing list >>>>> [email protected] >>>>> http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss> >>>>> >>>> >>>> >>>> ______________________________**_________________ >>>> ENet-discuss mailing list >>>> [email protected] >>>> http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss> >>>> >>>> >>> ______________________________**_________________ >>> ENet-discuss mailing list >>> [email protected] >>> http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss> >>> >>> ______________________________**_________________ >> ENet-discuss mailing list >> [email protected] >> http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss> >> >> > ______________________________**_________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/**mailman/listinfo/enet-discuss<http://lists.cubik.org/mailman/listinfo/enet-discuss> >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
