MacOS support
Now that it was proven possible to port libTAS to MacOS with at least one game hooked correctly, here is all the stuff to implement for a full MacOS support:
Setup:
- [X] Protect OS-specific code in library
- [X] Write specific code for preloading library
- [X] Xcode project
- [X] Listen to keyboard events for hotkeys
- [X] Convert MacOS keycodes to xcb keysyms for movie compatibility
- [X] Launch MacOS
.appapplications - [ ] Bundle libtas program, library and additional frameworks (Qt) to get a standalone application
- [ ] Determine what are the necessary steps to get the authorization to run the program (read/write memory of child process, listen to system keyboard events)
Several features need to be written using MacOS API:
- [x] Write an audio player using CoreAudio
- [x] Resample audio using CoreAudio
- [ ] Render text into a surface for HUD, using either Core Text or Cocoa
- [ ] Get pixels from the window surface for video encoding
Specifically for savestates:
- [ ] Handle TLS
- [ ] Get memory map of process, parse it and read/write into memory
- [ ] Restore the state of connection to Quartz server, if need (I really don't know anything about that step :/)
- [ ] Cleanly disable unsupported features (incremental savestates won't work, unless there's something inside XNU kernel)
- [ ] Get information on memory pages, for possible optimization (unused/zero pages?)
SDL is almost automatically supported, because we already hook all the relevant part of the API. If we want to go further, we need to hook the lower levels. It seems a better choice to hook the low-level API (Core Foundation) than the high-level API (Cocoa), because the former is pure C. The list of things to hook include:
- [ ] Core Audio, for getting the audio played by the game
- [ ] Core OpenGL, for intercepting the OpenGL functions, and the specific functions. A nice thing is that Apple has its own software rendering, so we don't have extra work to do for savestates. However, OpenGL was deprecated from MacOS 10.14
- [ ] Metal (not the priority)
- [ ] Core Graphics/Quartz, for events, windows, rendering, etc.
- [ ] Mach kernel API
Bug fixes:
- [X] Change all dirent API hooking so that it uses the matching
struct direnttype, causingreaddir()to report garbage data. - [ ] Executables can store its list of linked library paths using relative paths, but because we hook
dlopen(), the caller is not the executable anymore but our library. Special paths like@loader_path(directory of the caller path) and@rpath(special path included in the caller header section) won't work anymore - [x] We need to write our own keysym -> description translation, because
XKeysymToString()is not available.
@Sappharad could you provide some assistance with this given how youre familiar with mac os?
@Sappharad could you provide some assistance with this given how youre familiar with mac os?
I don't really have time to pick up any additional projects right now. If there's something in particular you want I might be able to point you in the right direction but it seems like @clementgallet is doing a great job.
Regarding
- [ ] Executables can store its list of linked library paths using relative paths, but because we hook dlopen(), the caller is not the executable anymore but our library. Special paths like @loader_path (directory of the caller path) and @rpath (special path included in the caller header section) won't work anymore
See #411.
so, im not sure if this is a dumb question, but do you think this can be used for openemu? once its ported of course
It absolutely won't work. Also, openemu is a frontend for existing emulators. You should check which console you want to TAS and seek for an existing emulator with TAS support.