bsnes/ruby/video/sdl.cpp

133 lines
3.6 KiB
C++
Raw Normal View History

#include <sys/ipc.h>
#include <sys/shm.h>
#include <X11/extensions/Xv.h>
#include <X11/extensions/Xvlib.h>
#include <X11/extensions/XShm.h>
#include <SDL/SDL.h>
struct VideoSDL : Video {
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
VideoSDL() { initialize(); }
~VideoSDL() { terminate(); }
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto ready() -> bool { return _ready; }
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto context() -> uintptr { return _context; }
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto setContext(uintptr context) -> bool {
if(_context == context) return true;
_context = context;
return initialize();
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto clear() -> void {
if(!ready()) return;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(SDL_MUSTLOCK(_buffer)) SDL_LockSurface(_buffer);
for(uint y : range(_bufferHeight)) {
uint32_t* data = (uint32_t*)_buffer->pixels + y * (_buffer->pitch >> 2);
for(uint x : range(_bufferWidth)) *data++ = 0xff000000;
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(SDL_MUSTLOCK(_buffer)) SDL_UnlockSurface(_buffer);
output();
}
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 v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(SDL_MUSTLOCK(_buffer)) SDL_LockSurface(_buffer);
pitch = _buffer->pitch;
return data = (uint32_t*)_buffer->pixels;
}
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 v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(SDL_MUSTLOCK(_buffer)) SDL_UnlockSurface(_buffer);
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto output() -> void {
if(!ready()) return;
//ruby input is X8R8G8B8, top 8-bits are ignored.
//as SDL forces us to use a 32-bit buffer, we must set alpha to 255 (full opacity)
//to prevent blending against the window beneath when X window visual is 32-bits.
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(SDL_MUSTLOCK(_buffer)) SDL_LockSurface(_buffer);
for(uint y : range(_height)) {
uint32_t* data = (uint32_t*)_buffer->pixels + y * (_buffer->pitch >> 2);
for(uint x : range(_width)) *data++ |= 0xff000000;
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(SDL_MUSTLOCK(_buffer)) SDL_UnlockSurface(_buffer);
XWindowAttributes attributes;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
XGetWindowAttributes(_display, _context, &attributes);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
SDL_Rect source;
SDL_Rect target;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
source.x = 0;
source.y = 0;
source.w = _width;
source.h = _height;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
target.x = 0;
target.y = 0;
target.w = attributes.width;
target.h = attributes.height;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
SDL_SoftStretch(_buffer, &source, _screen, &target);
SDL_UpdateRect(_screen, target.x, target.y, target.w, target.h);
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
private:
auto initialize() -> bool {
terminate();
if(!_context) return false;
_display = XOpenDisplay(0);
char env[512];
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
sprintf(env, "SDL_WINDOWID=%ld", (long)_context);
putenv(env);
SDL_InitSubSystem(SDL_INIT_VIDEO);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
_screen = SDL_SetVideoMode(2560, 1600, 32, SDL_HWSURFACE);
XUndefineCursor(_display, _context);
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
_buffer = nullptr;
_bufferWidth = 0;
_bufferHeight = 0;
resize(_width = 256, _height = 256);
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
return _ready = true;
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto terminate() -> void {
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
_ready = false;
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
if(_buffer) SDL_FreeSurface(_buffer), _buffer = nullptr;
if(_screen) SDL_QuitSubSystem(SDL_INIT_VIDEO), _screen = nullptr;
if(_display) XCloseDisplay(_display), _display = nullptr;
}
Update to v103r17 release. byuu says: Changelog: - tomoko: re-hid the video sync option¹ - tomoko: removed " Settings" duplication on all the individual settings tab options - ruby/audio/wasapi: finished port to new syntax; adapted to an event-driven model; support 32-bit integral audio² - ruby/video/sdl: ported to new syntax; disabled driver on FreeBSD³ ¹: still contemplating a synchronize submenu of {none, video, audio}, but ... the fact that video can't work on PAL, WonderSwan games is a real limitation for it ²: this driver actually received a ton of work. There's also a new ring-buffer queue, and I added special handling for when exclusive mode fails because the latency requested is lower than the hardware can support. It'll pick the closest latency to the minimum that is possible in this case. On my Audigy Rx, the results for non-exclusive mode are the same. For exclusive mode, the framerate drops from 60fps to ~50fps for smaller buffers, and ~55fps for larger buffers (no matter how big, it never hits 60fps.) This is a lot better than before where it was hitting ~15fps, but unfortunately it's the best I can do. The event system used by WASAPI is really stupid. It just uses SetEvent at some arbitrary time, and you have to query to see how many samples it's waiting on. This makes it unknowable how many samples we should buffer before calling `WaitForSingleObject(INFINITE)`, and it's also unclear how we should handle cases where there's more samples available than our queue has: either we can fill it with zeroes, or we can write less samples. The former should prevent audio looping effects when running too slowly, whereas the latter could potentially be too ambitious when the audio could've recovered from a minor stall. It's shocking to me how there's as many ways to send audio to a sound card as there are sound card APIs, when all that's needed is a simple double buffer and a callback event from another thread to do it right. It's also terrifying how unbelievably shitty nearly all sound card drivers apparently are. Also, I don't know if cards can output an actual 24-bit mode with three byte audio samples, or if they always just take 32-bit samples and ignore the lower 8-bits. Whatever, it's all nonsense for the final output to be >16-bits anyway (hi, `double[]` input from ruby.) ³: unfortunately, this driver always crashes on FreeBSD (even before the rewrite), so I'll need someone on Linux to test it and make sure it actually works. I'll also need testing for a lot of the other drivers as well, once they're ported over (I don't have X-video, PulseAudio, ALSA, or udev.) Note that I forgot to set `_ready=true` at the end of `initialize()`, and `_ready=false` in `terminate()`, but it shouldn't actually matter beyond showing you a false warning message on startup about it failing to initialize.
2017-07-19 13:14:00 +00:00
auto resize(uint width, uint height) -> void {
if(_bufferWidth >= width && _bufferHeight >= height) return;
_bufferWidth = max(width, _bufferWidth);
_bufferHeight = max(height, _bufferHeight);
if(_buffer) SDL_FreeSurface(_buffer);
_buffer = SDL_CreateRGBSurface(
SDL_SWSURFACE, _bufferWidth, _bufferHeight, 32,
0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
);
}
bool _ready = false;
uintptr _context = 0;
Display* _display = nullptr;
SDL_Surface* _screen = nullptr;
SDL_Surface* _buffer = nullptr;
uint _bufferWidth = 0;
uint _bufferHeight = 0;
uint _width = 0;
uint _height = 0;
};