Jul 30 2015, 4:48 am
|
|
MrStonedOne
 |
Like, if you want higher resolution times, make a new fucking thread. Don't tack it on to some other thread and attack anybody who doesn't take your new "requirement" into account.
|
I must have missed how the argument started because I can't make sense of the disagreement, but for my two cents I agree that higher-res timers are a different animal than getting a tick completion amount.
| |
The argument started here:
http://www.byond.com/ forum/?post=1904435&page=3#comment16139213 I got a few posts compiling about me not addressing some side topic, then this bit of passive agressiveness: http://www.byond.com/ forum/?post=1904435&page=3#comment16139273 | |
Ah. To be honest the stuff ... stuff code made zero sense to me in the context of measuring ticks, so I'm guessing Marquesas didn't get it either. Like you I wasn't thrilled with the tone of his post though.
| |
So how this would work, is when byond goes to start a tick, it calls the default world/loop() (or lets actually call it, world/GameLoop() ) and everything byond does internally happens there. If somebody wants to implement their own things to happen every tick, or their own game loop, they can just override it, and call ..() for when byond should do its own internal once a tick stuff.
If you know when the start of a tick happens, because you can actually override the internal game loop, you can just save world.timeofday at the start, and compare that with world.ticklag when you want to know the tick completion. Then tick completion percentage would be as easy as var/tick_completion_percentage = (world.timeofday-tickstart)/world.tick_lag*100 This also solves the issue of everybody who wants to make something happen at a regular interval jumping thru odd hoops. At tgstation, we have a master controller, AND a failsafe controller, to detect when the master controller isn't firing. What if we could actually have a proc that gets called every tick. Removes the entire need for that mess, lets games have a more intimate relation with the internal byond tick if they want, and just makes sense. | |
But I think world.timeofday itself still lacks the precision to handle this sort of task.
| |
Been awhile since I worked with it, I just remember it having a decimal part to it. Or maybe I'm thinking of world.time
| |
I will add, (possibly uselessly), that volundr and mso are both working on different process schedulers/MCs, and are using their own approaches to it. (Different codebases)
So it's possible that the arguments arose from arguing over two different methods to approach the same problem? | |
Lummox JR wrote:
But I think world.timeofday itself still lacks the precision to handle this sort of task. I attempted to build something like StonedOne was describing. The problem is that the granularity of Timeofday is limited to roughly your tick lag value. Even at 40fps (tick lag of 0.25), it's just not precise enough to calculate overruns of less than 100%. Using sleep(-1) is more effective, as it seems to actually sleep out before the level of overrun that StonedOne's technique could detect. Really, it's all a moot point anyway because none of the world timer variables update amid-tick. They are updated at the beginning of each individual tick prior to any calls being continued from the last tick. If DLL calls weren't so damn expensive, that'd be a great solution to the problem. | |
Ya, I just did some tests, It was world.time I was thinking of having a decimal part to it, and that's only if your tick_lag would cause it to not equal whole numbers.
| |
So what you're saying is it might be more ideal to have like, .16 ticklag, but then use interpolation/framerate stuff lummox might eventually add to control how fast everything is, and use the scheduler/mc to slow down/ speed up processes intelligently?
| |
So what you're saying is it might be more ideal to have like, .16 ticklag, but then use interpolation/framerate stuff lummox might eventually add to control how fast everything is, and use the scheduler/mc to slow down/ speed up processes intelligently? Probably not. Having the server run at a slower tick rate than the client is more sensible than having the server run at a faster tick rate than the client. | |
If you use volundr's dll to get a real time timer, (after they make my suggested changes to it, and allow it to be given a number (in seconds or deciseconds) to offset the amount (like, say, the world.timeofday that the world started at)) you could do whats requested.
IF lummux codes what I'm talking about, giving you a way to know when the tick begins, via a proc you can define/override, that happens each tick. (Ideally one you override, so you can have end of tick code and time how long byond spends on its internal stuff/calling spawned/sleeped procs/handling and calling client verb/move actions) | |
IF lummux codes what I'm talking about, giving you a way to know when the tick begins Honestly, I'm not sure that what we really need is any kind of override function. Just giving us a high-granularity time variable (or proc) that pulls from the system time every time it's read rather than just living with a once-per-frame locked time value, you'd be able to do what you are talking about on your own. No need for specific implementations, much more flexible and reasonable. BYOND's a game development engine. It should stray away from specific implementations where at all possible and simply expose general tools to the developer that allow them to control their own experience. The more convoluted and specific the implementation, the less likely it is to be of use to everyone. | |
Ter13: Last night I changed my dll to provide the time in seconds since the start of the hour with millisecond accuracy. Byond's float can handle this level of accuracy. Before, I was providing a higher-precision analogue of world.timeofday, which was losing precision due to the nature of byond floating point values. I made some changes to my process scheduler, and it can now schedule work accurately enough to keep cpu utilization at about 100%.
The code does a lot of work to ensure it's one of the first things that runs during the tick, in order to determine how much time has elapsed during the tick. Having an elapsed time var would save a lot of that hassle. I'll be uploading the changes to github shortly. | |
ter:
As brought up in this thread, multiple times, such variable is useless for the intended purpose of the OP and volundr if you can't link it to the start or end of a tick. It also allows for you to explicitly control where in your periodical loop internal stuff happens at. Do you want byond's internal tick handling to run before or after you do your stuff (this can make difference) This thread, if you go back and read the op, is about the knowing how far along in a tick you are, can't do that if you don't know when tick has started. Doing it the override way allows for a proper before -> core -> after approach. it's just flat out more powerful for the future, its more OOP, and it falls in line with how interaction with internal byond processes have always worked. High precision timers is ALSO something we need, but can we all please stop derailing the thread over it. Having an elapsed time var would save a lot of that hassle. It can't be a var, this wouldn't be able to be updated with any sort of accuracy without too much overhead. Am I not wrong in saying that doing what you want to do with timing your stuff at the start of the tick would be massively easier if you could literally bind to the start of the loop? Regardless of how much you think that it would be "abused", am I not wrong? | |
I'm not looking to just solve this one particular issue, having a more intimate knowledge of internal byond ticks has sooooooooooooooooooooooo many potential uses AND helps solve your issue about knowing how far into a tick you are.
| |
MrStonedOne: With the time resolution that currently exists in the engine, being able to override the main loop isn't useful. world.timeofday at the beginning of the loop is almost always going to be the same value as at the end of the loop.
I'm happy to start a new thread, but if one feature request is totally useless without another, then what is the point of having two threads? | |
And furthermore, this feature request thread was originally about a tick completion percentage. Where does overriding the main loop come into that?
| |
world.timeofday at the beginning of the loop is almost always going to be the same value as at the end of the loop.
Yes, but! if you use your system, AND move the process scheduler to run (or get started by) the overridden loop. You have a guarantee that it's the start of the tick. | |