bsnes/hiro/windows/application.cpp

191 lines
5.1 KiB
C++
Raw Normal View History

#if defined(Hiro_Application)
namespace hiro {
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;
auto pApplication::modal() -> bool {
return state().modalCount > 0;
}
auto pApplication::run() -> void {
MSG msg;
if(Application::state().onMain) {
while(!Application::state().quit) {
Application::doMain();
processEvents();
}
} else {
MSG msg;
while(GetMessage(&msg, 0, 0, 0)) {
Application_processDialogMessage(msg);
}
}
}
auto pApplication::pendingEvents() -> bool {
MSG msg;
return PeekMessage(&msg, 0, 0, 0, PM_NOREMOVE);
}
auto pApplication::processEvents() -> void {
while(pendingEvents()) {
MSG msg;
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) {
Application_processDialogMessage(msg);
}
}
}
auto Application_processDialogMessage(MSG& msg) -> void {
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;
}
}
if(!IsDialogMessage(GetForegroundWindow(), &msg)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
auto pApplication::quit() -> void {
PostQuitMessage(0);
}
auto pApplication::setScreenSaver(bool screenSaver) -> void {
}
auto pApplication::initialize() -> void {
CoInitialize(0);
InitCommonControls();
WNDCLASS wc{};
#if defined(Hiro_Window)
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;
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";
wc.lpszMenuName = 0;
wc.style = CS_HREDRAW | CS_VREDRAW;
RegisterClass(&wc);
#endif
#if defined(Hiro_Widget)
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);
wc.lpfnWndProc = ToolTip_windowProc;
wc.lpszClassName = L"hiroToolTip";
wc.lpszMenuName = 0;
wc.style = CS_HREDRAW | CS_VREDRAW;
RegisterClass(&wc);
#endif
#if defined(Hiro_Widget)
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);
wc.lpfnWndProc = Default_windowProc;
wc.lpszClassName = L"hiroWidget";
wc.lpszMenuName = 0;
wc.style = CS_HREDRAW | CS_VREDRAW;
RegisterClass(&wc);
#endif
pKeyboard::initialize();
pWindow::initialize();
}
auto pApplication::state() -> State& {
static State state;
return state;
}
static auto Application_keyboardProc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) -> bool {
if(msg != WM_KEYDOWN && msg != WM_SYSKEYDOWN && msg != WM_KEYUP && msg != WM_SYSKEYUP) return false;
GUITHREADINFO info{sizeof(GUITHREADINFO)};
GetGUIThreadInfo(GetCurrentThreadId(), &info);
auto object = (mObject*)GetWindowLongPtr(info.hwndFocus, GWLP_USERDATA);
if(!object) return false;
auto objectWindow = (mObject*)GetWindowLongPtr(GetAncestor(info.hwndFocus, GA_ROOT), GWLP_USERDATA);
if(!objectWindow) return false;
if(auto window = dynamic_cast<mWindow*>(objectWindow)) {
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();
}
}
}
}
if(auto window = object->parentWindow(true)) {
if(auto self = window->self()) {
if(self->_modalityDisabled()) return false;
}
}
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();
}
}
}
#endif
}
return false;
}
}
#endif