ucontext_t is what POSIX requires; glibc no longer provides struct
ucontext as of 2.26: https://sourceware.org/glibc/wiki/Release/2.26
(Most architectures were already using ucontext_t, so this also makes
things more consistent; only arm and mips change.)
This should help with debugging windowing system issues, which may reside in SDL, which SDL may not provide adequate diagnostic info, or which Basilisk may not report
This change may end up being a bit slower on some systems, as the SDL backend will now render its content to two, new, SDL_Surfaces: one of which is in the guest OS' resolution, the other of which is application defined.
SDL2's SDL_Render API is used, which exposes some rudimentary elements of GPU + texture-based programming. Basilisk II now maintains a single 'SDL_Texture' object, which is an SDL representation of a GPU texture. The 'outer' surface will be used to update this texture, as requests to redraw are made.
TODO: look into removing the 'outer' SDL surface, and see if we can just copy the 'inner' surface to the SDL_Texture.
TODO: the entire SDL_Texture is updated, any time a request is made to draw. Look into minimizing this a bit.
SDL 1.x is used for display, rather than Mac OS X specific backend. If time permits, I'll port it to SDL 2, if only to reduce Basilisk's overall code foot-print.
Lots of features are apt to be disabled, as many 'dummy' backends were used.
Video-depths other than 1-bit or 32-bit are untested, and in some cases (4-bit, at least) are currently non-functional. This is due to a partial re-write of the SDL backend's blitting code, which was non-functional when low-bit-depths were used.
The SDL backend was also rewired, on OSX, to not attempt to align the display buffer on page-boundaries. So far, this doesn't seem to cause any notice-able problems, however, that's only using limited knowledge and testing (System 7.5.x does boot and display at 640x480, though!). The original display-buffer allocation code was failing to run, in some cases.
Preferences are, on Mac, currently hardcoded to be accessed at /tmp/BasiliskII/BasiliskII_Prefs. The folder, "/tmp/BasiliskII/", may be a symbolic link to elsewhere, though.
This lets you setup an environment to cross-compile, with extended support for how things will behave.
This should let the build play nicely with bitbake, without changing the --flags, and without breaking existing behaviors.
