-
Notifications
You must be signed in to change notification settings - Fork 10
Asynchronous mode #60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or 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
…ntirely for reinsertion via BotWrapper, so this revision is in a non-working state.
…ent of bot idleness and frame buffer size.
…mmands to live shared memory instead of uselessly writing them to the frame buffer.
… direct ByteBuffers on successive games, due either to fragmentation or leaking (or both). Now reusing the FrameBuffer across games so we only have to allocate once, for the first game. Replaced some unnecessary references to ClientData with GameData. Cleaned up BWClient game loop.
… removed 'idleness' concept from BotWrapper.
…t pass at performance metrics.
…ontrol immediately always). Improved some metrics
…gured tests to run with sufficient memory to allocate framebuffers.
…due to assertion errors
…t frame performance test
New in the pull request:
I believe all loose ends are tied up and this PR is ready for review in its current state. |
We're on passing tests now and merge compatibility with develop. @JasperGeurtz what do you think? |
LGTM, thank you for finishing this up! three questions:
I don't mind version 2.0 being a bit experimental for now, and just keeping 1.5.1 as the "stable" branch that anyone can use |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This pull request adds an optional asynchronous operation mode to JBWAPI, similar to the non-blocking mode of TorchCraft.
The goal is to allow bot authors to more reliably ensure real-time performance for their bots. Async mode runs in two threads: One for communication with BWAPI, and one for bot operation. This allows bot code to run independently of the BWAPI control flow, and for JBWAPI to release its lock-step control of StarCraft in a timely fashion even if bot code is still running.
When a new frame from BWAPI is ready, JBWAPI copies it into a queue of frames for the bot to process. JBWAPI then waits 40ms (configurable) for the bot to finish processing all the frames in the queue. When the bot has done so or time has elapsed, JBWAPI returns control to BWAPI.