bsnes/ruby/video/xvideo.cpp

556 lines
18 KiB
C++
Raw Normal View History

#include <sys/ipc.h>
#include <sys/shm.h>
#include <X11/extensions/XShm.h>
#include <X11/extensions/Xv.h>
#include <X11/extensions/Xvlib.h>
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
extern "C" auto XvShmCreateImage(Display*, XvPortID, int, char*, int, int, XShmSegmentInfo*) -> XvImage*;
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
struct VideoXVideo : Video {
VideoXVideo() { initialize(); }
~VideoXVideo() { terminate(); }
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto ready() -> bool { return _ready; }
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto context() -> uintptr { return _context; }
auto blocking() -> bool { return _blocking; }
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto setContext(uintptr context) -> bool {
if(_context == context) return true;
_context = context;
return initialize();
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto setBlocking(bool blocking) -> bool {
if(_blocking == blocking) return true;
_blocking = blocking;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
bool result = false;
Display* display = XOpenDisplay(nullptr);
Atom atom = XInternAtom(display, "XV_SYNC_TO_VBLANK", true);
if(atom != None && _port >= 0) {
XvSetPortAttribute(display, _port, atom, _blocking);
result = true;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XCloseDisplay(display);
return result;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto clear() -> void {
if(!ready()) return;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
memory::fill(_buffer, _bufferWidth * _bufferHeight * sizeof(uint32_t));
//clear twice in case video is double buffered ...
output();
output();
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
if(!ready()) return false;
if(width != _width || height != _height) resize(_width = width, _height = height);
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
pitch = _bufferWidth * 4;
return data = _buffer;
}
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 unlock() -> void {
if(!ready()) return;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto output() -> void {
if(!ready()) return;
XWindowAttributes target;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XGetWindowAttributes(_display, _window, &target);
//we must ensure that the child window is the same size as the parent window.
//unfortunately, we cannot hook the parent window resize event notification,
//as we did not create the parent window, nor have any knowledge of the toolkit used.
//therefore, query each window size and resize as needed.
XWindowAttributes parent;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XGetWindowAttributes(_display, (Window)_context, &parent);
if(target.width != parent.width || target.height != parent.height) {
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XResizeWindow(_display, _window, parent.width, parent.height);
}
//update target width and height attributes
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XGetWindowAttributes(_display, _window, &target);
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
switch(_format) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
case XvFormatRGB32: renderRGB32(_width, _height); break;
case XvFormatRGB24: renderRGB24(_width, _height); break;
case XvFormatRGB16: renderRGB16(_width, _height); break;
case XvFormatRGB15: renderRGB15(_width, _height); break;
case XvFormatUYVY: renderUYVY (_width, _height); break;
case XvFormatYUY2: renderYUY2 (_width, _height); break;
case XvFormatYV12: renderYV12 (_width, _height); break;
case XvFormatI420: renderI420 (_width, _height); break;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XvShmPutImage(_display, _port, _window, _gc, _image,
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
0, 0, _width, _height,
0, 0, target.width, target.height,
true);
}
private:
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto initialize() -> bool {
terminate();
if(!_context) return false;
_display = XOpenDisplay(nullptr);
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(!XShmQueryExtension(_display)) {
print("VideoXv: XShm extension not found.\n");
return false;
}
//find an appropriate Xv port
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_port = -1;
XvAdaptorInfo* adaptorInfo = nullptr;
uint adaptorCount = 0;
XvQueryAdaptors(_display, DefaultRootWindow(_display), &adaptorCount, &adaptorInfo);
for(uint n : range(adaptorCount)) {
//find adaptor that supports both input (memory->drawable) and image (drawable->screen) masks
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(adaptorInfo[n].num_formats < 1) continue;
if(!(adaptorInfo[n].type & XvInputMask)) continue;
if(!(adaptorInfo[n].type & XvImageMask)) continue;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_port = adaptorInfo[n].base_id;
_depth = adaptorInfo[n].formats->depth;
_visualID = adaptorInfo[n].formats->visual_id;
break;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XvFreeAdaptorInfo(adaptorInfo);
if(_port < 0) {
print("VideoXv: failed to find valid XvPort.\n");
return false;
}
//create child window to attach to parent window.
//this is so that even if parent window visual depth doesn't match Xv visual
//(common with composited windows), Xv can still render to child window.
XWindowAttributes window_attributes;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XGetWindowAttributes(_display, (Window)_context, &window_attributes);
XVisualInfo visualTemplate;
visualTemplate.visualid = _visualID;
visualTemplate.screen = DefaultScreen(_display);
visualTemplate.depth = _depth;
visualTemplate.visual = 0;
int visualMatches = 0;
XVisualInfo* visualInfo = XGetVisualInfo(_display, VisualIDMask | VisualScreenMask | VisualDepthMask, &visualTemplate, &visualMatches);
if(visualMatches < 1 || !visualInfo->visual) {
if(visualInfo) XFree(visualInfo);
print("VideoXv: unable to find Xv-compatible visual.\n");
return false;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_colormap = XCreateColormap(_display, (Window)_context, visualInfo->visual, AllocNone);
XSetWindowAttributes attributes;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
attributes.colormap = _colormap;
attributes.border_pixel = 0;
attributes.event_mask = StructureNotifyMask;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_window = XCreateWindow(_display, /* parent = */ (Window)_context,
/* x = */ 0, /* y = */ 0, window_attributes.width, window_attributes.height,
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
/* border_width = */ 0, _depth, InputOutput, visualInfo->visual,
CWColormap | CWBorderPixel | CWEventMask, &attributes);
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XFree(visualInfo);
XSetWindowBackground(_display, _window, /* color = */ 0);
XMapWindow(_display, _window);
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_gc = XCreateGC(_display, _window, 0, 0);
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
int attributeCount = 0;
XvAttribute* attributeList = XvQueryPortAttributes(_display, _port, &attributeCount);
for(auto n : range(attributeCount)) {
if(string{attributeList[n].name} == "XV_AUTOPAINT_COLORKEY") {
//set colorkey to auto paint, so that Xv video output is always visible
Atom atom = XInternAtom(_display, "XV_AUTOPAINT_COLORKEY", true);
if(atom != None) XvSetPortAttribute(_display, _port, atom, 1);
}
}
XFree(attributeList);
//find optimal rendering format
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_format = XvFormatUnknown;
int formatCount = 0;
XvImageFormatValues* format = XvListImageFormats(_display, _port, &formatCount);
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvRGB && format[n].bits_per_pixel == 32) {
_format = XvFormatRGB32;
_fourCC = format[n].id;
break;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvRGB && format[n].bits_per_pixel == 24) {
_format = XvFormatRGB24;
_fourCC = format[n].id;
break;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvRGB && format[n].bits_per_pixel <= 16 && format[n].red_mask == 0xf800) {
_format = XvFormatRGB16;
_fourCC = format[n].id;
break;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvRGB && format[n].bits_per_pixel <= 16 && format[n].red_mask == 0x7c00) {
_format = XvFormatRGB15;
_fourCC = format[n].id;
break;
}
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvYUV && format[n].bits_per_pixel == 16 && format[n].format == XvPacked) {
if(format[n].component_order[0] == 'U' && format[n].component_order[1] == 'Y'
&& format[n].component_order[2] == 'V' && format[n].component_order[3] == 'Y'
) {
_format = XvFormatUYVY;
_fourCC = format[n].id;
break;
}
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvYUV && format[n].bits_per_pixel == 16 && format[n].format == XvPacked) {
if(format[n].component_order[0] == 'Y' && format[n].component_order[1] == 'U'
&& format[n].component_order[2] == 'Y' && format[n].component_order[3] == 'V'
) {
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_format = XvFormatYUY2;
_fourCC = format[n].id;
break;
}
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
if(format[n].type == XvYUV && format[n].bits_per_pixel == 12 && format[n].format == XvPlanar) {
if(format[n].component_order[0] == 'Y' && format[n].component_order[1] == 'V'
&& format[n].component_order[2] == 'U' && format[n].component_order[3] == '\x00'
) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
_format = XvFormatYV12;
_fourCC = format[n].id;
break;
}
}
}
if(_format == XvFormatUnknown) for(auto n : range(formatCount)) {
if(format[n].type == XvYUV && format[n].bits_per_pixel == 12 && format[n].format == XvPlanar) {
if(format[n].component_order[0] == 'Y' && format[n].component_order[1] == 'U'
&& format[n].component_order[2] == 'V' && format[n].component_order[3] == '\x00'
) {
_format = XvFormatI420;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_fourCC = format[n].id;
break;
}
}
}
free(format);
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_format == XvFormatUnknown) {
print("VideoXv: unable to find a supported image format.\n");
return false;
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
_ready = true;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
initializeTables();
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
resize(_width = 256, _height = 256);
clear();
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
return true;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto terminate() -> void {
_ready = false;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_image) {
XShmDetach(_display, &_shmInfo);
shmdt(_shmInfo.shmaddr);
shmctl(_shmInfo.shmid, IPC_RMID, nullptr);
XFree(_image);
_image = nullptr;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_window) {
XUnmapWindow(_display, _window);
_window = 0;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_colormap) {
XFreeColormap(_display, _colormap);
_colormap = 0;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
if(_display) {
XCloseDisplay(_display);
_display = nullptr;
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
delete[] _buffer, _buffer = nullptr, _bufferWidth = 0, _bufferHeight = 0;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
delete[] _ytable, _ytable = nullptr;
delete[] _utable, _utable = nullptr;
delete[] _vtable, _vtable = nullptr;
}
auto resize(uint width, uint height) -> void {
if(_bufferWidth >= width && _bufferHeight >= height) return;
_bufferWidth = max(width, _bufferWidth);
_bufferHeight = max(height, _bufferHeight);
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
//must round to be evenly divisible by 4
if(uint round = _bufferWidth & 3) _bufferWidth += 4 - round;
if(uint round = _bufferHeight & 3) _bufferHeight += 4 - round;
_bufferWidth = bit::round(_bufferWidth);
_bufferHeight = bit::round(_bufferHeight);
if(_image) {
XShmDetach(_display, &_shmInfo);
shmdt(_shmInfo.shmaddr);
shmctl(_shmInfo.shmid, IPC_RMID, nullptr);
XFree(_image);
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_image = XvShmCreateImage(_display, _port, _fourCC, 0, _bufferWidth, _bufferHeight, &_shmInfo);
_shmInfo.shmid = shmget(IPC_PRIVATE, _image->data_size, IPC_CREAT | 0777);
_shmInfo.shmaddr = _image->data = (char*)shmat(_shmInfo.shmid, 0, 0);
_shmInfo.readOnly = false;
XShmAttach(_display, &_shmInfo);
delete[] _buffer;
_buffer = new uint32_t[_bufferWidth * _bufferHeight];
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto renderRGB32(uint width, uint height) -> void {
uint32_t* input = (uint32_t*)_buffer;
uint32_t* output = (uint32_t*)_image->data;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint y : range(height)) {
memory::copy(output, input, width * 4);
input += _bufferWidth;
output += _bufferWidth;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto renderRGB24(uint width, uint height) -> void {
uint32_t* input = (uint32_t*)_buffer;
uint8_t* output = (uint8_t*)_image->data;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint y : range(height)) {
for(uint x : range(width)) {
uint32_t p = *input++;
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
*output++ = p >> 0;
*output++ = p >> 8;
*output++ = p >> 16;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
input += (_bufferWidth - width);
output += (_bufferWidth - width) * 3;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto renderRGB16(uint width, uint height) -> void {
uint32_t* input = (uint32_t*)_buffer;
uint16_t* output = (uint16_t*)_image->data;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint y : range(height)) {
for(uint x : range(width)) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
uint32_t p = toRGB16(*input++);
*output++ = p;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
input += _bufferWidth - width;
output += _bufferWidth - width;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto renderRGB15(uint width, uint height) -> void {
uint32_t* input = (uint32_t*)_buffer;
uint16_t* output = (uint16_t*)_image->data;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint y : range(height)) {
for(uint x : range(width)) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
uint32_t p = toRGB15(*input++);
*output++ = p;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
input += _bufferWidth - width;
output += _bufferWidth - width;
}
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
auto renderUYVY(uint width, uint height) -> void {
const uint32_t* input = (const uint32_t*)_buffer;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
uint16_t* output = (uint16_t*)_image->data;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint y : range(height)) {
for(uint x : range(width >> 1)) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
uint32_t p0 = toRGB16(*input++);
uint32_t p1 = toRGB16(*input++);
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
*output++ = _ytable[p0] << 8 | ((_utable[p0] + _utable[p1]) >> 1) << 0;
*output++ = _ytable[p1] << 8 | ((_vtable[p0] + _vtable[p1]) >> 1) << 0;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
input += _bufferWidth - width;
output += _bufferWidth - width;
}
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
auto renderYUY2(uint width, uint height) -> void {
const uint32_t* input = (const uint32_t*)_buffer;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
uint16_t* output = (uint16_t*)_image->data;
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint y : range(height)) {
for(uint x : range(width >> 1)) {
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
uint32_t p0 = toRGB16(*input++);
uint32_t p1 = toRGB16(*input++);
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
*output++ = ((_utable[p0] + _utable[p1]) >> 1) << 8 | _ytable[p0] << 0;
*output++ = ((_vtable[p0] + _vtable[p1]) >> 1) << 8 | _ytable[p1] << 0;
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
input += _bufferWidth - width;
output += _bufferWidth - width;
}
}
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
auto renderYV12(uint width, uint height) -> void {
const uint w = _bufferWidth, h = _bufferHeight;
for(uint y : range(height >> 1)) {
const uint32_t* input0 = (const uint32_t*)_buffer + (2 * y * w);
const uint32_t* input1 = input0 + w;
uint16_t* youtput0 = (uint16_t*)_image->data + ((2 * y * w) >> 1);
uint16_t* youtput1 = youtput0 + (w >> 1);
uint8_t* voutput = (uint8_t*)_image->data + (w * h) + ((2 * y * w) >> 2);
uint8_t* uoutput = (uint8_t*)_image->data + (w * h) + ((w * h) >> 2) + ((2 * y * w) >> 2);
for(uint x : range(width >> 1)) {
uint16_t p0 = toRGB16(*input0++);
uint16_t p1 = toRGB16(*input0++);
uint16_t p2 = toRGB16(*input1++);
uint16_t p3 = toRGB16(*input1++);
*youtput0++ = _ytable[p0] << 0 | _ytable[p1] << 8;
*youtput1++ = _ytable[p2] << 0 | _ytable[p3] << 8;
*voutput++ = (_vtable[p0] + _vtable[p1] + _vtable[p2] + _vtable[p3]) >> 2;
*uoutput++ = (_utable[p0] + _utable[p1] + _utable[p2] + _utable[p3]) >> 2;
}
}
}
auto renderI420(uint width, uint height) -> void {
const uint w = _bufferWidth, h = _bufferHeight;
for(uint y : range(height >> 1)) {
const uint32_t* input0 = (const uint32_t*)_buffer + (2 * y * w);
const uint32_t* input1 = input0 + w;
uint16_t* youtput0 = (uint16_t*)_image->data + ((2 * y * w) >> 1);
uint16_t* youtput1 = youtput0 + (w >> 1);
uint8_t* uoutput = (uint8_t*)_image->data + (w * h) + ((2 * y * w) >> 2);
uint8_t* voutput = (uint8_t*)_image->data + (w * h) + ((w * h) >> 2) + ((2 * y * w) >> 2);
for(uint x : range(width >> 1)) {
uint16_t p0 = toRGB16(*input0++);
uint16_t p1 = toRGB16(*input0++);
uint16_t p2 = toRGB16(*input1++);
uint16_t p3 = toRGB16(*input1++);
*youtput0++ = _ytable[p0] << 0 | _ytable[p1] << 8;
*youtput1++ = _ytable[p2] << 0 | _ytable[p3] << 8;
*uoutput++ = (_utable[p0] + _utable[p1] + _utable[p2] + _utable[p3]) >> 2;
*voutput++ = (_vtable[p0] + _vtable[p1] + _vtable[p2] + _vtable[p3]) >> 2;
}
}
}
inline auto toRGB15(uint32_t rgb32) const -> uint16_t {
return ((rgb32 >> 9) & 0x7c00) + ((rgb32 >> 6) & 0x03e0) + ((rgb32 >> 3) & 0x001f);
}
inline auto toRGB16(uint32_t rgb32) const -> uint16_t {
return ((rgb32 >> 8) & 0xf800) + ((rgb32 >> 5) & 0x07e0) + ((rgb32 >> 3) & 0x001f);
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
auto initializeTables() -> void {
_ytable = new uint8_t[65536];
_utable = new uint8_t[65536];
_vtable = new uint8_t[65536];
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
for(uint n : range(65536)) {
//extract RGB565 color data from i
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
uint8_t r = (n >> 11) & 31, g = (n >> 5) & 63, b = (n) & 31;
r = (r << 3) | (r >> 2); //R5->R8
g = (g << 2) | (g >> 4); //G6->G8
b = (b << 3) | (b >> 2); //B5->B8
//ITU-R Recommendation BT.601
//double lr = 0.299, lg = 0.587, lb = 0.114;
int y = int( +(double(r) * 0.257) + (double(g) * 0.504) + (double(b) * 0.098) + 16.0 );
int u = int( -(double(r) * 0.148) - (double(g) * 0.291) + (double(b) * 0.439) + 128.0 );
int v = int( +(double(r) * 0.439) - (double(g) * 0.368) - (double(b) * 0.071) + 128.0 );
//ITU-R Recommendation BT.709
//double lr = 0.2126, lg = 0.7152, lb = 0.0722;
//int y = int( double(r) * lr + double(g) * lg + double(b) * lb );
//int u = int( (double(b) - y) / (2.0 - 2.0 * lb) + 128.0 );
//int v = int( (double(r) - y) / (2.0 - 2.0 * lr) + 128.0 );
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
_ytable[n] = y < 0 ? 0 : y > 255 ? 255 : y;
_utable[n] = u < 0 ? 0 : u > 255 ? 255 : u;
_vtable[n] = v < 0 ? 0 : v > 255 ? 255 : v;
}
}
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
bool _ready = false;
uintptr _context = 0;
bool _blocking = false;
uint _width = 0;
uint _height = 0;
uint32_t* _buffer = nullptr;
uint _bufferWidth = 0;
uint _bufferHeight = 0;
uint8_t* _ytable = nullptr;
uint8_t* _utable = nullptr;
uint8_t* _vtable = nullptr;
enum XvFormat : uint {
XvFormatRGB32,
XvFormatRGB24,
XvFormatRGB16,
XvFormatRGB15,
XvFormatUYVY,
Update to v103r19 release. byuu says: Changelog: - tomoko: Application::onMain assigned at end of Program::Program() [Screwtape]¹ - libco: add `#define _XOPEN_SOURCE 500` to fix compilation of sjlj.c [Screwtape] - ruby/audio/openal: fixed device driver string list enumeration - ruby/audio/wasapi: changing device re-initializes the driver now - ruby/audio/wasapi: probably a pointless change, but don't fill the buffer beyond the queue size with silence - ruby/video/xvideo: renamed from ruby/video/xv - ruby/video/xvideo: check to see if `XV_AUTOPAINT_COLORKEY` exists before setting it [SuperMikeMan] - ruby/video/xvideo: align buffer sizes to be evenly divisible by four [SuperMikeMan] - ruby/video/xvideo: fail nicely without crashing (hopefully) - ruby/video/xvideo: add support for YV12 and I420 12-bit planar YUV formats² ¹: prevents crashes when drivers fail to initialize from running the main loop that polls input drivers before the input driver is initialized (or fails to initialize itself.) Some drivers still don't block their main functions when initialization fails, so they will still crash, but I'll work to fix them. ²: this was a **major** pain in the ass, heh. You only get one chroma sample for every four luma samples, so the color reproduction is even worse than UYVY and YUYV (which is two to four chroma to luma.) Further, the planar format took forever to figure out. Apparently it doesn't care what portion of the image you specify in XvShmPutImage, it expects you to use the buffer dimensions to locate the U and V portions of the data. This is probably the most thorough X-Video driver in existence now. Notes: - forgot to rename the configuration settings dialog window title to just "Settings"
2017-07-23 09:18:16 +00:00
XvFormatYUY2,
XvFormatYV12,
XvFormatI420,
Update to v103r18 release. byuu says: Changelog: - tomoko: improved handling of changing audio devices on the audio settings panel - ruby/audio/wasapi: added device enumeration and selection support¹ - ruby/audio/wasapi: release property store handle from audio device - ruby/audio/wasapi: fix exclusive mode buffer filling - ruby/video/glx2: ported to new API -- tested and confirmed working great² - ruby/video/sdl: fixed initialization -- tested and confirmed working on FreeBSD now³ - ruby/video/xv: ported to new API -- tested and mostly working great, sans fullscreen mode⁴ Errata: - accidentally changed "Driver Settings" label to "Driver" on the audio settings tab because I deleted the line and forgot the "Settings" part - need to use "return initialize();" from setDevice() in the WASAPI driver, instead of "return true;", so device selection is currently not functioning in this WIP for said driver ¹: for now, this will likely end up selecting the first available endpoint device, which is probably wrong. I need to come up with a system to expose good 'default values' when selecting new audio drivers, or changing audio device settings. ²: glx2 is a fallback driver for system with only OpenGL 2.0 and no OpenGL 3.2 drivers, such as FreeBSD 10.1 with AMD graphics cards. ³: although I really should track down why InputManager::poll() is crashing the emulator when Video::ready() returns false ... ⁴: really bizarrely, when entering fullscreen mode, it looks like the image was a triangle strip, and the bottom right triange is missing, and the top left triangle skews the entire image into it. I'm suspecting this is a Radeon driver bug when trying to create a 2560x1600 X-Video surface. The glitch persists when exiting fullscreen, too. If anyone can test the X-Video driver on their Linux/BSD system, it'd be appreciated. If it's just my video card, I'll ignore it. If not, hopefully someone can find the cause of the issue :|
2017-07-20 11:52:47 +00:00
XvFormatUnknown,
};
Display* _display = nullptr;
GC _gc = 0;
Window _window = 0;
Colormap _colormap = 0;
XShmSegmentInfo _shmInfo;
int _port = -1;
int _depth = 0;
int _visualID = 0;
XvImage* _image = nullptr;
XvFormat _format = XvFormatUnknown;
uint32_t _fourCC = 0;
};