2015-06-12 13:14:38 +00:00
|
|
|
#if defined(Hiro_Application)
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
namespace hiro {
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
static auto Application_keyboardProc(HWND, UINT, WPARAM, LPARAM) -> bool;
|
|
|
|
static auto Application_processDialogMessage(MSG&) -> void;
|
Update to 20180809 release.
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
2018-08-10 05:02:59 +00:00
|
|
|
static auto CALLBACK Window_windowProc(HWND, UINT, WPARAM, LPARAM) -> LRESULT;
|
|
|
|
|
2020-02-23 11:23:25 +00:00
|
|
|
auto pApplication::exit() -> void {
|
|
|
|
quit();
|
|
|
|
auto processID = GetCurrentProcessId();
|
|
|
|
auto handle = OpenProcess(SYNCHRONIZE | PROCESS_TERMINATE, true, processID);
|
|
|
|
TerminateProcess(handle, 0);
|
|
|
|
}
|
|
|
|
|
Update to 20180809 release.
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
2018-08-10 05:02:59 +00:00
|
|
|
auto pApplication::modal() -> bool {
|
|
|
|
return state().modalCount > 0;
|
|
|
|
}
|
2015-06-12 13:14:38 +00:00
|
|
|
|
|
|
|
auto pApplication::run() -> void {
|
Update to bsnes v107.1 release.
byuu says:
Don't let the point release fool you, there are many significant changes in this
release. I will be keeping bsnes releases using a point system until the new
higan release is ready.
Changelog:
- GUI: added high DPI support
- GUI: fixed the state manager image preview
- Windows: added a new waveOut driver with support for dynamic rate control
- Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso]
- Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering
- Windows: fixed XInput controller support on Windows 10
- SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4
coprocessors
- SFC: fixed a slight rendering glitch in the intro to Megalomania
If the coprocessor firmware is missing, bsnes will fallback on HLE where it is
supported, which is everything other than SD Gundam GX and the two Hayazashi
Nidan Morita Shougi games.
The Windows dynamic rate control works best with Direct3D in fullscreen
exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it
is not possible to target a single XAudio2 version on all Windows OS releases.
The waveOut driver should work everywhere out of the box.
Note that with DRC, the synchronization source is your monitor, so you will
want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync
monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
|
|
|
while(!Application::state().quit) {
|
|
|
|
if(Application::state().onMain) {
|
|
|
|
//doMain() is responsible for sleeping the thread where practical
|
2015-06-12 13:14:38 +00:00
|
|
|
Application::doMain();
|
Update to bsnes v107.1 release.
byuu says:
Don't let the point release fool you, there are many significant changes in this
release. I will be keeping bsnes releases using a point system until the new
higan release is ready.
Changelog:
- GUI: added high DPI support
- GUI: fixed the state manager image preview
- Windows: added a new waveOut driver with support for dynamic rate control
- Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso]
- Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering
- Windows: fixed XInput controller support on Windows 10
- SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4
coprocessors
- SFC: fixed a slight rendering glitch in the intro to Megalomania
If the coprocessor firmware is missing, bsnes will fallback on HLE where it is
supported, which is everything other than SD Gundam GX and the two Hayazashi
Nidan Morita Shougi games.
The Windows dynamic rate control works best with Direct3D in fullscreen
exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it
is not possible to target a single XAudio2 version on all Windows OS releases.
The waveOut driver should work everywhere out of the box.
Note that with DRC, the synchronization source is your monitor, so you will
want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync
monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
|
|
|
if(Application::state().quit) break;
|
|
|
|
} else {
|
|
|
|
//avoid consuming 100% CPU thread usage
|
|
|
|
usleep(20 * 1000);
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
Update to bsnes v107.1 release.
byuu says:
Don't let the point release fool you, there are many significant changes in this
release. I will be keeping bsnes releases using a point system until the new
higan release is ready.
Changelog:
- GUI: added high DPI support
- GUI: fixed the state manager image preview
- Windows: added a new waveOut driver with support for dynamic rate control
- Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso]
- Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering
- Windows: fixed XInput controller support on Windows 10
- SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4
coprocessors
- SFC: fixed a slight rendering glitch in the intro to Megalomania
If the coprocessor firmware is missing, bsnes will fallback on HLE where it is
supported, which is everything other than SD Gundam GX and the two Hayazashi
Nidan Morita Shougi games.
The Windows dynamic rate control works best with Direct3D in fullscreen
exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it
is not possible to target a single XAudio2 version on all Windows OS releases.
The waveOut driver should work everywhere out of the box.
Note that with DRC, the synchronization source is your monitor, so you will
want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync
monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
|
|
|
//called after doMain(), in case doMain() calls Application::quit()
|
|
|
|
processEvents();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pApplication::pendingEvents() -> bool {
|
2013-03-15 13:11:33 +00:00
|
|
|
MSG msg;
|
|
|
|
return PeekMessage(&msg, 0, 0, 0, PM_NOREMOVE);
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pApplication::processEvents() -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
while(pendingEvents()) {
|
|
|
|
MSG msg;
|
|
|
|
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) {
|
|
|
|
Application_processDialogMessage(msg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto Application_processDialogMessage(MSG& msg) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
if(msg.message == WM_KEYDOWN || msg.message == WM_KEYUP
|
|
|
|
|| msg.message == WM_SYSKEYDOWN || msg.message == WM_SYSKEYUP) {
|
|
|
|
if(Application_keyboardProc(msg.hwnd, msg.message, msg.wParam, msg.lParam)) {
|
|
|
|
DispatchMessage(&msg);
|
Update to v094 release.
byuu says:
This release adds support for game libraries, and substantially improves
Game Boy and Game Boy Color emulation with cycle-based renderers. Many
other changes are also present.
It's very important to note that this release now defaults to optimal
drivers rather than safe drivers. This is particularly important if you
do not have strong OpenGL 3.2 drivers. If performance is bad, go to
Settings -> Configuration -> Advanced, change the video driver, and
restart higan. In the rare case that you have trouble opening higan, you
can edit settings.bml directly and change the setting there. The Windows
safe driver is Direct3D, and the Linux safe driver is XShm.
Also note that although display emulation shaders are now supported,
they have not been included in this release as they are not ready yet.
The support has been built-in anyway, so that they can be tested by
everyone. Once refined, future releases of higan will come with built-in
shaders for each emulated system that simulates the unique display
characteristics of each.
Changelog (since v093):
- sfc: added SA-1 MDR support (fixes SD Gundam G-Next bug)
- sfc: remove random/ and config/, merge to system/ with better
randomization
- gb: improved color emulation palette contrast
- gbc: do not sort sprites by X-priority
- gbc: allow transparency on BG priority pixels
- gbc: VRAM DMA timing and register fixes
- gbc: block invalid VRAM DMA transfer source and target addresses
- gba: added LCD color emulation (without it, colors are grossly
over-saturated)
- gba: removed internal frame blending (use shaders to simulate motion
blur if desired)
- gba: added Game Boy Player support (adds joypad rumble support to
supported games)
- gba: SOUND_CTL_H is readable
- gb/gbc: PPU renderer is now cycle-based (major accuracy improvement)
- gb/gbc: OAM DMA runs in parallel with the CPU
- gb/gbc: only HRAM can be accessed during OAM DMA
- gb/gbc: fixed serialization of games with SRAM
- gb/gbc: disallow up+down or left+right at the same time
- gb/gbc: added weak hipass filter to remove DC bias
- gb/gbc: STAT OAM+Hblank IRQs only trigger during active display
- gb/gbc: fixed underflow in window clamping
- gb/gbc/gba: audio mixes internally at 2MHz now instead of 4MHz (does
not affect accuracy)
- gb/gbc/gba: audio volume reduced for consistency with other systems
- fc/sfc/gb/gbc/gba: cheat codes are now stored in universal, decrypted
format
- ethos: replaced file loader with a proper game library
- ethos: added display emulation shader support
- ethos: added color emulation option to video settings
- ethos: program icon upgraded from 48x48 to 512x512
- ethos: settings and tools windows now use tab frames (less wasted
screen space)
- ethos: default to optimal (video, audio, input) drivers instead of
safest drivers
- ethos: input mapping system completely rewritten to support
hotplugging and unique device mappings
- ruby: added fixes for OpenGL 3.2 on AMD graphics cards
- ruby: quark shaders now support user settings inside of manifest
- ruby: quark shaders can use integral textures (allows display
emulation shaders to work with raw colors)
- ruby: add joypad rumble support
- ruby: XInput (Xbox 360) controllers now support hotplugging
- ruby: added Linux udev joypad driver with hotplug support
- phoenix: fixed a rare null pointer dereference issue on Windows
- port: target -std=c++11 instead of -std=gnu++11 (do not rely on GNU
C++ extensions)
- port: added out-of-the-box compilation support for BSD/Clang 3.3+
- port: applied a few Debian upstream patches
- cheats: updated to mightymo's 2014-01-02 release; decrypted all Game
Genie codes
2014-01-20 08:55:17 +00:00
|
|
|
return;
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if(!IsDialogMessage(GetForegroundWindow(), &msg)) {
|
|
|
|
TranslateMessage(&msg);
|
|
|
|
DispatchMessage(&msg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pApplication::quit() -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
PostQuitMessage(0);
|
|
|
|
}
|
|
|
|
|
2018-07-24 13:41:41 +00:00
|
|
|
auto pApplication::setScreenSaver(bool screenSaver) -> void {
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pApplication::initialize() -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
CoInitialize(0);
|
|
|
|
InitCommonControls();
|
|
|
|
|
Update to v106r57 release.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 08:46:58 +00:00
|
|
|
WNDCLASS wc{};
|
2015-06-12 13:14:38 +00:00
|
|
|
|
|
|
|
#if defined(Hiro_Window)
|
2013-03-15 13:11:33 +00:00
|
|
|
wc.cbClsExtra = 0;
|
|
|
|
wc.cbWndExtra = 0;
|
|
|
|
wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
|
|
|
|
wc.hCursor = LoadCursor(0, IDC_ARROW);
|
|
|
|
wc.hIcon = LoadIcon(GetModuleHandle(0), MAKEINTRESOURCE(2));
|
|
|
|
wc.hInstance = GetModuleHandle(0);
|
Update to 20180809 release.
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
2018-08-10 05:02:59 +00:00
|
|
|
wc.lpfnWndProc = Window_windowProc;
|
2015-06-12 13:14:38 +00:00
|
|
|
wc.lpszClassName = L"hiroWindow";
|
|
|
|
wc.lpszMenuName = 0;
|
|
|
|
wc.style = CS_HREDRAW | CS_VREDRAW;
|
|
|
|
RegisterClass(&wc);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(Hiro_PopupMenu)
|
|
|
|
wc.cbClsExtra = 0;
|
|
|
|
wc.cbWndExtra = 0;
|
|
|
|
wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
|
|
|
|
wc.hCursor = LoadCursor(0, IDC_ARROW);
|
|
|
|
wc.hIcon = LoadIcon(GetModuleHandle(0), MAKEINTRESOURCE(2));
|
|
|
|
wc.hInstance = GetModuleHandle(0);
|
|
|
|
wc.lpfnWndProc = Menu_windowProc;
|
|
|
|
wc.lpszClassName = L"hiroPopupMenu";
|
2013-03-15 13:11:33 +00:00
|
|
|
wc.lpszMenuName = 0;
|
|
|
|
wc.style = CS_HREDRAW | CS_VREDRAW;
|
|
|
|
RegisterClass(&wc);
|
2015-06-12 13:14:38 +00:00
|
|
|
#endif
|
2013-03-15 13:11:33 +00:00
|
|
|
|
Update to v106r57 release.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 08:46:58 +00:00
|
|
|
#if defined(Hiro_Widget)
|
2013-03-15 13:11:33 +00:00
|
|
|
wc.cbClsExtra = 0;
|
|
|
|
wc.cbWndExtra = 0;
|
|
|
|
wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
|
|
|
|
wc.hCursor = LoadCursor(0, IDC_ARROW);
|
|
|
|
wc.hIcon = LoadIcon(0, IDI_APPLICATION);
|
|
|
|
wc.hInstance = GetModuleHandle(0);
|
Update to v106r57 release.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 08:46:58 +00:00
|
|
|
wc.lpfnWndProc = ToolTip_windowProc;
|
|
|
|
wc.lpszClassName = L"hiroToolTip";
|
2013-03-15 13:11:33 +00:00
|
|
|
wc.lpszMenuName = 0;
|
|
|
|
wc.style = CS_HREDRAW | CS_VREDRAW;
|
|
|
|
RegisterClass(&wc);
|
2015-06-12 13:14:38 +00:00
|
|
|
#endif
|
2013-03-15 13:11:33 +00:00
|
|
|
|
Update to v106r57 release.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 08:46:58 +00:00
|
|
|
#if defined(Hiro_Widget)
|
2013-03-15 13:11:33 +00:00
|
|
|
wc.cbClsExtra = 0;
|
|
|
|
wc.cbWndExtra = 0;
|
|
|
|
wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
|
|
|
|
wc.hCursor = LoadCursor(0, IDC_ARROW);
|
|
|
|
wc.hIcon = LoadIcon(0, IDI_APPLICATION);
|
|
|
|
wc.hInstance = GetModuleHandle(0);
|
Update to v106r57 release.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 08:46:58 +00:00
|
|
|
wc.lpfnWndProc = Default_windowProc;
|
|
|
|
wc.lpszClassName = L"hiroWidget";
|
2013-03-15 13:11:33 +00:00
|
|
|
wc.lpszMenuName = 0;
|
|
|
|
wc.style = CS_HREDRAW | CS_VREDRAW;
|
|
|
|
RegisterClass(&wc);
|
2015-06-12 13:14:38 +00:00
|
|
|
#endif
|
2013-03-15 13:11:33 +00:00
|
|
|
|
|
|
|
pKeyboard::initialize();
|
2018-07-16 06:16:26 +00:00
|
|
|
pWindow::initialize();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
Update to v106r57 release.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
2018-08-08 08:46:58 +00:00
|
|
|
auto pApplication::state() -> State& {
|
|
|
|
static State state;
|
|
|
|
return state;
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
static auto Application_keyboardProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) -> bool {
|
2013-03-15 13:11:33 +00:00
|
|
|
if(msg != WM_KEYDOWN && msg != WM_SYSKEYDOWN && msg != WM_KEYUP && msg != WM_SYSKEYUP) return false;
|
|
|
|
|
2015-06-15 22:16:43 +00:00
|
|
|
GUITHREADINFO info{sizeof(GUITHREADINFO)};
|
2013-03-15 13:11:33 +00:00
|
|
|
GetGUIThreadInfo(GetCurrentThreadId(), &info);
|
2015-06-15 22:16:43 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto object = (mObject*)GetWindowLongPtr(info.hwndFocus, GWLP_USERDATA);
|
|
|
|
if(!object) return false;
|
|
|
|
|
2017-07-15 12:00:20 +00:00
|
|
|
auto objectWindow = (mObject*)GetWindowLongPtr(GetAncestor(info.hwndFocus, GA_ROOT), GWLP_USERDATA);
|
|
|
|
if(!objectWindow) return false;
|
|
|
|
|
|
|
|
if(auto window = dynamic_cast<mWindow*>(objectWindow)) {
|
2015-06-15 22:16:43 +00:00
|
|
|
if(auto self = window->self()) {
|
|
|
|
if(!self->_modalityDisabled()) {
|
|
|
|
if(auto code = pKeyboard::_translate(wparam, lparam)) {
|
Update to v103r13 release.
byuu says:
Changelog:
- gb/interface: fix Game Boy Color extension to be "gbc" and not "gb"
[hex\_usr]
- ms/interface: move Master System hardware controls below controller
ports
- sfc/ppu: improve latching behavior of BGnHOFS registers (not
hardware verified) [AWJ]
- tomoko/input: rework port/device mapping to support non-sequential
ports and devices¹
- todo: should add move() to inputDevice.mappings.append and
inputPort.devices.append
- note: there's a weird GCC 4.9 bug with brace initialization of
InputEmulator; have to assign each field separately
- tomoko: all windows sans the main presentation window can be
dismissed with the escape key
- icarus: the single file selection dialog ("Load ROM Image...") can
be dismissed with the escape key
- tomoko: do not pause emulation when FocusLoss/Pause is set during
exclusive fullscreen mode
- hiro/(windows,gtk,qt): implemented Window::setDismissable() function
(missing from cocoa port, sorry)
- nall/string: fixed printing of largest possible negative numbers (eg
`INT_MIN`) [Sintendo]
- only took eight months! :D
¹: When I tried to move the Master System hardware port below the
controller ports, I ran into a world of pain.
The input settings list expects every item in the
`InputEmulator<InputPort<InputDevice<InputMapping>>>>` arrays to be
populated with valid results. But these would be sparsely populated
based on the port and device IDs from inside higan. And that is done so
that the Interface::inputPoll can have O(1) lookup of ports and devices.
This worked because all the port and device IDs were sequential (they
left no gaps in the maps upon creating the lists.)
Unfortunately by changing the expectation of port ID to how it appears
in the list, inputs would not poll correctly. By leaving them alone and
just moving Hardware to the third position, the Game Gear would be
missing port IDs of 0 and 1 (the controller ports of the Master System).
Even by trying to make separate MasterSystemHardware and
GameGearHardware ports, things still fractured when the devices were no
longer contigious.
I got pretty sick of this and just decided to give up on O(1)
port/device lookup, and moved to O(n) lookup. It only knocked the
framerate down by maybe one frame per second, enough to be in the margin
of error. Inputs aren't polled *that* often for loops that usually
terminate after 1-2 cycles to be too detrimental to performance.
So the new input system now allows non-sequential port and device IDs.
Remember that I killed input IDs a while back. There's never any reason
for those to need IDs ... it was easier to just order the inputs in the
order you want to see them in the user interface. So the input lookup is
still O(1). Only now, everything's safer and I return a
maybe<InputMapping&>, and won't crash out the program trying to use a
mapping that isn't found for some reason.
Errata: the escape key isn't working on the browser/message dialogs on
Windows, because of course nothing can ever just be easy and work for
me. If anyone else wouldn't mind looking into that, I'd greatly
appreciate it.
Having the `WM_KEYDOWN` test inside the main `Application_sharedProc`, it
seems to not respond to the escape key on modal dialogs. If I put the
`WM_KEYDOWN` test in the main window proc, then it doesn't seem to get
called for `VK_ESCAPE` at all, and doesn't get called period for modal
windows. So I'm at a loss and it's past 4AM here >_>
2017-07-12 08:24:27 +00:00
|
|
|
if(msg == WM_KEYDOWN || msg == WM_SYSKEYDOWN) {
|
|
|
|
window->doKeyPress(code);
|
|
|
|
}
|
|
|
|
if(msg == WM_KEYUP || msg == WM_SYSKEYUP) {
|
|
|
|
window->doKeyRelease(code);
|
|
|
|
}
|
|
|
|
}
|
Update to 20180809 release.
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
2018-08-10 05:02:59 +00:00
|
|
|
//TODO: does this really need to be hooked here?
|
|
|
|
if(msg == WM_KEYDOWN && wparam == VK_ESCAPE && window->state.dismissable) {
|
|
|
|
if(auto result = self->windowProc(self->hwnd, WM_CLOSE, wparam, lparam)) return result();
|
2015-06-15 22:16:43 +00:00
|
|
|
}
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-15 22:16:43 +00:00
|
|
|
if(auto window = object->parentWindow(true)) {
|
|
|
|
if(auto self = window->self()) {
|
|
|
|
if(self->_modalityDisabled()) return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
if(msg == WM_KEYDOWN) {
|
Update to 20180809 release.
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
2018-08-10 05:02:59 +00:00
|
|
|
//TODO: does this really need to be hooked here?
|
|
|
|
#if defined(Hiro_Widget)
|
|
|
|
if(auto widget = dynamic_cast<mWidget*>(object)) {
|
|
|
|
if(auto self = widget->self()) {
|
|
|
|
if(auto result = self->windowProc(self->hwnd, msg, wparam, lparam)) {
|
|
|
|
return result();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-06-12 13:14:38 +00:00
|
|
|
#endif
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
2015-06-12 13:14:38 +00:00
|
|
|
|
|
|
|
#endif
|