bsnes/ruby/video/xshm.cpp

308 lines
8.7 KiB
C++
Raw Normal View History

Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
//XShm driver for Xorg
//Note that on composited displays, the alpha bits will allow translucency underneath the active window
//As this is not a feature of ruby, this driver must always set the alpha bits on clear() and refresh()
//Linear interpolation is only applied horizontally for performance reasons, although Nearest is still much faster
#include <sys/shm.h>
#include <X11/extensions/XShm.h>
struct VideoXShm : VideoDriver {
VideoXShm& self = *this;
VideoXShm(Video& super) : VideoDriver(super) { construct(); }
~VideoXShm() { destruct(); }
auto create() -> bool override {
VideoDriver::exclusive = true;
return initialize();
}
Update to 20180731 release. byuu says: I've completed moving all the class objects from `unique_pointer<T>` to just T. The one exception is the Emulator::Interface instance. I can absolutely make that a global object, but only in bsnes where there's just the one emulation core. I also moved all the SettingsWindow and ToolsWindow panels out to their own global objects, and fixed a very difficult bug with GTK TabFrame controls. The configuration settings panel is now the emulator settings panel. And I added some spacing between bold label sections on both the emulator and driver settings panels. I gave fixing ComboButtonItem my best shot, given I can't reproduce the crash. Probably won't work, though. Also made a very slight consistency improvement to ruby and renamed driverName() to driver(). ... An important change ... as a result of moving bsnes to global objects, this means that the constructors for all windows run before the presentation window is displayed. Before this change, only the presentation window was constructed first berore displaying it, followed by the construction of the rest of the GUI windows. The upside to this is that as soon as you see the main window, the GUI is ready to go without a period where it's unresponsive. The downside to this is it takes about 1.5 seconds to show the main window, compared to around 0.75 seconds before. I've no intention of changing that back. So if the startup time becomes a problem, then we'll just have to work on optimizing hiro, so that it can construct all the global Window objects quicker. The main way to do that would be to not do calls to the Layout::setGeometry functions for every widget added, and instead wait until the window is displayed. But I don't have an easy way to do that, because you want the widget geometry values to be sane even before the window is visible to help size certain things.
2018-07-31 10:56:45 +00:00
auto driver() -> string override { return "XShm"; }
Update to 20180728 release. byuu says: Sigh, I seem to be spiraling a bit here ... but the work is very important. Hopefully I can get a solid WIP together soon. But for now... I've integrated dynamic rate control into ruby::Audio via setDynamic(bool) for now. It's very demanding, as you would expect. When it's not in use, I realized the OSS driver's performance was pretty bad due to calling write() for every sample for every channel. I implemented a tiny 256-sample buffer and bsnes went from 290fps to 330fps on my FreeBSD desktop. It may be possible to do the same buffering with DRC, but for now, I'm not doing so, and adjusting the audio input frequency on every sample. I also added ruby::Video::setFlush(bool), which is available only in the OpenGL drivers, and this causes glFinish() to be called after swapping display buffers. I really couldn't think of a good name for this, "hard GPU sync" sounds kind of silly. In my view, flush is what commits queued events. Eg fflush(). OpenGL of course treats glFlush differently (I really don't even know what the point of it is even after reading the manual ...), and then has glFinish ... meh, whatever. It's setFlush(bool) until I come up with something better. Also as expected, this one's a big hit to performance. To implement the DRC, I started putting helper functions into the ruby video/audio/input core classes. And then the XVideo driver started crashing. It took hours and hours and hours to track down the problem: you have to clear XSetWindowAttributes to zero before calling XCreateWindow. No amount of `--sync`, `gdb break gdk_x_error`, `-Og`, etc will make Xlib be even remotely helpful in debugging errors like this. The GLX, GLX2, and XVideo drivers basically worked by chance before. If the stack frame had the right memory cleared, it worked. Otherwise it'd crash with BadValue, and my changing things broke that condition on the XVideo driver. So this has been fixed in all three now. Once XVideo was running again, I realized that non-power of two video sizes were completely broken for the YUV formats. It took a while, but I managed to fix all of that as well. At this point, most of ruby is going to be broken outside of FreeBSD, as I still need to finish updating all the drivers.
2018-07-28 11:21:39 +00:00
auto ready() -> bool override { return _ready; }
auto hasFullScreen() -> bool override { return true; }
auto hasMonitor() -> bool override { return true; }
Update to 20180728 release. byuu says: Sigh, I seem to be spiraling a bit here ... but the work is very important. Hopefully I can get a solid WIP together soon. But for now... I've integrated dynamic rate control into ruby::Audio via setDynamic(bool) for now. It's very demanding, as you would expect. When it's not in use, I realized the OSS driver's performance was pretty bad due to calling write() for every sample for every channel. I implemented a tiny 256-sample buffer and bsnes went from 290fps to 330fps on my FreeBSD desktop. It may be possible to do the same buffering with DRC, but for now, I'm not doing so, and adjusting the audio input frequency on every sample. I also added ruby::Video::setFlush(bool), which is available only in the OpenGL drivers, and this causes glFinish() to be called after swapping display buffers. I really couldn't think of a good name for this, "hard GPU sync" sounds kind of silly. In my view, flush is what commits queued events. Eg fflush(). OpenGL of course treats glFlush differently (I really don't even know what the point of it is even after reading the manual ...), and then has glFinish ... meh, whatever. It's setFlush(bool) until I come up with something better. Also as expected, this one's a big hit to performance. To implement the DRC, I started putting helper functions into the ruby video/audio/input core classes. And then the XVideo driver started crashing. It took hours and hours and hours to track down the problem: you have to clear XSetWindowAttributes to zero before calling XCreateWindow. No amount of `--sync`, `gdb break gdk_x_error`, `-Og`, etc will make Xlib be even remotely helpful in debugging errors like this. The GLX, GLX2, and XVideo drivers basically worked by chance before. If the stack frame had the right memory cleared, it worked. Otherwise it'd crash with BadValue, and my changing things broke that condition on the XVideo driver. So this has been fixed in all three now. Once XVideo was running again, I realized that non-power of two video sizes were completely broken for the YUV formats. It took a while, but I managed to fix all of that as well. At this point, most of ruby is going to be broken outside of FreeBSD, as I still need to finish updating all the drivers.
2018-07-28 11:21:39 +00:00
auto hasContext() -> bool override { return true; }
auto hasShader() -> bool override { return true; }
auto setFullScreen(bool fullScreen) -> bool override { return initialize(); }
auto setMonitor(string monitor) -> bool override { return initialize(); }
auto setContext(uintptr context) -> bool override { return initialize(); }
auto setShader(string shader) -> bool override { return true; }
auto focused() -> bool override {
return true;
}
Update to 20180728 release. byuu says: Sigh, I seem to be spiraling a bit here ... but the work is very important. Hopefully I can get a solid WIP together soon. But for now... I've integrated dynamic rate control into ruby::Audio via setDynamic(bool) for now. It's very demanding, as you would expect. When it's not in use, I realized the OSS driver's performance was pretty bad due to calling write() for every sample for every channel. I implemented a tiny 256-sample buffer and bsnes went from 290fps to 330fps on my FreeBSD desktop. It may be possible to do the same buffering with DRC, but for now, I'm not doing so, and adjusting the audio input frequency on every sample. I also added ruby::Video::setFlush(bool), which is available only in the OpenGL drivers, and this causes glFinish() to be called after swapping display buffers. I really couldn't think of a good name for this, "hard GPU sync" sounds kind of silly. In my view, flush is what commits queued events. Eg fflush(). OpenGL of course treats glFlush differently (I really don't even know what the point of it is even after reading the manual ...), and then has glFinish ... meh, whatever. It's setFlush(bool) until I come up with something better. Also as expected, this one's a big hit to performance. To implement the DRC, I started putting helper functions into the ruby video/audio/input core classes. And then the XVideo driver started crashing. It took hours and hours and hours to track down the problem: you have to clear XSetWindowAttributes to zero before calling XCreateWindow. No amount of `--sync`, `gdb break gdk_x_error`, `-Og`, etc will make Xlib be even remotely helpful in debugging errors like this. The GLX, GLX2, and XVideo drivers basically worked by chance before. If the stack frame had the right memory cleared, it worked. Otherwise it'd crash with BadValue, and my changing things broke that condition on the XVideo driver. So this has been fixed in all three now. Once XVideo was running again, I realized that non-power of two video sizes were completely broken for the YUV formats. It took a while, but I managed to fix all of that as well. At this point, most of ruby is going to be broken outside of FreeBSD, as I still need to finish updating all the drivers.
2018-07-28 11:21:39 +00:00
auto clear() -> void override {
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto dp = _inputBuffer;
uint length = _inputWidth * _inputHeight;
while(length--) *dp++ = 255u << 24;
output();
}
auto size(uint& width, uint& height) -> void override {
if(self.fullScreen) {
width = _monitorWidth;
height = _monitorHeight;
} else {
XWindowAttributes parent;
XGetWindowAttributes(_display, _parent, &parent);
width = parent.width;
height = parent.height;
}
}
auto acquire(uint32_t*& data, uint& pitch, uint width, uint height) -> bool override {
if(!_inputBuffer || _inputWidth != width || _inputHeight != height) {
if(_inputBuffer) delete[] _inputBuffer;
_inputWidth = width;
_inputHeight = height;
_inputBuffer = new uint32_t[width * height + 16]; //+16 is padding for linear interpolation
}
data = _inputBuffer;
pitch = _inputWidth * sizeof(uint32_t);
return true;
}
auto release() -> void override {
}
auto output(uint width = 0, uint height = 0) -> void override {
XWindowAttributes window;
XGetWindowAttributes(_display, _window, &window);
XWindowAttributes parent;
XGetWindowAttributes(_display, _parent, &parent);
if(window.width != parent.width || window.height != parent.height) {
_outputWidth = parent.width;
_outputHeight = parent.height;
XResizeWindow(_display, _window, _outputWidth, _outputHeight);
allocate();
}
uint viewportX = 0;
uint viewportY = 0;
uint viewportWidth = parent.width;
uint viewportHeight = parent.height;
if(self.fullScreen) {
viewportX = _monitorX;
viewportY = _monitorY;
viewportWidth = _monitorWidth;
viewportHeight = _monitorHeight;
}
if(!_image || !_inputBuffer || !_outputBuffer) return;
if(!width) width = viewportWidth;
if(!height) height = viewportHeight;
float xratio = (float)_inputWidth / (float)width;
float yratio = (float)_inputHeight / (float)height;
int x = ((int)viewportWidth - (int)width) / 2;
int y = ((int)viewportHeight - (int)height) / 2;
width = min(width, viewportWidth);
height = min(height, viewportHeight);
auto inputBuffer = _inputBuffer;
auto outputBuffer = _outputBuffer;
if(x < 0) {
inputBuffer += abs(x);
x = 0;
}
if(y < 0) {
inputBuffer += abs(y) * _inputWidth;
y = 0;
}
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
x += viewportX;
y += viewportY;
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
#pragma omp parallel for
for(uint y = 0; y < height; y++) {
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
float ystep = y * yratio;
float xstep = 0;
uint32_t* sp = inputBuffer + (uint)ystep * _inputWidth;
uint32_t* dp = outputBuffer + y * _outputWidth;
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
if(self.shader != "Blur") {
for(uint x = 0; x < width; x++) {
*dp++ = 255u << 24 | sp[(uint)xstep];
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
xstep += xratio;
}
} else {
for(uint x = 0; x < width; x++) {
*dp++ = 255u << 24 | interpolate(xstep - (uint)xstep, sp[(uint)xstep], sp[(uint)xstep + 1]);
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
xstep += xratio;
}
}
}
GC gc = XCreateGC(_display, _window, 0, 0);
XShmPutImage(_display, _window, gc, _image, 0, 0, x, y, width, height, False);
XFreeGC(_display, gc);
XFlush(_display);
}
auto poll() -> void override {
while(XPending(_display)) {
XEvent event;
XNextEvent(_display, &event);
if(event.type == Expose) {
XWindowAttributes attributes{};
XGetWindowAttributes(_display, _window, &attributes);
super.doUpdate(attributes.width, attributes.height);
}
}
}
private:
auto construct() -> void {
_display = XOpenDisplay(nullptr);
_screen = DefaultScreen(_display);
XSetErrorHandler(errorHandler);
}
auto destruct() -> void {
terminate();
XCloseDisplay(_display);
}
auto initialize() -> bool {
terminate();
if(!self.fullScreen && !self.context) return false;
_parent = self.fullScreen ? RootWindow(_display, _screen) : (Window)self.context;
XWindowAttributes windowAttributes{};
XGetWindowAttributes(_display, _parent, &windowAttributes);
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
//driver only supports 32-bit pixels
//note that even on 15-bit and 16-bit displays, the window visual's depth should be 32
if(windowAttributes.depth < 24 || windowAttributes.depth > 32) return free(), false;
auto monitor = Video::monitor(self.monitor);
_monitorX = monitor.x;
_monitorY = monitor.y;
_monitorWidth = monitor.width;
_monitorHeight = monitor.height;
_depth = windowAttributes.depth;
_visual = windowAttributes.visual;
_colormap = XCreateColormap(_display, _parent, _visual, AllocNone);
XSetWindowAttributes attributes{};
attributes.border_pixel = 0;
attributes.colormap = _colormap;
attributes.override_redirect = self.fullScreen;
_window = XCreateWindow(_display, _parent,
0, 0, windowAttributes.width, windowAttributes.height,
0, _depth, InputOutput, _visual,
CWBorderPixel | CWColormap | CWOverrideRedirect, &attributes
);
XSelectInput(_display, _window, ExposureMask);
XSetWindowBackground(_display, _window, 0);
XMapWindow(_display, _window);
XFlush(_display);
while(XPending(_display)) {
XEvent event;
XNextEvent(_display, &event);
}
_outputWidth = windowAttributes.width;
_outputHeight = windowAttributes.height;
allocate();
return _ready = (bool)_outputBuffer;
}
auto terminate() -> void {
_ready = false;
free();
if(_window) {
XUnmapWindow(_display, _window);
_window = 0;
}
if(_colormap) {
XFreeColormap(_display, _colormap);
_colormap = 0;
}
}
auto allocate() -> void {
free();
_shmInfo.shmid = shmget(IPC_PRIVATE, _outputWidth * _outputHeight * sizeof(uint32_t), IPC_CREAT | 0777);
if(_shmInfo.shmid < 0) return;
_shmInfo.shmaddr = (char*)shmat(_shmInfo.shmid, 0, 0);
_shmInfo.readOnly = False;
XShmAttach(_display, &_shmInfo);
_outputBuffer = (uint32_t*)_shmInfo.shmaddr;
_image = XShmCreateImage(_display, _visual, _depth, ZPixmap, _shmInfo.shmaddr, &_shmInfo, _outputWidth, _outputHeight);
}
Update to v094r23 release. byuu says: The library window is gone, and replaced with hiro::BrowserWindow::openFolder(). This gives navigation capabilities to game loading, and it also completes our slotted cart selection code. As an added bonus, it's less code this way, too. I also set the window size to consistent sizes between all emulated systems, so that switching between SFC and GB don't cause the window size to keep changing, and so that the scaling size is consistent (eg at normal scale, GB @ 3x is closer to SNES @ 2x.) This means black borders in GB/GBA mode, but it doesn't look that bad, and it's not like many people ever use these modes anyway. Finally, added the placeholder tabs for video, audio and timing. I don't intend to add the timing calculator code to v095 (it might be better as a separate tool), but I'll add the ability to set video/audio rates, at least. Glitch 1: despite selecting the first item in the BrowserDialog list, if you press enter when the window appears, it doesn't activate the item until you press an arrow key first. Glitch 2: in Game Boy mode, if you set the 4x window size, it's not honoring the full requested height because the viewport is smaller than the window. 8+ years of trying to get GTK+ and Qt to simply set the god damned window size I ask for, and I still can't get them to do it reliably. Remaining issues: - finish configuration panels (video, audio, timing) - fix ruby driver compilation on Windows - add DIP switch selection window (NSS) [I may end up punting this one to v096]
2015-05-30 11:39:09 +00:00
auto free() -> void {
if(_image) {
XShmDetach(_display, &_shmInfo);
XDestroyImage(_image);
shmdt(_shmInfo.shmaddr);
shmctl(_shmInfo.shmid, IPC_RMID, 0);
_image = nullptr;
}
_outputBuffer = nullptr;
}
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
Update to v094r23 release. byuu says: The library window is gone, and replaced with hiro::BrowserWindow::openFolder(). This gives navigation capabilities to game loading, and it also completes our slotted cart selection code. As an added bonus, it's less code this way, too. I also set the window size to consistent sizes between all emulated systems, so that switching between SFC and GB don't cause the window size to keep changing, and so that the scaling size is consistent (eg at normal scale, GB @ 3x is closer to SNES @ 2x.) This means black borders in GB/GBA mode, but it doesn't look that bad, and it's not like many people ever use these modes anyway. Finally, added the placeholder tabs for video, audio and timing. I don't intend to add the timing calculator code to v095 (it might be better as a separate tool), but I'll add the ability to set video/audio rates, at least. Glitch 1: despite selecting the first item in the BrowserDialog list, if you press enter when the window appears, it doesn't activate the item until you press an arrow key first. Glitch 2: in Game Boy mode, if you set the 4x window size, it's not honoring the full requested height because the viewport is smaller than the window. 8+ years of trying to get GTK+ and Qt to simply set the god damned window size I ask for, and I still can't get them to do it reliably. Remaining issues: - finish configuration panels (video, audio, timing) - fix ruby driver compilation on Windows - add DIP switch selection window (NSS) [I may end up punting this one to v096]
2015-05-30 11:39:09 +00:00
alwaysinline auto interpolate(float mu, uint32_t a, uint32_t b) -> uint32_t {
uint8_t ar = a >> 16, ag = a >> 8, ab = a >> 0;
uint8_t br = b >> 16, bg = b >> 8, bb = b >> 0;
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
uint8_t cr = ar * (1.0 - mu) + br * mu;
uint8_t cg = ag * (1.0 - mu) + bg * mu;
uint8_t cb = ab * (1.0 - mu) + bb * mu;
Update to v094r23 release. byuu says: The library window is gone, and replaced with hiro::BrowserWindow::openFolder(). This gives navigation capabilities to game loading, and it also completes our slotted cart selection code. As an added bonus, it's less code this way, too. I also set the window size to consistent sizes between all emulated systems, so that switching between SFC and GB don't cause the window size to keep changing, and so that the scaling size is consistent (eg at normal scale, GB @ 3x is closer to SNES @ 2x.) This means black borders in GB/GBA mode, but it doesn't look that bad, and it's not like many people ever use these modes anyway. Finally, added the placeholder tabs for video, audio and timing. I don't intend to add the timing calculator code to v095 (it might be better as a separate tool), but I'll add the ability to set video/audio rates, at least. Glitch 1: despite selecting the first item in the BrowserDialog list, if you press enter when the window appears, it doesn't activate the item until you press an arrow key first. Glitch 2: in Game Boy mode, if you set the 4x window size, it's not honoring the full requested height because the viewport is smaller than the window. 8+ years of trying to get GTK+ and Qt to simply set the god damned window size I ask for, and I still can't get them to do it reliably. Remaining issues: - finish configuration panels (video, audio, timing) - fix ruby driver compilation on Windows - add DIP switch selection window (NSS) [I may end up punting this one to v096]
2015-05-30 11:39:09 +00:00
return cr << 16 | cg << 8 | cb << 0;
Update to v094r09 release. byuu says: This will easily be the biggest diff in the history of higan. And not in a good way. * target-higan and target-loki have been blown away completely * nall and ruby massively updated * phoenix replaced with hiro (pretty near a total rewrite) * target-higan restarted using hiro (just a window for now) * all emulation cores updated to compile again * installation changed to not require root privileges (installs locally) For the foreseeable future (maybe even permanently?), the new higan UI will only build under Linux/BSD with GTK+ 2.20+. Probably the most likely route for Windows/OS X will be to try and figure out how to build hiro/GTK on those platforms, as awful as that would be. The other alternative would be to produce new UIs for those platforms ... which would actually be a good opportunity to make something much more user friendly. Being that I just started on this a few hours ago, that means that for at least a few weeks, don't expect to be able to actually play any games. Right now, you can pretty much just compile the binary and that's it. It's quite possible that some nall changes didn't produce compilation errors, but will produce runtime errors. So until the UI can actually load games, we won't know if anything is broken. But we should mostly be okay. It was mostly just trim<1> -> trim changes, moving to Hash::SHA256 (much cleaner), and patching some reckless memory copy functions enough to compile. Progress isn't going to be like it was before: I'm now dividing my time much thinner between studying and other hobbies. My aim this time is not to produce a binary for everyone to play games on. Rather, it's to keep the emulator alive. I want to be able to apply critical patches again. And I would also like the base of the emulator to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
}
static auto errorHandler(Display* display, XErrorEvent* event) -> int {
//catch occasional BadAccess errors during window resize events
//currently, I'm unsure of the cause, but they're certainly not fatal
return 0;
}
bool _ready = false;
uint32_t* _inputBuffer = nullptr;
uint _inputWidth = 0;
uint _inputHeight = 0;
Display* _display = nullptr;
uint _monitorX = 0;
uint _monitorY = 0;
uint _monitorWidth = 0;
uint _monitorHeight = 0;
int _screen = 0;
int _depth = 0;
Visual* _visual = nullptr;
Window _parent = 0;
Window _window = 0;
Colormap _colormap = 0;
XShmSegmentInfo _shmInfo;
XImage* _image = nullptr;
uint32_t* _outputBuffer = nullptr;
uint _outputWidth = 0;
uint _outputHeight = 0;
};