57 ms·

This bug is still there in OpenBSD. With the 100Hz tick rate, sleep(10ms) turns effectively into 15 milliseconds, or -- more likely -- 20 milliseconds if the s

by clarry 8y ago

This bug is still there in OpenBSD. With the 100Hz tick rate, sleep(10ms) turns effectively into 15 milliseconds, or -- more likely -- 20 milliseconds if the system is lightly loaded and the program doesn't spend much of its timeslice. Of course, some programs don't expect this. Fun story, me and my little sister played a game online years ago. The Mana World. A game with an OpenBSD port. She teamed up with some guy in game. She also told me that guy had a terrible internet connection & slow PC. So once I found them, I watched this guy lag and move about in slow motion. I asked if he's running OpenBSD. He said he's running OpenBSD. I sent him a little patch and it's like he got a new PC and a new internet connection, just like that.. :-)

ouid 8y ago
do you have a link to this little patch so that I can refer to this post at some point in the future?
mikroskeem 8y ago
can you put this patch up somewhere, e.g gist.github.com or something? or atleast point us where to look exactly? thank you :)
- clarry 8y ago
  Why, do you work on TMW? Like I said, it was years ago. If I still have the patch, it's got to be on one of these spinning rust disks sitting in my closet. I'm on a trip so I really can't look for it now. Assuming the client is still buggy (things like SDL2 have happened so who knows?), I'd probably look here first: https://gitlab.com/manaplus/manaplus/blob/485e9bb12bf5dda318ac0ccbf1d2a1cd86cf8c70/src/utils/timer.cpp#L64 https://gitlab.com/manaplus/manaplus/blob/485e9bb12bf5dda318... The logic won't run right if the timer is implemented with a sleep that ends up sleeping much longer than intended. If it works like it did back then (sleep is virtually always 20ms), simply incrementing the tick count by two every time should be enough to make it smooth on OpenBSD. Of course the correct fix is to keep track of actual time spent and adjust ticks accordingly. Or use a timer mechanism that has higher precision. IIRC setitimer[1] can get you a regular 100Hz alarm on OpenBSD. http://man.openbsd.org/setitimer.2 http://man.openbsd.org/setitimer.2 If I'm not entirely mistaken, the old userspace implementation of pthreads worked with a 100Hz timer using this mechanism.
  - mikroskeem 8y ago
    >Why, do you work on TMW? oh, no. i'm just curious

by clarry 8y ago

ouid 8y ago

do you have a link to this little patch so that I can refer to this post at some point in the future?

mikroskeem 8y ago

can you put this patch up somewhere, e.g gist.github.com or something? or atleast point us where to look exactly? thank you :)

clarry 8y ago
Why, do you work on TMW? Like I said, it was years ago. If I still have the patch, it's got to be on one of these spinning rust disks sitting in my closet. I'm on a trip so I really can't look for it now. Assuming the client is still buggy (things like SDL2 have happened so who knows?), I'd probably look here first: https://gitlab.com/manaplus/manaplus/blob/485e9bb12bf5dda318ac0ccbf1d2a1cd86cf8c70/src/utils/timer.cpp#L64 https://gitlab.com/manaplus/manaplus/blob/485e9bb12bf5dda318... The logic won't run right if the timer is implemented with a sleep that ends up sleeping much longer than intended. If it works like it did back then (sleep is virtually always 20ms), simply incrementing the tick count by two every time should be enough to make it smooth on OpenBSD. Of course the correct fix is to keep track of actual time spent and adjust ticks accordingly. Or use a timer mechanism that has higher precision. IIRC setitimer[1] can get you a regular 100Hz alarm on OpenBSD. http://man.openbsd.org/setitimer.2 http://man.openbsd.org/setitimer.2 If I'm not entirely mistaken, the old userspace implementation of pthreads worked with a 100Hz timer using this mechanism.
- mikroskeem 8y ago
  >Why, do you work on TMW? oh, no. i'm just curious