2015-12-30 06:41:46 +00:00
|
|
|
#if defined(Hiro_Window)
|
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
@implementation CocoaWindow : NSWindow
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
-(id) initWith:(hiro::mWindow&)windowReference {
|
2013-03-15 13:11:33 +00:00
|
|
|
window = &windowReference;
|
|
|
|
|
|
|
|
NSUInteger style = NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask;
|
|
|
|
if(window->state.resizable) style |= NSResizableWindowMask;
|
|
|
|
|
|
|
|
if(self = [super initWithContentRect:NSMakeRect(0, 0, 640, 480) styleMask:style backing:NSBackingStoreBuffered defer:YES]) {
|
|
|
|
[self setDelegate:self];
|
|
|
|
[self setReleasedWhenClosed:NO];
|
|
|
|
[self setAcceptsMouseMovedEvents:YES];
|
|
|
|
[self setTitle:@""];
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
NSBundle* bundle = [NSBundle mainBundle];
|
|
|
|
NSDictionary* dictionary = [bundle infoDictionary];
|
|
|
|
NSString* applicationName = [dictionary objectForKey:@"CFBundleDisplayName"];
|
2015-12-30 06:41:46 +00:00
|
|
|
if(applicationName == nil) applicationName = [NSString stringWithUTF8String:hiro::Application::state.name];
|
2013-04-09 13:31:46 +00:00
|
|
|
|
2013-03-19 08:48:50 +00:00
|
|
|
menuBar = [[NSMenu alloc] init];
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
NSMenuItem* item;
|
2013-03-15 13:11:33 +00:00
|
|
|
string text;
|
|
|
|
|
|
|
|
rootMenu = [[NSMenu alloc] init];
|
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:@"" action:nil keyEquivalent:@""] autorelease];
|
|
|
|
[item setSubmenu:rootMenu];
|
2013-03-19 08:48:50 +00:00
|
|
|
[menuBar addItem:item];
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2013-04-09 13:31:46 +00:00
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:[NSString stringWithFormat:@"About %@ ...", applicationName] action:@selector(menuAbout) keyEquivalent:@""] autorelease];
|
|
|
|
[item setTarget:self];
|
2013-03-15 13:11:33 +00:00
|
|
|
[rootMenu addItem:item];
|
|
|
|
[rootMenu addItem:[NSMenuItem separatorItem]];
|
|
|
|
|
2016-01-08 09:23:46 +00:00
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:@"Preferences ..." action:@selector(menuPreferences) keyEquivalent:@""] autorelease];
|
2013-04-09 13:31:46 +00:00
|
|
|
[item setTarget:self];
|
|
|
|
[rootMenu addItem:item];
|
2016-01-08 09:23:46 +00:00
|
|
|
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
string result = nall::execute("spctl", "--status").output.strip();
|
|
|
|
if(result != "assessments disabled") {
|
|
|
|
disableGatekeeper = [[[NSMenuItem alloc] initWithTitle:@"Disable Gatekeeper" action:@selector(menuDisableGatekeeper) keyEquivalent:@""] autorelease];
|
|
|
|
[disableGatekeeper setTarget:self];
|
|
|
|
[rootMenu addItem:disableGatekeeper];
|
2016-01-08 09:23:46 +00:00
|
|
|
}
|
|
|
|
|
2013-04-09 13:31:46 +00:00
|
|
|
[rootMenu addItem:[NSMenuItem separatorItem]];
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
NSMenu* servicesMenu = [[[NSMenu alloc] initWithTitle:@"Services"] autorelease];
|
2013-04-09 13:31:46 +00:00
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:@"Services" action:nil keyEquivalent:@""] autorelease];
|
|
|
|
[item setTarget:self];
|
|
|
|
[item setSubmenu:servicesMenu];
|
|
|
|
[rootMenu addItem:item];
|
|
|
|
[rootMenu addItem:[NSMenuItem separatorItem]];
|
|
|
|
[NSApp setServicesMenu:servicesMenu];
|
|
|
|
|
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:[NSString stringWithFormat:@"Hide %@", applicationName] action:@selector(hide:) keyEquivalent:@""] autorelease];
|
|
|
|
[item setTarget:NSApp];
|
|
|
|
[rootMenu addItem:item];
|
|
|
|
|
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:@"Hide Others" action:@selector(hideOtherApplications:) keyEquivalent:@""] autorelease];
|
|
|
|
[item setTarget:NSApp];
|
|
|
|
[rootMenu addItem:item];
|
|
|
|
|
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:@"Show All" action:@selector(unhideAllApplications:) keyEquivalent:@""] autorelease];
|
|
|
|
[item setTarget:NSApp];
|
2013-03-15 13:11:33 +00:00
|
|
|
[rootMenu addItem:item];
|
2016-01-08 09:23:46 +00:00
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
[rootMenu addItem:[NSMenuItem separatorItem]];
|
|
|
|
|
2013-04-09 13:31:46 +00:00
|
|
|
item = [[[NSMenuItem alloc] initWithTitle:[NSString stringWithFormat:@"Quit %@", applicationName] action:@selector(menuQuit) keyEquivalent:@""] autorelease];
|
|
|
|
[item setTarget:self];
|
2013-03-15 13:11:33 +00:00
|
|
|
[rootMenu addItem:item];
|
2013-03-21 12:59:01 +00:00
|
|
|
|
|
|
|
statusBar = [[NSTextField alloc] initWithFrame:NSMakeRect(0, 0, 0, 0)];
|
|
|
|
[statusBar setAlignment:NSLeftTextAlignment];
|
|
|
|
[statusBar setBordered:YES];
|
|
|
|
[statusBar setBezeled:YES];
|
|
|
|
[statusBar setBezelStyle:NSTextFieldSquareBezel];
|
|
|
|
[statusBar setEditable:NO];
|
|
|
|
[statusBar setHidden:YES];
|
|
|
|
|
|
|
|
[[self contentView] addSubview:statusBar positioned:NSWindowBelow relativeTo:nil];
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
|
|
|
-(BOOL) canBecomeKeyWindow {
|
|
|
|
return YES;
|
|
|
|
}
|
|
|
|
|
|
|
|
-(BOOL) canBecomeMainWindow {
|
|
|
|
return YES;
|
|
|
|
}
|
|
|
|
|
2013-03-21 12:59:01 +00:00
|
|
|
-(void) windowDidBecomeMain:(NSNotification*)notification {
|
2015-12-30 06:41:46 +00:00
|
|
|
if(window->state.menuBar) {
|
2013-03-19 08:48:50 +00:00
|
|
|
[NSApp setMainMenu:menuBar];
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-21 12:59:01 +00:00
|
|
|
-(void) windowDidMove:(NSNotification*)notification {
|
2015-12-30 06:41:46 +00:00
|
|
|
if(auto p = window->self()) p->moveEvent();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2013-03-21 12:59:01 +00:00
|
|
|
-(void) windowDidResize:(NSNotification*)notification {
|
2015-12-30 06:41:46 +00:00
|
|
|
if(auto p = window->self()) p->sizeEvent();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2013-03-21 12:59:01 +00:00
|
|
|
-(BOOL) windowShouldClose:(id)sender {
|
2015-12-30 06:41:46 +00:00
|
|
|
if(window->state.onClose) window->doClose();
|
2013-03-15 13:11:33 +00:00
|
|
|
else window->setVisible(false);
|
|
|
|
if(window->state.modal && !window->visible()) window->setModal(false);
|
|
|
|
return NO;
|
|
|
|
}
|
|
|
|
|
2013-07-29 09:42:45 +00:00
|
|
|
-(NSDragOperation) draggingEntered:(id<NSDraggingInfo>)sender {
|
|
|
|
return DropPathsOperation(sender);
|
|
|
|
}
|
|
|
|
|
|
|
|
-(BOOL) performDragOperation:(id<NSDraggingInfo>)sender {
|
2016-07-01 11:58:12 +00:00
|
|
|
auto paths = DropPaths(sender);
|
2016-05-04 10:07:13 +00:00
|
|
|
if(!paths) return NO;
|
2015-12-30 06:41:46 +00:00
|
|
|
window->doDrop(paths);
|
2013-07-29 09:42:45 +00:00
|
|
|
return YES;
|
|
|
|
}
|
|
|
|
|
2013-03-19 08:48:50 +00:00
|
|
|
-(NSMenu*) menuBar {
|
|
|
|
return menuBar;
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
-(void) menuAbout {
|
2015-12-30 06:41:46 +00:00
|
|
|
hiro::Application::Cocoa::doAbout();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
-(void) menuPreferences {
|
2015-12-30 06:41:46 +00:00
|
|
|
hiro::Application::Cocoa::doPreferences();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
//to hell with gatekeepers
|
|
|
|
-(void) menuDisableGatekeeper {
|
2016-01-08 09:23:46 +00:00
|
|
|
NSAlert* alert = [[[NSAlert alloc] init] autorelease];
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
[alert setMessageText:@"Disable Gatekeeper"];
|
|
|
|
|
|
|
|
AuthorizationRef authorization;
|
|
|
|
OSStatus status = AuthorizationCreate(nullptr, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authorization);
|
|
|
|
if(status == errAuthorizationSuccess) {
|
|
|
|
AuthorizationItem items = {kAuthorizationRightExecute, 0, nullptr, 0};
|
|
|
|
AuthorizationRights rights = {1, &items};
|
|
|
|
status = AuthorizationCopyRights(authorization, &rights, nullptr,
|
|
|
|
kAuthorizationFlagDefaults
|
|
|
|
| kAuthorizationFlagInteractionAllowed
|
|
|
|
| kAuthorizationFlagPreAuthorize
|
|
|
|
| kAuthorizationFlagExtendRights, nullptr);
|
|
|
|
if(status == errAuthorizationSuccess) {
|
|
|
|
{ char program[] = "/usr/sbin/spctl";
|
2018-07-02 01:55:42 +00:00
|
|
|
char* arguments[] = {"--master-disable", nullptr};
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
FILE* pipe = nullptr;
|
|
|
|
AuthorizationExecuteWithPrivileges(authorization, program, kAuthorizationFlagDefaults, arguments, &pipe);
|
|
|
|
}
|
|
|
|
{ char program[] = "/usr/bin/defaults";
|
2018-07-02 01:55:42 +00:00
|
|
|
char* arguments[] = {"write /Library/Preferences/com.apple.security GKAutoRearm -bool NO"};
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
FILE* pipe = nullptr;
|
|
|
|
AuthorizationExecuteWithPrivileges(authorization, program, kAuthorizationFlagDefaults, arguments, &pipe);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
AuthorizationFree(authorization, kAuthorizationFlagDefaults);
|
|
|
|
}
|
2016-01-08 09:23:46 +00:00
|
|
|
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
string result = nall::execute("spctl", "--status").output.strip();
|
|
|
|
if(result == "assessments disabled") {
|
2016-01-08 09:23:46 +00:00
|
|
|
[alert setAlertStyle:NSInformationalAlertStyle];
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
[alert setInformativeText:@"Gatekeeper has been successfully disabled."];
|
|
|
|
[disableGatekeeper setHidden:YES];
|
2016-01-08 09:23:46 +00:00
|
|
|
} else {
|
|
|
|
[alert setAlertStyle:NSWarningAlertStyle];
|
Update to v106r33 release.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
|
|
|
[alert setInformativeText:@"Error: failed to disable Gatekeeper."];
|
2016-01-08 09:23:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
[alert addButtonWithTitle:@"Ok"];
|
|
|
|
[alert runModal];
|
|
|
|
}
|
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
-(void) menuQuit {
|
2015-12-30 06:41:46 +00:00
|
|
|
hiro::Application::Cocoa::doQuit();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2013-03-21 12:59:01 +00:00
|
|
|
-(NSTextField*) statusBar {
|
|
|
|
return statusBar;
|
|
|
|
}
|
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
@end
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
namespace hiro {
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::construct() -> void {
|
|
|
|
@autoreleasepool {
|
|
|
|
cocoaWindow = [[CocoaWindow alloc] initWith:self()];
|
2016-01-08 09:23:46 +00:00
|
|
|
|
|
|
|
static bool once = true;
|
|
|
|
if(once) {
|
|
|
|
once = false;
|
|
|
|
[NSApp setMainMenu:[cocoaWindow menuBar]];
|
|
|
|
}
|
2015-12-30 06:41:46 +00:00
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::destruct() -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
2015-12-30 06:41:46 +00:00
|
|
|
[cocoaWindow release];
|
2013-03-15 13:11:33 +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 {
|
2015-12-30 06:41:46 +00:00
|
|
|
}
|
2013-03-15 13:11:33 +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 {
|
2018-07-16 06:16:26 +00:00
|
|
|
sizable->setGeometry(self().geometry().setPosition());
|
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
|
|
|
statusBarReposition();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::append(sStatusBar statusBar) -> void {
|
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
|
|
|
statusBar->setEnabled(statusBar->enabled(true));
|
|
|
|
statusBar->setFont(statusBar->font(true));
|
|
|
|
statusBar->setText(statusBar->text());
|
|
|
|
statusBar->setVisible(statusBar->visible(true));
|
2015-12-30 06:41:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::focused() const -> bool {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
return [cocoaWindow isMainWindow] == YES;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::frameMargin() const -> Geometry {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
NSRect frame = [cocoaWindow frameRectForContentRect:NSMakeRect(0, 0, 640, 480)];
|
2015-12-30 06:41:46 +00:00
|
|
|
return {abs(frame.origin.x), (int)(frame.size.height - 480), (int)(frame.size.width - 640), abs(frame.origin.y)};
|
2013-03-15 13:11:33 +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 {
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::remove(sSizable sizable) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
[[cocoaWindow contentView] setNeedsDisplay:YES];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::remove(sStatusBar statusBar) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
|
|
|
[[cocoaWindow statusBar] setHidden:YES];
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setBackgroundColor(Color color) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
[cocoaWindow
|
|
|
|
setBackgroundColor:[NSColor
|
2015-12-30 06:41:46 +00:00
|
|
|
colorWithCalibratedRed:color.red() / 255.0
|
|
|
|
green:color.green() / 255.0
|
|
|
|
blue:color.blue() / 255.0
|
|
|
|
alpha:color.alpha() / 255.0
|
2013-03-15 13:11:33 +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 {
|
|
|
|
//todo: not implemented
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setDroppable(bool droppable) -> void {
|
2013-07-29 09:42:45 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
if(droppable) {
|
|
|
|
[cocoaWindow registerForDraggedTypes:[NSArray arrayWithObject:NSFilenamesPboardType]];
|
|
|
|
} else {
|
|
|
|
[cocoaWindow unregisterDraggedTypes];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setFocused() -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
[cocoaWindow makeKeyAndOrderFront:nil];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setFullScreen(bool fullScreen) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
2016-01-08 09:23:46 +00:00
|
|
|
if(fullScreen) {
|
|
|
|
windowedGeometry = state().geometry;
|
2013-03-15 13:11:33 +00:00
|
|
|
[NSApp setPresentationOptions:NSApplicationPresentationFullScreen];
|
|
|
|
[cocoaWindow setCollectionBehavior:NSWindowCollectionBehaviorFullScreenPrimary];
|
|
|
|
[cocoaWindow toggleFullScreen:nil];
|
2016-01-08 09:23:46 +00:00
|
|
|
state().geometry = _geometry();
|
2013-03-15 13:11:33 +00:00
|
|
|
} else {
|
|
|
|
[cocoaWindow toggleFullScreen:nil];
|
|
|
|
[cocoaWindow setCollectionBehavior:NSWindowCollectionBehaviorDefault];
|
|
|
|
[NSApp setPresentationOptions:NSApplicationPresentationDefault];
|
2016-01-08 09:23:46 +00:00
|
|
|
state().geometry = windowedGeometry;
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setGeometry(Geometry geometry) -> void {
|
|
|
|
lock();
|
2013-03-15 13:11:33 +00:00
|
|
|
|
|
|
|
@autoreleasepool {
|
|
|
|
[cocoaWindow
|
|
|
|
setFrame:[cocoaWindow
|
2013-03-21 12:59:01 +00:00
|
|
|
frameRectForContentRect:NSMakeRect(
|
2015-12-30 06:41:46 +00:00
|
|
|
geometry.x(), Desktop::size().height() - geometry.y() - geometry.height(),
|
|
|
|
geometry.width(), geometry.height() + statusBarHeight()
|
2013-03-21 12:59:01 +00:00
|
|
|
)
|
2013-03-15 13:11:33 +00:00
|
|
|
]
|
|
|
|
display:YES
|
|
|
|
];
|
|
|
|
|
2018-07-16 06:16:26 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
sizable->setGeometry(self().geometry().setPosition());
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
2013-03-21 12:59:01 +00:00
|
|
|
|
|
|
|
statusBarReposition();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
unlock();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2018-07-08 04:58:27 +00:00
|
|
|
auto pWindow::setMaximized(bool maximized) -> void {
|
|
|
|
//todo
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setMaximumSize(Size size) -> void {
|
|
|
|
//todo
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setMinimized(bool minimized) -> void {
|
|
|
|
//todo
|
|
|
|
}
|
|
|
|
|
|
|
|
auto pWindow::setMinimumSize(Size size) -> void {
|
|
|
|
//todo
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setModal(bool modal) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
if(modal == true) {
|
|
|
|
[NSApp runModalForWindow:cocoaWindow];
|
|
|
|
} else {
|
|
|
|
[NSApp stopModal];
|
2013-05-02 11:25:45 +00:00
|
|
|
NSEvent* event = [NSEvent otherEventWithType:NSApplicationDefined location:NSMakePoint(0, 0) modifierFlags:0 timestamp:0.0 windowNumber:0 context:nil subtype:0 data1:0 data2:0];
|
2013-03-15 13:11:33 +00:00
|
|
|
[NSApp postEvent:event atStart:true];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setResizable(bool resizable) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
NSUInteger style = NSTitledWindowMask | NSClosableWindowMask | NSMiniaturizableWindowMask;
|
|
|
|
if(resizable) style |= NSResizableWindowMask;
|
|
|
|
[cocoaWindow setStyleMask:style];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setTitle(const string& text) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
[cocoaWindow setTitle:[NSString stringWithUTF8String:text]];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::setVisible(bool visible) -> void {
|
2013-03-15 13:11:33 +00:00
|
|
|
@autoreleasepool {
|
2013-03-21 12:59:01 +00:00
|
|
|
if(visible) [cocoaWindow makeKeyAndOrderFront:nil];
|
|
|
|
else [cocoaWindow orderOut:nil];
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::moveEvent() -> void {
|
|
|
|
if(!locked() && !self().fullScreen() && self().visible()) {
|
|
|
|
@autoreleasepool {
|
|
|
|
NSRect area = [cocoaWindow contentRectForFrameRect:[cocoaWindow frame]];
|
|
|
|
area.size.height -= statusBarHeight();
|
|
|
|
state().geometry.setX(area.origin.x);
|
|
|
|
state().geometry.setY(Desktop::size().height() - area.origin.y - area.size.height);
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
if(!locked()) self().doMove();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::sizeEvent() -> void {
|
|
|
|
if(!locked() && !self().fullScreen() && self().visible()) {
|
|
|
|
@autoreleasepool {
|
|
|
|
NSRect area = [cocoaWindow contentRectForFrameRect:[cocoaWindow frame]];
|
|
|
|
area.size.height -= statusBarHeight();
|
|
|
|
state().geometry.setWidth(area.size.width);
|
|
|
|
state().geometry.setHeight(area.size.height);
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2018-07-16 06:16:26 +00:00
|
|
|
if(auto& sizable = state().sizable) {
|
|
|
|
sizable->setGeometry(self().geometry().setPosition());
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2013-03-21 12:59:01 +00:00
|
|
|
statusBarReposition();
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
if(!locked()) self().doSize();
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::statusBarHeight() -> uint {
|
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
|
|
|
if(auto& statusBar = state().statusBar) {
|
2016-01-07 08:14:33 +00:00
|
|
|
if(statusBar->visible()) {
|
|
|
|
return pFont::size(statusBar->font(true), " ").height() + 6;
|
|
|
|
}
|
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
|
|
|
}
|
2015-12-30 06:41:46 +00:00
|
|
|
return 0;
|
2013-03-21 12:59:01 +00:00
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::statusBarReposition() -> void {
|
2013-03-21 12:59:01 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
NSRect area = [cocoaWindow contentRectForFrameRect:[cocoaWindow frame]];
|
|
|
|
[[cocoaWindow statusBar] setFrame:NSMakeRect(0, 0, area.size.width, statusBarHeight())];
|
|
|
|
[[cocoaWindow contentView] setNeedsDisplay:YES];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-30 06:41:46 +00:00
|
|
|
auto pWindow::_append(mWidget& widget) -> void {
|
|
|
|
@autoreleasepool {
|
|
|
|
if(auto pWidget = widget.self()) {
|
|
|
|
[pWidget->cocoaView removeFromSuperview];
|
|
|
|
[[cocoaWindow contentView] addSubview:pWidget->cocoaView positioned:NSWindowAbove relativeTo:nil];
|
|
|
|
pWidget->setGeometry(widget.geometry());
|
|
|
|
[[cocoaWindow contentView] setNeedsDisplay:YES];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-08 09:23:46 +00:00
|
|
|
auto pWindow::_geometry() -> Geometry {
|
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
|
|
|
@autoreleasepool {
|
|
|
|
NSRect area = [cocoaWindow contentRectForFrameRect:[cocoaWindow frame]];
|
|
|
|
area.size.height -= statusBarHeight();
|
2016-01-08 09:23:46 +00:00
|
|
|
return {
|
|
|
|
(int)area.origin.x, (int)(Monitor::geometry(Monitor::primary()).height() - area.origin.y - area.size.height),
|
|
|
|
(int)area.size.width, (int)area.size.height
|
|
|
|
};
|
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
2016-01-05 02:59:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
2015-12-30 06:41:46 +00:00
|
|
|
|
|
|
|
#endif
|