2015-06-12 13:14:38 +00:00
|
|
|
#if defined(Hiro_Window)
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
namespace hiro {
|
2013-04-14 08:52:47 +00:00
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
static const uint FixedStyle = WS_SYSMENU | WS_CAPTION | WS_MINIMIZEBOX | WS_BORDER | WS_CLIPCHILDREN;
|
|
|
|
static const uint ResizableStyle = WS_SYSMENU | WS_CAPTION | WS_MINIMIZEBOX | WS_MAXIMIZEBOX | WS_THICKFRAME | WS_CLIPCHILDREN;
|
2011-02-24 09:25:20 +00:00
|
|
|
|
2018-07-16 06:16:26 +00:00
|
|
|
uint pWindow::minimumStatusHeight = 0;
|
|
|
|
|
|
|
|
auto pWindow::initialize() -> void {
|
|
|
|
HWND hwnd = CreateWindow(L"hiroWindow", L"", ResizableStyle, 128, 128, 256, 256, 0, 0, GetModuleHandle(0), 0);
|
|
|
|
HWND hstatus = CreateWindow(STATUSCLASSNAME, L"", WS_CHILD, 0, 0, 0, 0, hwnd, nullptr, GetModuleHandle(0), 0);
|
|
|
|
SetWindowPos(hstatus, nullptr, 0, 0, 0, 0, SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED);
|
|
|
|
RECT rc;
|
|
|
|
GetWindowRect(hstatus, &rc);
|
|
|
|
minimumStatusHeight = rc.bottom - rc.top;
|
|
|
|
DestroyWindow(hstatus);
|
|
|
|
DestroyWindow(hwnd);
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::construct() -> void {
|
|
|
|
hwnd = CreateWindow(L"hiroWindow", L"", ResizableStyle, 128, 128, 256, 256, 0, 0, GetModuleHandle(0), 0);
|
|
|
|
SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR)&reference);
|
|
|
|
setDroppable(state().droppable);
|
|
|
|
setGeometry({128, 128, 256, 256});
|
2015-06-15 22:16:43 +00:00
|
|
|
|
|
|
|
windows.append(self().instance);
|
2012-08-07 13:28:00 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::destruct() -> void {
|
2015-06-15 22:16:43 +00:00
|
|
|
if(auto position = windows.find(self().instance)) windows.remove(*position);
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
if(hbrush) { DeleteObject(hbrush); hbrush = nullptr; }
|
|
|
|
DestroyWindow(hwnd);
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
auto pWindow::append(sMenuBar menuBar) -> void {
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
auto pWindow::append(sSizable sizable) -> void {
|
2015-06-12 13:14:38 +00:00
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::append(sStatusBar statusBar) -> void {
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
2015-06-15 22:16:43 +00:00
|
|
|
auto pWindow::focused() const -> bool {
|
2011-02-24 09:25:20 +00:00
|
|
|
return (GetForegroundWindow() == hwnd);
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::frameMargin() const -> Geometry {
|
|
|
|
RECT rc{0, 0, 640, 480};
|
2018-07-16 06:16:26 +00:00
|
|
|
uint style = state().fullScreen ? 0 : state().resizable ? ResizableStyle : FixedStyle;
|
|
|
|
bool menuVisible = state().menuBar && state().menuBar->visible();
|
|
|
|
AdjustWindowRect(&rc, style, menuVisible);
|
|
|
|
return {abs(rc.left), abs(rc.top), (rc.right - rc.left) - 640, (rc.bottom - rc.top) + _statusHeight() - 480};
|
2011-02-27 09:05:10 +00:00
|
|
|
}
|
|
|
|
|
Update to 20180729 release.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
2018-07-29 13:24:38 +00:00
|
|
|
auto pWindow::monitor() const -> uint {
|
|
|
|
//TODO
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
auto pWindow::remove(sMenuBar menuBar) -> void {
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
auto pWindow::remove(sSizable sizable) -> void {
|
2011-09-05 03:48:23 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::remove(sStatusBar statusBar) -> void {
|
2011-09-05 03:48:23 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setBackgroundColor(Color color) -> void {
|
|
|
|
hbrushColor = CreateRGB(color);
|
|
|
|
if(hbrush) { DeleteObject(hbrush); hbrush = nullptr; }
|
|
|
|
if(color) hbrush = CreateSolidBrush(hbrushColor);
|
2011-09-05 03:48:23 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
auto pWindow::setDismissable(bool dismissable) -> void {
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setDroppable(bool droppable) -> void {
|
|
|
|
DragAcceptFiles(hwnd, droppable);
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setEnabled(bool enabled) -> void {
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
if(auto self = sizable->self()) self->setEnabled(sizable->enabled(true));
|
2015-06-15 22:26:47 +00:00
|
|
|
}
|
2013-07-29 09:42:45 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setFocused() -> void {
|
|
|
|
if(!self().visible()) self().setVisible(true);
|
2011-02-24 09:25:20 +00:00
|
|
|
SetFocus(hwnd);
|
|
|
|
}
|
|
|
|
|
Update to v094r43 release.
byuu says:
Updated to compile with all of the new hiro changes. My next step is to
write up hiro API documentation, and move the API from alpha (constantly
changing) to beta (rarely changing), in preparation for the first stable
release (backward-compatible changes only.)
Added "--fullscreen" command-line option. I like this over
a configuration file option. Lets you use the emulator in both modes
without having to modify the config file each time.
Also enhanced the command-line game loading. You can now use any of
these methods:
higan /path/to/game-folder.sfc
higan /path/to/game-folder.sfc/
higan /path/to/game-folder.sfc/program.rom
The idea is to support launchers that insist on loading files only.
Technically, the file can be any name (manifest.bml also works); the
only criteria is that the file actually exists and is a file, and not
a directory. This is a requirement to support the first version (a
directory lacking the trailing / identifier), because I don't want my
nall::string class to query the file system to determine if the string
is an actual existing file or directory for its pathname() / dirname()
functions.
Anyway, every game folder I've made so far has program.rom, and that's
very unlikely to change, so this should be fine.
Now, of course, if you drop a regular "game.sfc" file on the emulator,
it won't even try to load it, unless it's in a folder that ends in .fc,
.sfc, etc. In which case, it'll bail out immediately by being unable to
produce a manifest for what is obviously not really a game folder.
2015-08-30 02:08:26 +00:00
|
|
|
auto pWindow::setFont(const Font& font) -> void {
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
if(auto self = sizable->self()) self->setFont(sizable->font(true));
|
2015-06-15 22:26:47 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setFullScreen(bool fullScreen) -> void {
|
2015-06-18 10:48:53 +00:00
|
|
|
auto style = GetWindowLongPtr(hwnd, GWL_STYLE) & WS_VISIBLE;
|
2015-06-12 13:14:38 +00:00
|
|
|
lock();
|
2015-08-24 09:42:11 +00:00
|
|
|
if(fullScreen) {
|
|
|
|
windowedGeometry = self().geometry();
|
2014-01-05 09:59:17 +00:00
|
|
|
HMONITOR monitor = MonitorFromWindow(hwnd, MONITOR_DEFAULTTONEAREST);
|
|
|
|
MONITORINFOEX info;
|
|
|
|
memset(&info, 0, sizeof(MONITORINFOEX));
|
|
|
|
info.cbSize = sizeof(MONITORINFOEX);
|
|
|
|
GetMonitorInfo(monitor, &info);
|
|
|
|
RECT rc = info.rcMonitor;
|
|
|
|
Geometry geometry = {rc.left, rc.top, rc.right - rc.left, rc.bottom - rc.top};
|
2015-06-18 10:48:53 +00:00
|
|
|
SetWindowLongPtr(hwnd, GWL_STYLE, style | WS_POPUP);
|
2011-02-24 09:27:21 +00:00
|
|
|
Geometry margin = frameMargin();
|
2015-08-24 09:42:11 +00:00
|
|
|
self().setGeometry({
|
2015-06-12 13:14:38 +00:00
|
|
|
geometry.x() + margin.x(), geometry.y() + margin.y(),
|
|
|
|
geometry.width() - margin.width(), geometry.height() - margin.height()
|
2014-01-05 09:59:17 +00:00
|
|
|
});
|
2015-08-24 09:42:11 +00:00
|
|
|
} else {
|
|
|
|
SetWindowLongPtr(hwnd, GWL_STYLE, style | (state().resizable ? ResizableStyle : FixedStyle));
|
|
|
|
self().setGeometry(windowedGeometry);
|
2011-02-24 09:27:21 +00:00
|
|
|
}
|
2015-06-12 13:14:38 +00:00
|
|
|
unlock();
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setGeometry(Geometry geometry) -> void {
|
|
|
|
lock();
|
2011-02-24 09:25:20 +00:00
|
|
|
Geometry margin = frameMargin();
|
|
|
|
SetWindowPos(
|
2015-08-24 09:42:11 +00:00
|
|
|
hwnd, nullptr,
|
2015-06-12 13:14:38 +00:00
|
|
|
geometry.x() - margin.x(), geometry.y() - margin.y(),
|
|
|
|
geometry.width() + margin.width(), geometry.height() + margin.height(),
|
Update to v103r11 release.
byuu says:
Changelog:
- tomoko: removed "Settings→Video Emulation→Overscan Mask" setting¹
- tomoko: remove a few unnecessary calls to resizeViewport on startup
- tomoko: only resize main window from video settings when in adaptive
or toggling adaptive mode²
- hiro/windows: add `SWP_NOACTIVATE` flag to prevent focus stealing on
resizing invisible windows³
- hiro/windows: suppress spurious API-generated `onSize()` callback
when calling `setVisible()`
¹: it just seemed like bad design to default to overscan masking
being disabled with overscan masks of 8 horizontal, 8 vertical out of
the box. Users would adjust the sliders and not see anything happening.
Instead, I've set the default masks to zero. If you want to turn off
overscan masking, simply slide those to zero again.
²: I figure the only way we're going to be able to fairly evaluate
Screwtape's suggestion is to try it both ways. And I will admit, I kind
of like the way this works as well ... a lot more so than I thought I
would, so I think it was a great suggestion. Still, now's the time if
people have strong opinions on this. Be sure to try both r10 and r11 to
compare. Barring no other feedback, I'm going to keep it this way.
³: this fixes the blinking of the main window on startup.
Screwtape, thanks again for the improvement suggestions. At this point
though, I am not using a tiling window manager. If you are able to patch
hiro/gtk and/or hiro/qt (I mostly use GTK) to work with tiling window
managers better, I wouldn't mind applying said patches, so long as they
don't break things on my own Xfce desktop with xfwm4.
Also, I noticed one issue with Xfce ... if the window is maximized and I
try to call `Window::setSize()`, it's not actually removing the maximize
flag. We'll need to look into how to add that to GTK, but I don't think
it's a huge issue. A similar glitch happens on windows where the icon
still reflects being maximized, but it does actually shrink, it just
sticks to the top left corner of the screen. So this isn't really a
critical bug, but would be extra polish.
2017-07-08 01:02:01 +00:00
|
|
|
SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED
|
2011-02-24 09:25:20 +00:00
|
|
|
);
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
if(auto& statusBar = state().statusBar) {
|
2015-06-12 13:14:38 +00:00
|
|
|
if(auto self = statusBar->self()) {
|
Update to v103r11 release.
byuu says:
Changelog:
- tomoko: removed "Settings→Video Emulation→Overscan Mask" setting¹
- tomoko: remove a few unnecessary calls to resizeViewport on startup
- tomoko: only resize main window from video settings when in adaptive
or toggling adaptive mode²
- hiro/windows: add `SWP_NOACTIVATE` flag to prevent focus stealing on
resizing invisible windows³
- hiro/windows: suppress spurious API-generated `onSize()` callback
when calling `setVisible()`
¹: it just seemed like bad design to default to overscan masking
being disabled with overscan masks of 8 horizontal, 8 vertical out of
the box. Users would adjust the sliders and not see anything happening.
Instead, I've set the default masks to zero. If you want to turn off
overscan masking, simply slide those to zero again.
²: I figure the only way we're going to be able to fairly evaluate
Screwtape's suggestion is to try it both ways. And I will admit, I kind
of like the way this works as well ... a lot more so than I thought I
would, so I think it was a great suggestion. Still, now's the time if
people have strong opinions on this. Be sure to try both r10 and r11 to
compare. Barring no other feedback, I'm going to keep it this way.
³: this fixes the blinking of the main window on startup.
Screwtape, thanks again for the improvement suggestions. At this point
though, I am not using a tiling window manager. If you are able to patch
hiro/gtk and/or hiro/qt (I mostly use GTK) to work with tiling window
managers better, I wouldn't mind applying said patches, so long as they
don't break things on my own Xfce desktop with xfwm4.
Also, I noticed one issue with Xfce ... if the window is maximized and I
try to call `Window::setSize()`, it's not actually removing the maximize
flag. We'll need to look into how to add that to GTK, but I don't think
it's a huge issue. A similar glitch happens on windows where the icon
still reflects being maximized, but it does actually shrink, it just
sticks to the top left corner of the screen. So this isn't really a
critical bug, but would be extra polish.
2017-07-08 01:02:01 +00:00
|
|
|
SetWindowPos(self->hwnd, nullptr, 0, 0, 0, 0, SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED);
|
2015-06-12 13:14:38 +00:00
|
|
|
}
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
sizable->setGeometry(geometry.setPosition());
|
2015-06-12 13:14:38 +00:00
|
|
|
}
|
|
|
|
unlock();
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
2018-07-08 04:58:27 +00:00
|
|
|
auto pWindow::setMaximized(bool maximized) -> void {
|
|
|
|
if(state().minimized) return;
|
|
|
|
lock();
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
ShowWindow(hwnd, maximized ? SW_MAXIMIZE : SW_SHOWNOACTIVATE);
|
2018-07-08 04:58:27 +00:00
|
|
|
unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setMaximumSize(Size size) -> void {
|
|
|
|
//todo
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setMinimized(bool minimized) -> void {
|
|
|
|
lock();
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
ShowWindow(hwnd, minimized ? SW_MINIMIZE : state().maximized ? SW_MAXIMIZE : SW_SHOWNOACTIVATE);
|
2018-07-08 04:58:27 +00:00
|
|
|
unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setMinimumSize(Size size) -> void {
|
|
|
|
//todo
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setModal(bool modality) -> void {
|
|
|
|
if(modality) {
|
2015-06-15 22:16:43 +00:00
|
|
|
_modalityUpdate();
|
2015-06-12 13:14:38 +00:00
|
|
|
while(state().modal) {
|
2013-03-15 13:11:33 +00:00
|
|
|
Application::processEvents();
|
2018-08-05 09:00:15 +00:00
|
|
|
if(Application::state().onMain) {
|
2015-06-12 13:14:38 +00:00
|
|
|
Application::doMain();
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
} else {
|
|
|
|
usleep(20 * 1000);
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
2015-06-15 22:16:43 +00:00
|
|
|
_modalityUpdate();
|
Update to v088r11 release.
byuu says:
Changelog:
- phoenix has added Window::setModal(bool modal = true);
- file dialog is now modal. This allows emulation cores to request data
and get it immediately before continuing the loading process
- save data is hooked up for most systems, still need to handle
subsystem slot saves (Sufami Turbo, basically.)
- toggle fullscreen key binding added (Alt+Enter for now. I think F11 is
probably better though, Enter is often mapped to game start button.)
- video scaling is in (center, scale, stretch), works the same in
windowed and fullscreen mode (stretch hides resize window option), all
in the settings menu now
- enough structure to map all saved paths for the browser and to load
BS-X slotted carts, BS-X carts, single Sufami Turbo carts
Caveats / Missing:
- Super Game Boy input doesn't work yet (due to change in callback
binding)
- doesn't load secondary Sufami Turbo slot yet
- BS-X BIOS isn't show the data pack games to load for some reason (ugh,
I hate the shit out of debugging BS-X stuff ...)
- need mute audio, sync audio+video toggle, save/load state menu and
quick keys, XML mapping information window
- need cheat editor and cheat database
- need state manager
- need to sort subsystems below main systems in load menu (basically
just see if media.slot.size() > 0)
- need video shaders (will probably leave off filters for the time being
... due to that 24/30-bit thing)
- need video adjustments (contrast etc, overscan masks)
- need audio adjustments (frequency, latency, resampler, volume,
per-system frequency)
- need driver selection and input focus policy (driver crash detection
would be nice too)
- need NSS DIP switch settings (that one will be really fun)
- need to save and load window geometry settings
- need to hook up controller selection (won't be fun), create a map to
hide controllers with no inputs to reassign
2012-05-03 12:36:47 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setResizable(bool resizable) -> void {
|
2015-06-18 10:48:53 +00:00
|
|
|
auto style = GetWindowLongPtr(hwnd, GWL_STYLE) & WS_VISIBLE;
|
|
|
|
SetWindowLongPtr(hwnd, GWL_STYLE, style | (state().resizable ? ResizableStyle : FixedStyle));
|
2015-06-12 13:14:38 +00:00
|
|
|
setGeometry(state().geometry);
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setTitle(string text) -> void {
|
2011-02-24 09:25:20 +00:00
|
|
|
SetWindowText(hwnd, utf16_t(text));
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::setVisible(bool visible) -> void {
|
2018-07-16 06:16:26 +00:00
|
|
|
auto lock = acquire();
|
2011-02-24 09:25:20 +00:00
|
|
|
ShowWindow(hwnd, visible ? SW_SHOWNORMAL : SW_HIDE);
|
2018-08-05 09:00:15 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
sizable->setGeometry(self().geometry().setPosition());
|
|
|
|
}
|
2015-06-12 13:14:38 +00:00
|
|
|
if(!visible) setModal(false);
|
2011-09-05 03:48:23 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
//
|
2011-02-24 09:25:20 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onClose() -> void {
|
|
|
|
if(state().onClose) self().doClose();
|
|
|
|
else self().setVisible(false);
|
|
|
|
if(state().modal && !self().visible()) self().setModal(false);
|
2011-02-24 09:25:20 +00:00
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onDrop(WPARAM wparam) -> void {
|
2016-07-01 11:58:12 +00:00
|
|
|
auto paths = DropPaths(wparam);
|
2016-05-04 10:07:13 +00:00
|
|
|
if(paths) self().doDrop(paths);
|
2013-11-28 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onEraseBackground() -> bool {
|
|
|
|
if(hbrush == 0) return false;
|
2013-11-28 10:29:01 +00:00
|
|
|
RECT rc;
|
|
|
|
GetClientRect(hwnd, &rc);
|
|
|
|
PAINTSTRUCT ps;
|
|
|
|
BeginPaint(hwnd, &ps);
|
2015-06-12 13:14:38 +00:00
|
|
|
FillRect(ps.hdc, &rc, hbrush);
|
2013-11-28 10:29:01 +00:00
|
|
|
EndPaint(hwnd, &ps);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onModalBegin() -> void {
|
|
|
|
Application::Windows::doModalChange(true);
|
2013-11-28 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onModalEnd() -> void {
|
|
|
|
Application::Windows::doModalChange(false);
|
2013-11-28 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onMove() -> void {
|
|
|
|
if(locked()) return;
|
|
|
|
state().geometry.setPosition(_geometry().position());
|
|
|
|
self().doMove();
|
|
|
|
}
|
2013-11-28 10:29:01 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::onSize() -> void {
|
|
|
|
if(locked()) return;
|
|
|
|
if(auto statusBar = state().statusBar) {
|
|
|
|
if(auto self = statusBar->self()) {
|
Update to v103r11 release.
byuu says:
Changelog:
- tomoko: removed "Settings→Video Emulation→Overscan Mask" setting¹
- tomoko: remove a few unnecessary calls to resizeViewport on startup
- tomoko: only resize main window from video settings when in adaptive
or toggling adaptive mode²
- hiro/windows: add `SWP_NOACTIVATE` flag to prevent focus stealing on
resizing invisible windows³
- hiro/windows: suppress spurious API-generated `onSize()` callback
when calling `setVisible()`
¹: it just seemed like bad design to default to overscan masking
being disabled with overscan masks of 8 horizontal, 8 vertical out of
the box. Users would adjust the sliders and not see anything happening.
Instead, I've set the default masks to zero. If you want to turn off
overscan masking, simply slide those to zero again.
²: I figure the only way we're going to be able to fairly evaluate
Screwtape's suggestion is to try it both ways. And I will admit, I kind
of like the way this works as well ... a lot more so than I thought I
would, so I think it was a great suggestion. Still, now's the time if
people have strong opinions on this. Be sure to try both r10 and r11 to
compare. Barring no other feedback, I'm going to keep it this way.
³: this fixes the blinking of the main window on startup.
Screwtape, thanks again for the improvement suggestions. At this point
though, I am not using a tiling window manager. If you are able to patch
hiro/gtk and/or hiro/qt (I mostly use GTK) to work with tiling window
managers better, I wouldn't mind applying said patches, so long as they
don't break things on my own Xfce desktop with xfwm4.
Also, I noticed one issue with Xfce ... if the window is maximized and I
try to call `Window::setSize()`, it's not actually removing the maximize
flag. We'll need to look into how to add that to GTK, but I don't think
it's a huge issue. A similar glitch happens on windows where the icon
still reflects being maximized, but it does actually shrink, it just
sticks to the top left corner of the screen. So this isn't really a
critical bug, but would be extra polish.
2017-07-08 01:02:01 +00:00
|
|
|
SetWindowPos(self->hwnd, nullptr, 0, 0, 0, 0, SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED);
|
2015-06-12 13:14:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
state().geometry.setSize(_geometry().size());
|
Update to v106r47 release.
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
2018-07-14 03:59:29 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
sizable->setGeometry(_geometry().setPosition());
|
2015-06-12 13:14:38 +00:00
|
|
|
}
|
|
|
|
self().doSize();
|
2013-11-28 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
//
|
2013-11-28 10:29:01 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
auto pWindow::_geometry() -> Geometry {
|
|
|
|
Geometry margin = frameMargin();
|
2013-11-28 10:29:01 +00:00
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
RECT rc;
|
|
|
|
if(IsIconic(hwnd)) {
|
|
|
|
//GetWindowRect returns -32000(x),-32000(y) when window is minimized
|
|
|
|
WINDOWPLACEMENT wp;
|
|
|
|
GetWindowPlacement(hwnd, &wp);
|
|
|
|
rc = wp.rcNormalPosition;
|
|
|
|
} else {
|
|
|
|
GetWindowRect(hwnd, &rc);
|
2013-11-28 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2015-06-12 13:14:38 +00:00
|
|
|
signed x = rc.left + margin.x();
|
|
|
|
signed y = rc.top + margin.y();
|
|
|
|
signed width = (rc.right - rc.left) - margin.width();
|
|
|
|
signed height = (rc.bottom - rc.top) - margin.height();
|
|
|
|
|
|
|
|
return {x, y, width, height};
|
2013-11-28 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2015-06-15 22:16:43 +00:00
|
|
|
auto pWindow::_modalityCount() -> unsigned {
|
|
|
|
unsigned modalWindows = 0;
|
|
|
|
for(auto& weak : windows) {
|
|
|
|
if(auto object = weak.acquire()) {
|
|
|
|
if(auto window = dynamic_cast<mWindow*>(object.data())) {
|
|
|
|
if(window->modal()) modalWindows++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return modalWindows;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_modalityDisabled() -> bool {
|
|
|
|
if(_modalityCount() == 0) return false;
|
|
|
|
return !state().modal;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::_modalityUpdate() -> void {
|
|
|
|
unsigned modalWindows = _modalityCount();
|
|
|
|
for(auto& weak : windows) {
|
|
|
|
if(auto object = weak.acquire()) {
|
|
|
|
if(auto window = dynamic_cast<mWindow*>(object.data())) {
|
|
|
|
if(auto self = window->self()) {
|
|
|
|
bool enabled = !modalWindows || window->modal();
|
|
|
|
if(IsWindowEnabled(self->hwnd) != enabled) {
|
|
|
|
EnableWindow(self->hwnd, enabled);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-07-16 06:16:26 +00:00
|
|
|
auto pWindow::_statusHeight() const -> int {
|
|
|
|
int height = 0;
|
|
|
|
if(auto& statusBar = state().statusBar) {
|
|
|
|
if(statusBar->visible()) {
|
|
|
|
auto& text = statusBar->state.text;
|
|
|
|
height = statusBar->font(true).size(text ? text : " ").height();
|
|
|
|
height = max(height, minimumStatusHeight);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return height;
|
|
|
|
}
|
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
2015-06-12 13:14:38 +00:00
|
|
|
|
|
|
|
#endif
|