Add configurable emu-specific blocking of button combinations to be able to stop users from doing soft/hard resets on things such as the GBA.

Add a basic authentication system for administrators for admin actions such as adding an emulator or shutting down the server.

As a workaround for an issue with colliding address spaces, libretro shared objects are copied to their own file and then read from. However, the server doesn't clean this up.

Server must list and send all available emulators. Information must include emulator system, game title, a preview of the emulator.
The join view must be implemented to display all available emulators and a preview.

Have support for users choosing which 'player' they choose to be (think, which port is the controller plugged into?). Have this be a toggleable option to allow for something like a weekly smash bros tournament. Would require an overhaul of the current turn system to allow for four different turn queues going at once.

Possible race condition when using framerate override option. Chunks of the image will appear distorted.

Parallel universes happen if you load the same core twice.

On page load, pull a list of emulators from the server with a preview and allow the user to select which emulator they want to connect to.

As of now, the RetroCore class relies on the Linux dl library. This obviously restricts its use to Linux-based platforms. Add support for Windows and optionally Mac.

Lots of problems relating to building on different platforms that derive from needing C++17 support. Backporting the code to C++14 will help this a lot.

Implement ability to reassign keys or gamepad buttons for game input.

As of now buttons are either on or off. Add support in both the client and server for analog values.

Add logging of IP Addresses and User Agents of those who connect. Retain chat logs, renames, joins, leaves as well as their timestamps.

Stream audio from the server. Add a mute command that stops/starts the server sending audio.

Full overhaul of video/audio required

This would improve builds and reduce errors across platforms. While it would tank the (initial) build time, it would still be worth using.

We already send previews and screen updates as binary data, so why not do the same for chat messages. Messages could be sent as UTF8 data which can be then decoded clientside.

Server could use some kind of system to automatically list and fetch compiled RetroArch cores from the libretro buildbot. Should use latest and nightly (?). Detect platform when accessing the buildbot.

Implementations for this already exist for the RetroArch Android app and possibly the desktop app. See their implementations to know how they access buildbot programmatically, or even if they use buildbot to begin with.

Add section to admin panel once it's completed to select the core from a given list. Server will automatically download it and extract it and use it for the emulator being configured.

Create a web application for updating, managing, creating emulators. Requires #10 to be finished first.

Add a config option to allow operators to specify how guest usernames are assigned (i.e. be able to specify that usernames are to be assigned as player### instead of guest#####)

Currently, every EmulatorController is supposed to exist in its own thread because of some limitations of the libretro API. This isn't a very elegant design, and doesn't scale well. A better solution would be to break out EmulatorControllers into their own processes, and use some form of IPC to communicate/share memory with the LetsPlayServer instance that spawned it. Currently looking into TIPC as the IPC mechanism, because that could be easily extended to allow for emulators run on other devices in a distributed setup which could pave the way for user-hosted emulators (a far-off feature).

GetFrame appears to be one of the biggest places the Let's Play spends its resources. It looks like the old method I was looking into, turning the pixel formats into RGB888 could be made a lot better and clearer by using XRGB8888 which turns out to be directly supported by libturbo-jpeg. This could allow for cores that use XRGB8888 by default to straight up bypass this step for a massive (relative) speed boost.

Build times are horrendous, especially for LetsPlayServer.cpp. Reduce build times by either precompiling imported boost headers or splitting up LetsPlayServer.cpp (Put the queue thread function in its own translation unit?).

Possibly a side effect of turbojpeg moving to XRGB data rather than RGB. A possible clientside fix is to slightly increase hue, brightness, and contrast, on the canvas output which would color correct it to be pretty close to the real deal. However, fixing it server-side would be the optimal solution.

Self explanatory.

Serve the client directly from the server. Serve HTTP and WebSocket on the same port if possible.

Server must block inputs from those who do not have a turn. Server must also send off turn lists when it updates.
Client must not capture keys if there's no turn. The user list has to also display the turn queue. Announce when turns are given.

So I don't get sued by the EU!

Pretty sure nlohmann::json is one of the culprits (other than boost of course) for the terrible build times. That, and this is faster by a long shot.
The HTTP server is currently pretty tied to websocketpp. Because not all transport methods also implement an HTTP server, its probably best we roll our own HTTP server instead of what's tacked onto websocketpp or similar. (#44).
This library looks very promising. Probably should use this for the JSON & HTTP. Also has SQL database support (#40).

Other things:
https://github.com/h2o/h2o (HTTP)
RapidJSON

Client can currently be XSSed. Do server-side HTML escaping of < and > sent from the client for usernames and chats. On client, ensure the HTML escaped characters display correctly.

Right now a lot of the 'classes' are intertwined with each other. They can be decoupled by using events.

Prevent people spamming chat

Currently compiling is restricted to just gcc 8.

Docs: https://libretro.readthedocs.io/en/latest/development/cores/opengl-cores/
An example implementation of a gl core: https://bitbucket.org/Themaister/libretro-gl/src/master/gl.cpp
Another: https://github.com/libretro/libretro-3dengine

This is a step towards (#35).