2013-04-09 13:31:46 +00:00
|
|
|
#include "opengl/opengl.hpp"
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2013-07-29 09:42:45 +00:00
|
|
|
#define GLX_CONTEXT_MAJOR_VERSION_ARB 0x2091
|
|
|
|
#define GLX_CONTEXT_MINOR_VERSION_ARB 0x2092
|
|
|
|
|
2015-11-08 08:54:42 +00:00
|
|
|
auto VideoGLX_X11ErrorHandler(Display*, XErrorEvent*) -> int {
|
|
|
|
return 0; //suppress errors
|
|
|
|
}
|
|
|
|
|
2018-08-05 09:00:15 +00:00
|
|
|
struct VideoGLX : VideoDriver, OpenGL {
|
|
|
|
VideoGLX& self = *this;
|
2019-07-07 09:44:09 +00:00
|
|
|
VideoGLX(Video& super) : VideoDriver(super) { construct(); }
|
|
|
|
~VideoGLX() { destruct(); }
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2018-08-05 09:00:15 +00:00
|
|
|
auto create() -> bool override {
|
|
|
|
super.setFormat("RGB24");
|
|
|
|
return initialize();
|
|
|
|
}
|
|
|
|
|
2018-08-09 04:15:56 +00:00
|
|
|
auto driver() -> string override { return "OpenGL 3.2"; }
|
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; }
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
auto hasExclusive() -> 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 hasBlocking() -> bool override { return true; }
|
|
|
|
auto hasFlush() -> bool override { return true; }
|
|
|
|
auto hasShader() -> bool override { return true; }
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2018-08-05 09:00:15 +00:00
|
|
|
auto hasFormats() -> vector<string> override {
|
2019-07-07 09:44:09 +00:00
|
|
|
if(_depth == 30) return {"RGB30", "RGB24"};
|
|
|
|
if(_depth == 24) return {"RGB24"};
|
|
|
|
return {"RGB24"}; //fallback
|
|
|
|
}
|
|
|
|
|
|
|
|
auto setExclusive(bool exclusive) -> bool override {
|
|
|
|
return initialize();
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
}
|
|
|
|
|
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 setContext(uintptr context) -> bool override {
|
2017-07-24 05:23:40 +00:00
|
|
|
return initialize();
|
|
|
|
}
|
2012-03-10 12:37:36 +00:00
|
|
|
|
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 setBlocking(bool blocking) -> bool override {
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
if(glXSwapInterval) glXSwapInterval(blocking);
|
2017-07-24 05:23:40 +00:00
|
|
|
return true;
|
|
|
|
}
|
2012-03-10 12:37:36 +00:00
|
|
|
|
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 setFlush(bool flush) -> bool override {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto setFormat(string format) -> bool override {
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
if(format == "RGB24") {
|
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
|
|
|
OpenGL::inputFormat = GL_RGBA8;
|
2019-07-07 09:44:09 +00:00
|
|
|
return initialize();
|
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
|
|
|
}
|
|
|
|
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
if(format == "RGB30") {
|
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
|
|
|
OpenGL::inputFormat = GL_RGB10_A2;
|
2019-07-07 09:44:09 +00:00
|
|
|
return initialize();
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
}
|
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
|
|
|
|
|
|
|
return false;
|
2017-07-24 05:23:40 +00:00
|
|
|
}
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
|
2018-08-21 03:17:12 +00:00
|
|
|
auto setShader(string shader) -> bool override {
|
|
|
|
OpenGL::setShader(shader);
|
2017-07-24 05:23:40 +00:00
|
|
|
return true;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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 {
|
2017-07-24 05:23:40 +00:00
|
|
|
OpenGL::clear();
|
|
|
|
if(_doubleBuffer) glXSwapBuffers(_display, _glXWindow);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
auto size(uint& width, uint& height) -> void override {
|
|
|
|
XWindowAttributes window;
|
|
|
|
XGetWindowAttributes(_display, _window, &window);
|
|
|
|
|
|
|
|
XWindowAttributes parent;
|
|
|
|
XGetWindowAttributes(_display, _parent, &parent);
|
|
|
|
|
|
|
|
if(window.width != parent.width || window.height != parent.height) {
|
|
|
|
XResizeWindow(_display, _window, parent.width, parent.height);
|
|
|
|
}
|
|
|
|
|
|
|
|
width = parent.width;
|
|
|
|
height = parent.height;
|
|
|
|
}
|
|
|
|
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
auto acquire(uint32_t*& data, uint& pitch, uint width, uint height) -> bool override {
|
2013-04-09 13:31:46 +00:00
|
|
|
OpenGL::size(width, height);
|
2010-08-09 13:28:56 +00:00
|
|
|
return OpenGL::lock(data, pitch);
|
|
|
|
}
|
|
|
|
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
auto release() -> void override {
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
auto output(uint width, uint height) -> void override {
|
|
|
|
uint windowWidth, windowHeight;
|
|
|
|
size(windowWidth, windowHeight);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
OpenGL::absoluteWidth = width;
|
|
|
|
OpenGL::absoluteHeight = height;
|
|
|
|
OpenGL::outputWidth = windowWidth;
|
|
|
|
OpenGL::outputHeight = windowHeight;
|
2017-07-24 05:23:40 +00:00
|
|
|
OpenGL::output();
|
|
|
|
if(_doubleBuffer) glXSwapBuffers(_display, _glXWindow);
|
2018-08-05 09:00:15 +00:00
|
|
|
if(self.flush) glFinish();
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
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 poll() -> void override {
|
2018-06-10 08:07:19 +00:00
|
|
|
while(XPending(_display)) {
|
|
|
|
XEvent event;
|
|
|
|
XNextEvent(_display, &event);
|
|
|
|
if(event.type == Expose) {
|
|
|
|
XWindowAttributes attributes;
|
|
|
|
XGetWindowAttributes(_display, _window, &attributes);
|
2018-08-05 09:00:15 +00:00
|
|
|
super.doUpdate(attributes.width, attributes.height);
|
2018-06-10 08:07:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
private:
|
2019-07-07 09:44:09 +00:00
|
|
|
auto construct() -> void {
|
2017-07-24 05:23:40 +00:00
|
|
|
_display = XOpenDisplay(nullptr);
|
|
|
|
_screen = DefaultScreen(_display);
|
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
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
XWindowAttributes attributes{};
|
|
|
|
XGetWindowAttributes(_display, RootWindow(_display, _screen), &attributes);
|
|
|
|
_depth = attributes.depth;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto destruct() -> void {
|
|
|
|
terminate();
|
|
|
|
|
|
|
|
if(_display) {
|
|
|
|
XCloseDisplay(_display);
|
|
|
|
_display = nullptr;
|
|
|
|
_screen = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto initialize() -> bool {
|
|
|
|
terminate();
|
|
|
|
if(!self.exclusive && !self.context) return false;
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
//require GLX 1.2+ API
|
2017-07-24 05:23:40 +00:00
|
|
|
glXQueryVersion(_display, &_versionMajor, &_versionMinor);
|
|
|
|
if(_versionMajor < 1 || (_versionMajor == 1 && _versionMinor < 2)) return false;
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2018-08-05 09:00:15 +00:00
|
|
|
int redDepth = VideoDriver::format == "RGB30" ? 10 : 8;
|
|
|
|
int greenDepth = VideoDriver::format == "RGB30" ? 10 : 8;
|
|
|
|
int blueDepth = VideoDriver::format == "RGB30" ? 10 : 8;
|
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
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
//let GLX determine the best Visual to use for GL output; provide a few hints
|
|
|
|
//note: some video drivers will override double buffering attribute
|
2017-07-24 05:23:40 +00:00
|
|
|
int attributeList[] = {
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT,
|
|
|
|
GLX_RENDER_TYPE, GLX_RGBA_BIT,
|
|
|
|
GLX_DOUBLEBUFFER, 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
|
|
|
GLX_RED_SIZE, redDepth,
|
|
|
|
GLX_GREEN_SIZE, greenDepth,
|
|
|
|
GLX_BLUE_SIZE, blueDepth,
|
2013-07-29 09:42:45 +00:00
|
|
|
None
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
};
|
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
int fbCount = 0;
|
|
|
|
GLXFBConfig* fbConfig = glXChooseFBConfig(_display, _screen, attributeList, &fbCount);
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
if(fbCount == 0) return false;
|
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
auto visual = glXGetVisualFromFBConfig(_display, fbConfig[0]);
|
|
|
|
|
|
|
|
_parent = self.exclusive ? RootWindow(_display, visual->screen) : (Window)self.context;
|
|
|
|
XWindowAttributes windowAttributes;
|
|
|
|
XGetWindowAttributes(_display, _parent, &windowAttributes);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2018-08-05 09:00:15 +00:00
|
|
|
//(Window)self.context has already been realized, most likely with DefaultVisual.
|
2010-08-09 13:28:56 +00:00
|
|
|
//GLX requires that the GL output window has the same Visual as the GLX context.
|
|
|
|
//it is not possible to change the Visual of an already realized (created) window.
|
2017-07-24 05:23:40 +00:00
|
|
|
//therefore a new child window, using the same GLX Visual, must be created and binded to it.
|
2019-07-07 09:44:09 +00:00
|
|
|
_colormap = XCreateColormap(_display, RootWindow(_display, visual->screen), visual->visual, AllocNone);
|
|
|
|
XSetWindowAttributes attributes{};
|
2010-08-09 13:28:56 +00:00
|
|
|
attributes.border_pixel = 0;
|
2019-07-07 09:44:09 +00:00
|
|
|
attributes.colormap = _colormap;
|
|
|
|
attributes.override_redirect = self.exclusive;
|
|
|
|
_window = XCreateWindow(_display, _parent,
|
|
|
|
0, 0, windowAttributes.width, windowAttributes.height,
|
|
|
|
0, visual->depth, InputOutput, visual->visual,
|
|
|
|
CWBorderPixel | CWColormap | CWOverrideRedirect, &attributes);
|
2018-06-10 08:07:19 +00:00
|
|
|
XSelectInput(_display, _window, ExposureMask);
|
2019-07-07 09:44:09 +00:00
|
|
|
XSetWindowBackground(_display, _window, 0);
|
2017-07-24 05:23:40 +00:00
|
|
|
XMapWindow(_display, _window);
|
|
|
|
XFlush(_display);
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
//window must be realized (appear onscreen) before we make the context current
|
2017-07-24 05:23:40 +00:00
|
|
|
while(XPending(_display)) {
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
XEvent event;
|
2017-07-24 05:23:40 +00:00
|
|
|
XNextEvent(_display, &event);
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2019-07-07 09:44:09 +00:00
|
|
|
_glXContext = glXCreateContext(_display, visual, 0, GL_TRUE);
|
2017-07-24 05:23:40 +00:00
|
|
|
glXMakeCurrent(_display, _glXWindow = _window, _glXContext);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-11-08 08:54:42 +00:00
|
|
|
//glXSwapInterval is used to toggle Vsync
|
|
|
|
//note that the ordering is very important! MESA declares SGI, but the SGI function does nothing
|
2017-07-24 05:23:40 +00:00
|
|
|
if(!glXSwapInterval) glXSwapInterval = (int (*)(int))glGetProcAddress("glXSwapIntervalMESA");
|
|
|
|
if(!glXSwapInterval) glXSwapInterval = (int (*)(int))glGetProcAddress("glXSwapIntervalSGI");
|
2013-07-29 09:42:45 +00:00
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
if(auto glXCreateContextAttribs = (auto (*)(Display*, GLXFBConfig, GLXContext, int, const int*) -> GLXContext)glGetProcAddress("glXCreateContextAttribsARB")) {
|
|
|
|
int attributes[] = {
|
2013-07-29 09:42:45 +00:00
|
|
|
GLX_CONTEXT_MAJOR_VERSION_ARB, 3,
|
|
|
|
GLX_CONTEXT_MINOR_VERSION_ARB, 2,
|
|
|
|
None
|
|
|
|
};
|
2015-11-08 08:54:42 +00:00
|
|
|
|
|
|
|
//glXCreateContextAttribs tends to throw BadRequest errors instead of simply failing gracefully
|
|
|
|
auto originalHandler = XSetErrorHandler(VideoGLX_X11ErrorHandler);
|
2017-07-24 05:23:40 +00:00
|
|
|
auto context = glXCreateContextAttribs(_display, fbConfig[0], nullptr, true, attributes);
|
|
|
|
XSync(_display, False);
|
2015-11-08 08:54:42 +00:00
|
|
|
XSetErrorHandler(originalHandler);
|
|
|
|
|
2013-07-29 09:42:45 +00:00
|
|
|
if(context) {
|
2017-07-24 05:23:40 +00:00
|
|
|
glXMakeCurrent(_display, 0, nullptr);
|
|
|
|
glXDestroyContext(_display, _glXContext);
|
|
|
|
glXMakeCurrent(_display, _glXWindow, _glXContext = context);
|
2015-11-08 08:54:42 +00:00
|
|
|
} else {
|
|
|
|
//OpenGL 3.2+ not supported (most likely OpenGL 2.x)
|
|
|
|
return false;
|
2013-07-29 09:42:45 +00:00
|
|
|
}
|
2015-11-08 08:54:42 +00:00
|
|
|
} else {
|
|
|
|
//missing required glXCreateContextAtribs function
|
|
|
|
return false;
|
2013-07-29 09:42:45 +00:00
|
|
|
}
|
|
|
|
|
2018-08-05 09:00:15 +00:00
|
|
|
if(glXSwapInterval) glXSwapInterval(self.blocking);
|
2013-07-29 09:42:45 +00:00
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
//read attributes of frame buffer for later use, as requested attributes from above are not always granted
|
2017-07-24 05:23:40 +00:00
|
|
|
int value = 0;
|
2019-07-07 09:44:09 +00:00
|
|
|
glXGetConfig(_display, visual, GLX_DOUBLEBUFFER, &value);
|
2017-07-24 05:23:40 +00:00
|
|
|
_doubleBuffer = value;
|
|
|
|
_isDirect = glXIsDirect(_display, _glXContext);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2018-08-21 03:17:12 +00:00
|
|
|
return _ready = OpenGL::initialize(self.shader);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
auto terminate() -> void {
|
|
|
|
_ready = false;
|
|
|
|
OpenGL::terminate();
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
if(_glXContext) {
|
|
|
|
glXDestroyContext(_display, _glXContext);
|
|
|
|
_glXContext = nullptr;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
if(_window) {
|
|
|
|
XUnmapWindow(_display, _window);
|
|
|
|
_window = 0;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2017-07-24 05:23:40 +00:00
|
|
|
if(_colormap) {
|
|
|
|
XFreeColormap(_display, _colormap);
|
|
|
|
_colormap = 0;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2012-03-10 12:37:36 +00:00
|
|
|
}
|
2017-07-24 05:23:40 +00:00
|
|
|
|
|
|
|
bool _ready = false;
|
|
|
|
|
|
|
|
auto (*glXSwapInterval)(int) -> int = nullptr;
|
|
|
|
|
|
|
|
Display* _display = nullptr;
|
|
|
|
int _screen = 0;
|
2019-07-07 09:44:09 +00:00
|
|
|
uint _depth = 24; //depth of the default root window
|
|
|
|
Window _parent = 0;
|
2017-07-24 05:23:40 +00:00
|
|
|
Window _window = 0;
|
|
|
|
Colormap _colormap = 0;
|
|
|
|
GLXContext _glXContext = nullptr;
|
|
|
|
GLXWindow _glXWindow = 0;
|
|
|
|
|
|
|
|
int _versionMajor = 0;
|
|
|
|
int _versionMinor = 0;
|
|
|
|
bool _doubleBuffer = false;
|
|
|
|
bool _isDirect = false;
|
2010-08-09 13:28:56 +00:00
|
|
|
};
|