Skip to content
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

Emulator <-> API connection requires 4 API calls per frame. #17

Open
OhmGeek opened this issue Dec 20, 2018 · 5 comments
Open

Emulator <-> API connection requires 4 API calls per frame. #17

OhmGeek opened this issue Dec 20, 2018 · 5 comments
Labels
enhancement New feature or request

Comments

@OhmGeek
Copy link
Collaborator

OhmGeek commented Dec 20, 2018

This is a slight bottleneck, as the emulator input plugin blocks while the TCP socket fetches the response, causing stuttering.

Instead of requesting 4 responses per image frame, instead request 1 response containing the entire memory buffer.

This will require a slight change in the JSON structure, such that:

{
  "PLAYER_1_ANALOG": [0,0],
   ...

   "PLAYER_4_A_BTN: 0
}

We can then parse this more easily, using only function calls on a string instead of blocking the input thread.

@OhmGeek OhmGeek added the enhancement New feature or request label Dec 20, 2018
@OliMac1
Copy link
Collaborator

OliMac1 commented Oct 20, 2019

New idea for reducing this bottleneck:

  • UDP sent from the server to the plugin at set rate eg. 30 Hz.
  • The plugin stores the relevant data and the response is fetched internally.
  • To deal with potential atomicity issues I propose a system similar to swapping a framebuffer with one controller to be written to and one to be read from.

This stops the API being restful but will reduce latency and network traffic.

@OhmGeek
Copy link
Collaborator Author

OhmGeek commented Oct 20, 2019

That could definitely work - for now, I'm looking into running the constant polling in a separate thread, with controller still being stored in shared memory (and just being written). The bottleneck was because of the blocking nature, so that might help in the short term. But definitely switching to either UDP/using Kafka (and polling at 60 Hz as per Nyquist theorem might be suitable)

@OhmGeek
Copy link
Collaborator Author

OhmGeek commented Oct 20, 2019

See #20 for the multithreaded approach. Still working on testing it (need to sort out my linux again).

As part of the new Java server (#19), looking at making it fairly decoupled so we can accept user requests from REST, while throwing state outputs to either REST/UDP/TCP or even Apache Kafka (which might be useful if we want to have it dealing with multiple games in the future).

If you want to start looking into the UDP based method that'll be good, as I think that'll be the best solution for now (Kafka is definitely a pipedream at the moment)

@OliMac1
Copy link
Collaborator

OliMac1 commented Oct 20, 2019

Do kafka streams support non Java consumers? The Plugin won't necessarily like the data fed to it?

@OhmGeek
Copy link
Collaborator Author

OhmGeek commented Oct 20, 2019

Yes, just depends on the serialiser/deserialiser: we would need to use a Json Serialise/Deserialisation based scheme, rather than bytes directly. But there is a C API for Kafka. UDP for now might be the best shout, since we only have one session, providing we fix the hostname based issue (so we could host the central server somewhere other than locally)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants