But we're talking about timeGetTime() with approx 16ms period, in which case it has no real advantage over GetTickCount().
On Mon, Oct 22, 2012 at 12:56 PM, Ruud van Gaal <[email protected]> wrote: > 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 > >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
