Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
So, IIRC, everyone sends blocks with the delay (except for that one guy who made a thread and y'all ignored me saying the thread.sleep) as System.Threading.Thread.Sleep(delay)...
Would it be more efficient in this case to have a fancy timer setup, or a form of WaitCall, so it isn't hogging a thread?
Or is the delay so minimal that the benefit is negligible compared to the extra processing required?
Offline
I've had decent results with a timer and a queue; the timer send a block for every tick when the queue has 1+ items in it, so all I need to is queue block packets. This has the added benefit of being able to easily add packets sent to a list, as a few ticks after a block is sent, the code checks whether that block is still in the list - the packet is removed from the list if/when it's received back from "b".
While it's definitely more difficult to get a timer doing something similar, in the long run it saves a good few lines of code by removing the need for any Thread.Sleep() or terrible thread hogging.
Whether it's actually more efficient... ^^ I can't really say. It's definitely more convenient, especially with block-checking added, and it might be faster given that the resolution of Thread.Sleep is about 10 or 15ms. Timers can be reprogrammed to have a resolution of 1ms.
I was on a roll while coding this, and made the timer automatically optimise its tick to send blocks as fast as possible without resending too many packets. In that case a timer is even more convenient.
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
Pages: 1
[ Started around 1740042906.1286 - Generated in 0.052 seconds, 10 queries executed - Memory usage: 1.38 MiB (Peak: 1.48 MiB) ]