mirror of https://github.com/bsnes-emu/bsnes.git
9 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
e1223366a7 |
Update to v103r22 release.
byuu says:
Changelog:
- ruby: ported all remaining drivers to new API¹
- ruby/wasapi: fix for dropping one sample per period [SuperMikeMan]
- gb: emulated most of the TAMA RTC; but RTC state is still volatile²
¹: the new ports are:
- audio/{directsound, alsa, pulseaudio, pulseaudiosimple, ao}
- input/{udev, quartz, carbon}
It's pretty much guaranteed many of them will have compilation errors.
Please paste the error logs and I'll try to fix them up. It may take a
WIP or two to get there.
It's also possible things broke from the updates. If so, I could use
help comparing the old file to the new file, looking for mistakes, since
I can't test on these platforms apart from audio/directsound.
Please report working drivers in this list, so we can mark them off the
list. I'll need both macOS and Linux testers.
audio/directsound.cpp:112:
if(DirectSoundCreate(0, &_interface, 0) != DS_OK) return terminate(), false;
²: once I get this working, I'll add load/save support for the RTC
values. For now, the RTC data will be lost when you close the emulator.
Right now, you can set the date/time in real-time mode, and when you
start the game, the time will be correct, and the time will tick
forward. Note that it runs off emulated time instead of actual real
time, so if you fast-forward to 300%, one minute will be 20 seconds.
The really big limitation right now is that when you exit the game, and
restart it, and resume a new game, the hour spot gets corrupted, and
this seems to instantly kill your pet. Fun. This is crazy because the
commands the game sends to the TAMA interface are identical between
starting a new game and getting in-game versus loading a game.
It's likely going to require disassembling the game's code and seeing
what in the hell it's doing, but I am extremely bad at LR35092 assembly.
Hopefully endrift can help here :|
|
|
|
Tim Allen
|
8be474b0ac |
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"
|
|
|
Tim Allen
|
284e4c043e |
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 :|
|
|
|
Tim Allen
|
0b4e7fb5a5 |
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.
|
|
|
Tim Allen
|
f87c6b7ecb |
Update to v103r16 release.
byuu says:
Changelog:
- emulator/audio: added the ability to change the output frequency at
run-time without emulator reset
- tomoko: display video synchronize option again¹
- tomoko: Settings→Configuration expanded to Settings→{Video,
Audio, Input, Hotkey, Advanced} Settings²
- tomoko: fix default population of audio settings tab
- ruby: Audio::frequency is a double now (to match both
Emulator::Audio and ASIO)³
- tomoko: changing the audio device will repopulate the frequency and
latency lists
- tomoko: changing the audio frequency can now be done in real-time
- ruby/audio/asio: added missing device() information, so devices can
be changed now
- ruby/audio/openal: ported to new API; added device selection support
- ruby/audio/wasapi: ported to new API, but did not test yet (it's
assuredly still broken)⁴
¹: I'm uneasy about this ... but, I guess if people want to disable
audio and just have smooth scrolling video ... so be it. With
Screwtape's documentation, hopefully that'll help people understand that
video synchronization always breaks audio synchronization. I may change
this to a child menu that lets you pick between {no synchronization,
video synchronization, audio synchronization} as a radio selection.
²: given how much more useful the video and audio tabs are now, I
felt that four extra menu items were worth saving a click and going
right to the tab you want. This also matches the behavior of the Tools
menu displaying all tool options and taking you directly to each tab.
This is kind of a hard change to get used to ... but I think it's for
the better.
³: kind of stupid because I've never seen a hardware sound card where
floor(frequency) != frequency, but whatever. Yay consistency.
⁴: I'm going to move it to be event-driven, and try to support 24-bit
sample formats if possible. Who knows which cards that'll fix and which
cards that'll break. I may end up making multiple WASAPI drivers so
people can find one that actually works for them. We'll see.
|
|
|
Tim Allen
|
6ae0abe3d3 |
Update to v098r09 release.
byuu says: Changelog: - fixed major nall/vector/prepend bug - renamed hiro/ListView to hiro/TableView - added new hiro/ListView control which is a simplified abstraction of hiro/TableView - updated higan's cheat database window and icarus' scan dialog to use the new ListView control - compilation works once again on all platforms (Windows, Cocoa, GTK, Qt) - the loki skeleton compiles once again (removed nall/DSP references; updated port/device ID names) Small catch: need to capture layout resize events internally in Windows to call resizeColumns. For now, just resize the icarus window to get it to use the full window width for list view items. |
|
|
Tim Allen
|
55e507d5df |
Update to v098r05 release.
byuu says:
Changelog:
- WS/WSC: re-added support for screen rotation (code is inside WS core)
- ruby: changed sample(uint16_t left, uint16_t right) to sample(int16_t
left, int16_t right);
- requires casting to uint prior to shifting in each driver, but
I felt it was misleading to use uint16_t just to avoid that
- ruby: WASAPI is now built in by default; has wareya's improvements,
and now supports latency adjust
- tomoko: audio settings panel has new "Exclusive Mode" checkbox for
WASAPI driver only
- note: although the setting *does* take effect in real-time, I'd
suggest restarting the emulator after changing it
- tomoko: audio latency can now be set to 0ms (which in reality means
"the minimum supported by the driver")
- all: increased cothread size from 512KiB to 2MiB to see if it fixes
bullshit AMD driver crashes
- this appears to cause a slight speed penalty due to cache locality
going down between threads, though
|
|
|
Tim Allen
|
19e1d89f00 |
Update to v098r01 release.
byuu says:
Changelog:
- SFC: balanced profile removed
- SFC: performance profile removed
- SFC: code for handling non-threaded CPU, SMP, DSP, PPU removed
- SFC: Coprocessor, Controller (and expansion port) shared Thread code
merged to SFC::Cothread
- Cothread here just means "Thread with CPU affinity" (couldn't think
of a better name, sorry)
- SFC: CPU now has vector<Thread*> coprocessors, peripherals;
- this is the beginning of work to allow expansion port devices to be
dynamically changed at run-time
- ruby: all audio drivers default to 48000hz instead of 22050hz now if
no frequency is assigned
- note: the WASAPI driver can default to whatever the native frequency
is; doesn't have to be 48000hz
- tomoko: removed the ability to change the frequency from the UI (but
it will display the frequency used)
- tomoko: removed the timing settings panel
- the goal is to work toward smooth video via adaptive sync
- the model is broken by not being in control of the audio frequency
anyway
- it's further broken by PAL running at 50hz and WSC running at 75hz
- it was always broken anyway by SNES interlace timing varying from
progressive timing
- higan: audio/ stub created (for now, it's just nall/dsp/ moved here
and included as a header)
- higan: video/ stub created
- higan/GNUmakefile: now includes build rules for essential components
(libco, emulator, audio, video)
The audio changes are in preparation to merge wareya's awesome WASAPI
work without the need for the nall/dsp resampler.
|
|
|
Tim Allen
|
a219f9c121 |
Update to v095r08 release.
byuu says: Changelog: - added preliminary WASAPI driver (it's really terrible, though. Patches most welcome.) - all of processor/ updated to auto fn() -> ret syntax - all of gb/ updated to auto fn() -> ret syntax If you want to test the WASAPI driver, then edit ui-tomoko/GNUmakefile, and replace audio.xaudio2 with audio.wasapi Note that the two drivers are incompatible and cannot co-exist (yet. We can probably make it work in the future.) All that's left for the auto fn() -> ret syntax is the NES core and the balanced/performance SNES components. This is kind of a big deal because this syntax change causes diffs between WIPs to go crazy. So the sooner we get this done and out of the way, the better. It's also nice from a consistency standpoint, of course. |