I'm currently testing yojimbo for my top-down shooter as it looks like a really solid network stack.
I already did some gameplay tests and I think I'll stay with this library for quite some time to come!
I made some commits along the way that I think could perhaps be useful.
The first commit makes the channels' HasMessagesToSend methods accessible to the library's user
the same way that CanSendMessage methods are.
One use-case I can think of if is the initial state of the world is reaally huge, say, it takes several seconds to transfer.
The next server update, whether it's a delta-compressed snapshot or a list of inputs -
might grow so huge during the initial transfer that it's probably best sent using another block message, so the server would simply check if the initial block has gotten through using HasMessagesToSend, and if it did, send a correction that will get through a lot faster, and only then begin to send regular messages.
The second commit removes an unused field, which is blockData inside the SendBlockData. It compiles just fine without the field, and it's quite logical not to need it - as far as I understand, it is the library's user that allocates the necessary memory for the block through AllocateBlock, and later fills that memory. This is in contrast to ReceiveBlockData, which needs a working space ready whenever a block starts coming in.
The third commit is self-explanatory.
The tests pass - at least for me!
Hello Glenn,
I'm currently testing yojimbo for my top-down shooter as it looks like a really solid network stack. I already did some gameplay tests and I think I'll stay with this library for quite some time to come! I made some commits along the way that I think could perhaps be useful.
The first commit makes the channels'
HasMessagesToSendmethods accessible to the library's user the same way thatCanSendMessagemethods are. One use-case I can think of if is the initial state of the world is reaally huge, say, it takes several seconds to transfer. The next server update, whether it's a delta-compressed snapshot or a list of inputs - might grow so huge during the initial transfer that it's probably best sent using another block message, so the server would simply check if the initial block has gotten through usingHasMessagesToSend, and if it did, send a correction that will get through a lot faster, and only then begin to send regular messages.The second commit removes an unused field, which is
blockDatainside theSendBlockData. It compiles just fine without the field, and it's quite logical not to need it - as far as I understand, it is the library's user that allocates the necessary memory for the block throughAllocateBlock, and later fills that memory. This is in contrast toReceiveBlockData, which needs a working space ready whenever a block starts coming in.The third commit is self-explanatory. The tests pass - at least for me!
Cheers!