This repository has been archived by the owner on Jul 26, 2022. It is now read-only.
Non-blocking mode for BWEnv #211
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jgehring
commented
Oct 17, 2017
BWEnv/include/controller.h
Outdated
| @@ -145,13 +149,17 @@ class Controller { | |||
| static const int pixelsPerTile = 32; | |||
| static const int pixelsPerWalkTile = 8; | |||
| bool logCommands = true; | |||
| int combine_frames = 1; | |||
| int max_combine_frames = 1; | |||
There was a problem hiding this comment.
This should actually be named min_combine_frames. Will update.
jgehring
force-pushed
the
bwenv-nonblocking
branch
from
a995ff5
to
83ec59a
Compare
In non-blocking mode, BWEnv will block the game for a specified maximum amount of time only before continuing. This enables abiding time limits for a given match-up without adding complicated timing logic to the TorchCraft client program. If the client does not send commands for the current frame back in time (e.g. receive in BWEnv times out), the game continues and a new attempt to receive them will take place in the very next frame and so on until we finally get a reply. If BWEnv absolutely has to send the frame (e.g. the game or battle is over), it will perform a blocking receive call before sending it to abide the REQ/REP pattern. Please note the interplay with the SET_COMBINE_FRAMES option: BWEnv can only send frame data to the client after having a received a message with commands. Hence, if it is unable to send new frame data it will keep combining frames and eventually send the combined frame in the next execution of `Controller::onFrame()` after the successful receive. Hence, SET_COMBINE_FRAMES defines a *minimum* number of combined frames for non-blocking mode. The default behavior is blocking mode (i.e. the same as before). It can be enabled specifically via the new SET_BLOCKING command. The timeout can also be set via a new command; by default it's 50ms.
jgehring
force-pushed
the
bwenv-nonblocking
branch
from
83ec59a
to
8ec58f3
Compare
syhw
approved these changes
Oct 31, 2017
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In non-blocking mode, BWEnv will block the game for a specified maximum amount
of time only before continuing. This enables abiding time limits for a given
match-up without adding complicated timing logic to the TorchCraft client
program.
If the client does not send commands for the current frame back in time (e.g.
receive in BWEnv times out), the game continues and a new attempt to receive
them will take place in the very next frame and so on until we finally get a
reply. If BWEnv absolutely has to send the frame (e.g. the game or battle is
over), it will perform a blocking receive call before sending it to abide the
REQ/REP pattern.
Please note the interplay with the SET_COMBINE_FRAMES option: BWEnv can only
send frame data to the client after having a received a message with commands.
Hence, if it is unable to send new frame data it will keep combining frames and
eventually send the combined frame in the next execution of
Controller::onFrame()after the successful receive. Hence, SET_COMBINE_FRAMESdefines a minimum number of combined frames for non-blocking mode.
The default behavior is blocking mode (i.e. the same as before). It can be
enabled specifically via the new SET_BLOCKING command. The timeout can also be
set via a new command; by default it's 50ms.