2015-06-12 13:14:38 +00:00
|
|
|
#if defined(Hiro_Timer)
|
|
|
|
|
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
|
|
|
//timeBeginPeriod(1) + timeSetEvent does not seem any more performant than SetTimer
|
|
|
|
//it also seems buggier, and requires libwinmm
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
namespace hiro {
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2012-08-07 13:28:00 +00:00
|
|
|
static vector<pTimer*> timers;
|
2011-06-05 03:45:04 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
static auto CALLBACK Timer_timeoutProc(HWND hwnd, UINT msg, UINT_PTR timerID, DWORD time) -> void {
|
2019-01-01 23:52:08 +00:00
|
|
|
if(Application::state().quit) return;
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
for(auto& timer : timers) {
|
2015-06-12 13:14:38 +00:00
|
|
|
if(timer->htimer == timerID) return timer->self().doActivate();
|
2011-06-05 03:45:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pTimer::construct() -> void {
|
|
|
|
timers.append(this);
|
|
|
|
htimer = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pTimer::destruct() -> 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
|
|
|
setEnabled(false);
|
|
|
|
if(auto index = timers.find(this)) timers.remove(*index);
|
2015-06-12 13:14:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto pTimer::setEnabled(bool enabled) -> void {
|
2011-06-05 03:45:04 +00:00
|
|
|
if(htimer) {
|
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
|
|
|
KillTimer(nullptr, htimer);
|
2011-06-05 03:45:04 +00:00
|
|
|
htimer = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(enabled == true) {
|
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
|
|
|
htimer = SetTimer(nullptr, 0, state().interval, Timer_timeoutProc);
|
2011-06-05 03:45:04 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 pTimer::setInterval(uint interval) -> void {
|
2011-06-05 03:45:04 +00:00
|
|
|
//destroy and recreate timer if interval changed
|
2015-06-12 13:14:38 +00:00
|
|
|
setEnabled(self().enabled(true));
|
2011-06-05 03:45:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
#endif
|