hi all. is there any new updates for bizhawk? i am keen to get bizhawk running again. i would love to see a workable version for the latest version of Mac <3
I mentioned back in June 2020 that I had stopped working on it. No one else has expressed interest in taking that over:
http://tasvideos.org/forum/viewtopic.php?p=496190#496190
I don't really have time to be looking at it again, but it's been long enough since I've touched it that I might want to re-fork the latest code and see what state it's in. The awkward situation with the user interface support on Mac hasn't changed since then, I've been subscribed to one of the GitHub threads about that. But as of the last time I checked (around 9 months ago) the awful approach that I was using before is still working.
I also still get emails from the Issue tracker on GitHub, so I'm not entirely in the dark but I haven't really paid attention to what's going on at all for over a year now.
okay no luck. i will just have to wait for a fixed copy to be made.
It's fixed now, for real this time. I replaced the file at the link above with a proper build and actually downloaded & tested it.
It's also code signed & notarized by Apple now, so no gatekeeper work-arounds are required to run it. The previous build was not working because it was partially signed but I was having problems getting Apple's service to validate it so I gave up and released it without completing the process. I assumed the app would still work and just warn you that the signature was invalid, but instead it claims to be corrupt. What I should have done was remove the signatures from everything, but I didn't know that was the problem initially because it ran on my machine since it was built there.
Going forward, if there ever is another release from me, this shouldn't be a problem.
Lessons learned: (Note to self)
1. If distributing an unsigned build, make sure it's not signed.
2. Trying to manually re-sign a build after Visual Studio signs it breaks the app and it won't launch. To release a signed build, "Archive" it in Visual Studio, then open the organizer in XCode and use XCode to upload it to Apple's notary service. XCode will re-sign the entire archive for me prior to submission, and it doesn't break like when I do it manually. I used to code sign builds manually before the notary service was a thing, but I guess I don't need to do it manually anymore.
Edit: i get an error saying that disck imagine is broken. have you copmiled this properly at all?
It is valid, I just downloaded and tested it.
But I do see one problem I've ran into in the past: Apple makes disk images APFS by default on Catalina. If you're running a version of macOS that is too old for the APFS filesystem, (10.12 or older) then the image is seen as invalid.
I have converted the image to MacOS Extended (HFS+) and re-uploaded it.
Thanks for taking the time to make this. It looks like a good start towards getting BizHawk to work on MacOS. From testing out this version of BizHawk on my Mac on Catalina, I did find the following errors that I wanted to bring up, in case you hadn't found them yet.
1. Atari 2600 games won't load on this version. More specifically, they cause a NullReferenceException to be thrown. The exact error message begins "System.NullReferenceException: Object reference not set to an instance of an object at BizHawk.Common.SettingsUtil.CreateSetter(System.Type t) ...". I tested this for the games Pitfall!, RoadRunner, and Adventure and all 3 couldn't load.
Here's a new macOS build with the arbitrary version number of 1.13.4 which doesn't really match any PC releases. Compatible with macOS Catalina.
https://projects.sappharad.com/bizhawk_mac/BizHawk_mac64_1.13.4.dmg
It is code signed and notarized now, so you don't need to use any tricks to run it. Be sure to copy it out of the disk image first through, it can't load roms from inside because settings are saved inside the app bundle.
Changes:
1. It fixes Atari 2600 which you noted was broken.
2. It also backported a handful of changes to Genesis Plus GX, some of which aren't even in the current BizHawk 2.0 windows release. These fixes are needed to run Esrael's Sonic Delta 40mbit romhack and SRAM support is working as well. There were some other random games that got fixed as well, I basically just grabbed the latest versions of some files needed to get Sonic Delta working & merged other changes that were needed for the files I grabbed to build. In other words, some new things are there and others are not. It's a grab bag.
3. It removes the dependency on Nvidia's cgc, which was wasting 27MB inside the download. I got rid of this because it was preventing me from code signing, because it's built for such an old OS version and hasn't been updated in 8 years, but then didn't end up trying to code sign again.
SNES is still acting weird and unplayable. The other bugs are not fixed.
====
At this point Microsoft / Xamarin still has no plans to officially or unofficially support WinForms on 64-bit macOS, even with the upcoming .NET 5. I'm still stuck building modified forks of WinForms and OpenTK and heavily butchering the app to make it work with them. I know a bunch of work has gone into getting BizHawk 2.x to work on Linux, but I have not looked at those changes lately or had time to see if they would help some of the newer cores work on macOS.
It's safe to say that work on the macOS port has stopped. If anyone wants to take over, let me know and I can go over the awkward and complicated work-arounds necessary to even get it to compile and run as a 64-bit application. (The OpenTK fork is on my GitHub)
In the meantime, I may will pop in every once and awhile, but it will just be for random little things that I want to fix. In the event Apple switches future Macs to ARM processors, I'll see if I can provide an equivalent build of what I just released for those later, provided they don't remove even more outdated API's. (Example: I'm not even using OpenTK for keyboard input in the last 2 releases because it broke in Catalina and OpenTK isn't updating 3.x anymore)
Here's a macOS build of 1.13.2. Compatible with macOS Catalina.
https://projects.sappharad.com/bizhawk_mac/BizHawk_mac64_1.13.2.dmg
Note: Unlike the last several releases, this build is not signed. And it's not notarized either. You'll need to right click -> Open the first time you run it to bypass Gatekeeper. I could have gone through the steps to try, but it would have taken some extra time and I might end up doing another build if we can fix SNES.
All systems supported by the macOS release of 1.13.1 should be supported here, including PSX, MegaDrive / Sega CD, NES, GBA, Wonderswan, etc.
SNES runs, but you won't see any video for it, just sound. It's a side effect of porting to 64-bit that I couldn't figure out how to fix and I don't really care to try more right now. It sounds like there's been a lot of progress on the Linux port recently, so maybe that will help get a full build of 2.0 running.
In the meantime, this is at least something. Enjoy?
It was my intention to post something about this maybe 3 weeks ago, but I keep running out of time and/or forgetting. None of the builds released thus far actually work on macOS 10.15 Catalina released last month.
The 1.x series was 32-bit, thus not compatible with macOS Catalina which dropped support for 32-bit apps. The 2.3 alpha above is 64-bit, but for some reason keyboard input doesn't work, possibly due to new security changes because I noticed macOS requires you to allow an exemption for system wide keyboard access when running that build. (Keyboard still doesn't work if you allow it.)
Keyboard and Gamepad Input are handled via OpenTK 3, but the macOS implementation doesn't seem to work correctly on Catalina. The next version (OpenTK 4) is not released or ready, and they don't want to fix bugs in OpenTK 3 or release new versions of that. I don't even know if anyone has reported keyboard being broken. Ideally I would have fixed it myself in my fork of OpenTK 3, but their implementation of keyboard is low level and doesn't give me access to the native macOS keyboard API and I don't really want to try and solve that. Instead of I've re-implemented keyboard input from scratch using the native API and kind of hacked it into BizHawk from the outside. This is not a good solution, but I finally have it working.
My plan over the next few weeks is to release 2 builds. A 64-bit port of 1.13.2, with all of the cores that were previously supported, and a new 'beta' build of BizHawk 2, with whatever works at the time.
1.13.2 is working, including some native cores like Genesis / MegaCD. I need to get all of the previously supported cores built as 64-bit and hook those up, then I will release a build. Following that, 2.0 can come at some point.
Some things fixed so far since the last "alpha" build I posted:
1. Works on Catalina
2. Controller config works
3. Dark mode on Mojave and Catalina is supported.
4. Doesn't crash when you exit.
New BizHawk 2.3 macOS alpha build. EXTREMELY POOR QUALITY use at own risk!
https://projects.sappharad.com/bizhawk_mac/BizHawk_mac_2.3.0_alpha.dmgDoes NOT replace 1.13.1, build only being provided because I'm going to archive the changes and start over against the latest code now that a bunch of stuff was changed in master to improve Linux support. The direction I went previously differs from the approach to multi-platform support that's being used in current development, and starting again is the best option. Going forward there should need to be fewer macOS specific hacks (still going to need some platform specific code) which will make my life easier.
Problems and limitations of this build:
* It will crash when you try to exit. Don't bother using the macOS crash reporter, no one will get the reports except Apple and it's not their fault so they can't do anything about it.
* Control configuration is broken, you won't see any buttons to configure. You're stuck with default buttons!
* Several consoles supported in the previous build are NOT supported in this build. For example, Genesis/MegaDrive and SuperNES no longer work.
* The menus are messed up. Every option is always enabled.
* Do not try to resize the window manually, it might get stuck in resize mode forever.
* Gamepad support is disabled, because I forgot to enable and test that again.
* ...and more!
Benefits to using this release:
* You can play NES games, Gameboy Games, GameGear, and a few other systems too.
* It's 64-bit, so you won't see the "This application is not optimized for your computer" on macOS 10.13 and later anymore.
* You no longer need to install Mono. Everything needed is bundled inside the app. This made the app over twice as big, but is easier to install going forward.
* Windows and dialogs now contain native macOS controls, some of the time.
If you're like me and only use BizHawk to play games, this build can be used to do that. You're welcome to provide feedback if you want, but since I'm starting over any problems reported might not be relevant or get resolved on their own prior to next release.
Enjoy, maybe? No idea when I'll have something better to share and I've played NES games with this build so I thought I should dump it out there before things go back to a worse state for a bit.
I'll bump this with a long overdue progress update:
No new release yet, but maybe that will finally happen in 2019.
As mentioned in a previous update, when BizHawk went 64-bit in version 2.0 I was unable to use the existing UI because WinForms on macOS only supported 32-bit and it didn't look like they were ever going to update that because Microsoft doesn't officially support WinForms on MacOS. (BizHawk 1.x Mac builds were using the 32-bit Mono WInForms implementation that was written against the old macOS Windowing system that was deprecated over 10 years ago.) It didn't seem like anyone was going to create a 64-bit implementation against the modern APIs, so I had started EtoHawk which was going to be a brand new UI native to macOS & Linux. I had that barely working (Load Rom, configure controls, sound + input, that's it) but when I tried to implement OpenGL for video I ran into problems and got stuck for a few months where I could see the screen border color but not the actual video.
In September of last year, I discovered that some guy had released a 64-bit macOS implementation of WinForms earlier in the year that his company was using to port their product to Mac. Unlike the Mono implementation, this one substitutes native macOS controls (buttons, menus, checkboxes, open/save dialogs) whenever feasible. The only downside to this because it's a replacement for a system library, I either have to build my own separate copy of Mono to use it as if it were built-in, or fork BizHawk to reference the unofficial version which makes the same code not build against Windows. I chose the latter, so that anyone else can check out the code for my fork and build it without needing an entirely different version of Mono.
After getting BizHawk running against it (as seen in the screenshot from last September) I had to fork OpenTK as well and port the OpenTK WinForms GLControl to work against the special Cocoa macOS WinForms implementation. Because I'm not very good at OpenGL, I had to throw some small hacks into BizHawk to get the native control / view handles, and also support 2x+ scaling for Retina displays. 64-Bit QuickNES is running again, so that's great.
What's left:
- Broken UI stuff, worse than before. For example controls don't appear in the control dialog to map them right now. (But the defaults mostly work.) Also, right now the menus are eating inputs from buttons that overlap to them, in other words if something is mapped to C and you press that, the config menu actually opens. I need to make sure that when the video has focus that the menus don't eat keyboard inputs.
- Rest of the previously supported native cores. QuickNES is working, it was the first one I did.
- Re-enable gamepad support. It's commented out right now just because I didn't feel like plugging in controllers to re-implement and test that.
- Some stability issues, but also caused by UI stuff.
- Menus are still native, but they're attached to the window like a Windows application. I may or may not fix this and put them back at the top of the screen.
Advantages of the new version so far over 1.x:
- Supports Retina displays, as pictured above. (View full image if using a normal monitor)
- UI is faster and more responsive. No more sluggish menus, windows usually draw faster.
- 64-bit. It will still work when Apple drops support for 32-bit applications in the next release of macOS, 10.15, which is due in September or October of 2019.
- It can be built using the Xamarin.Mac Linker. This results in a massive executable (probably twice the size of the last 1.x release... sorry) but you no longer need to install the Mono runtime to run the app. It automatically includes only the parts needed to run the app, so you can just download and install on a new machine without worrying about Mono.
I'll try to post another update in a few months, but I am still committing to the fork on my GitHub if another developer wants to build their own copy. My OpenTK fork is also checked in under a branch for the Cocoa WinForms GLControl. (But the binaries are committed to the BizHawk fork, so you don't need to build your own copy of that)
Under Config->Speed/Skip, which throttle method are you using?
Have you tried audio throttle instead? There are reasons this could be a bad suggestion, but maybe there's a sync issue such as your monitor's refresh rate differing from the console being emulated?
Yes. But deprecated doesn't mean removed, it just means they don't want people to use it anymore and won't be updating it. There are some APIs that have been deprecated for over 10 years that still work fine because they need to keep them for backwards compatibility with old applications.
It's possible for them to remove it someday, but it's very unlikely at least for several years. The most logical time for them to do something evil like that would be when they stop using Intel processors and switch to their own in-house processors rumored for 2020 or later, because at that point they'd be dropping other backwards compatibility as a result anyway.
There's an open source port of Vulkan to macOS that Valve uses for some of their games now; performance on that is better than OpenGL. It will probably be an option at some point. In the event they actually plan to drop OpenGL, I'll worry about it then.
Edit:
Update 2018-Dec-11 - I finally have the OpenTK GLControl working against the unofficial 64-bit macOS Cocoa WinForms implementation. This means Video + Sound are working again. But I've been using a version of OpenTK that's over a year old, so I now need to re-implement my changes against the latest version of OpenTK and not make a bunch of hacks everywhere in BizHawk to use them.
Now that games are actually playable again, I'm probably less than 6 months away from having a new release ready. (Still working on this only an hour or two a week)
r57shell has some knowledge of opengl. I saw you questions on IRC, and he shared some ideas, but I couldn't catch you there live. He's occasionally on IRC, but you can try forum PM too.
It's kind of irrelevant at this point unless someone prefers that I try to continue down the path of an Eto frontend. Using WinForms saves me so much time re-implementing all of the UI stuff, despite it not being as good as native.
If someone else wants to play with it, the EtoHawk solution is in BizHawk.Client.EtoHawk and it will compile on Windows to both WinForms and WPF:
https://github.com/Sappharad/BizHawk
But I'm not looking at it right now in favor of WinForms. I'm willing to change my mind again, so I can stop by IRC again on Tuesday to discuss it further.
Not really. I have nothing really new to share, other than this screenshot from 2 weeks ago:
http://projects.sappharad.com/bizhawk_mac/bh2_macOS_64bitWinForms.png
I gave up on writing a native Mac UI for BizHawk because I ran into problems getting OpenGL to work correctly and after 2 months of being stuck (I only work on it one night every week) I decided to give up and go back to the original approach of using the Windows UI. The problem I got stuck on was some texture weirdness with OpenGL - the border color for systems that have one like GameGear was showing correctly, but the actual display was just a blank rectangle. The texture it needed to use was there, it just wasn't making it to output, even on a Windows build. I think it may have had something to do with pixel shaders but that's where I stopped before switching approaches.
It wasn't possible to use the Windows UI on 64-bit applications a year ago, and I wasn't expecting it to be possible, but earlier this year it did become an option again. Someone created a new port of WinForms for MacOS that supports 64-bit and even substitutes native Mac controls in some places. This gives native buttons, checkboxes, file dialogs, and some other things without me having to write a wrapper like the old Mac builds. The only thing it doesn't have that the previous Mac builds had was native menus. I started over with this approach about 3 weeks ago, so no games even load or work right now. I'm running into problems getting Audio and Video to work with this new approach. Audio I'm not sure why because it should work, video requires more work on my end because I have to port the OpenGL control to be compatible with 64-bit Mac WinForms. (And the GDI option isn't feasible due to the WinForms port being incomplete)
In short, nothing has happened in a year because I started over twice. The remains of what happened with EtoHawk are on my github fork, but the new WinForms port has not been committed anywhere yet since it can't run any games yet.
I just added the missing builds to the versions that had entries.
As far as the builds on my site, I removed some of them a few years ago to save space. Here are is a full list of what I have locally, they may or may not exist in the folder on my site:
Jun 25 2017 BizHawk_mac_1.13.1.dmg
Jun 4 2017 BizHawk_mac_1.13.0.dmg
May 16 2017 BizHawk_mac_1.12.2.dmg
Apr 2 2017 BizHawk_mac_1.12.1.dmg
Feb 21 2017 BizHawk_mac_1.12.0.zip
Jan 3 2017 BizHawk_mac_1.11.9.zip
Oct 25 2016 BizHawk_mac_1.11.8.zip
Sep 1 2016 BizHawk_mac_1.11.7.zip
Mar 9 2016 BizHawk_mac_1.11.6.zip
Feb 15 2016 BizHawk_mac_1.11.5.zip
Dec 23 2015 BizHawk_mac_1.11.4.zip
Nov 17 2015 BizHawk_mac_1.11.3.zip
Jul 26 2015 BizHawk_mac_1.11.1.zip
Jul 19 2015 BizHawk_mac_1.11.0.zip
Jun 21 2015 BizHawk_mac_1.10.0.zip
Apr 6 2015 BizHawk_mac_1.9.4.zip
Mar 15 2015 BizHawk_mac_1.9.3.zip
Mar 4 2015 BizHawk_mac_1.9.2.zip
Nov 29 2014 BizHawk_mac_1.9.1.zip
Nov 23 2014 BizHawk_mac_1.9.0.zip
Oct 12 2014 BizHawk_mac_1.8.4.zip
Sep 23 2014 BizHawk_mac_1.8.2.zip
Aug 29 2014 BizHawk_mac_1.8.1.zip
Aug 26 2014 BizHawk_mac_1.8.0.zip
Aug 3 2014 BizHawk_mac_1.7.4.zip
Jul 22 2014 BizHawk_mac_1.7.3.zip
Jul 19 2014 BizHawk_mac_1.7.2.zip
Jun 22 2014 BizHawk_mac_1.7.1.zip
Jun 8 2014 BizHawk_mac_1.7.0.zip
Apr 1 2014 BizHawk_mac_1.6.1.zip
Feb 25 2014 BizHawk_mac_1.6.0.zip
Feb 20 2014 BizHawk_mac_1.6.0_beta.zip
Oct 20 2013 BizHawk_mac_1.5.2.zip
Aug 31 2013 BizHawk_mac_1.5.1.zip
Mar 25 2013 BizHawk_mac_1.4.1.zip
Dec 26 2012 BizHawk_mac_1.4.0.zip
Dec 1 2012 BizHawk_mac_1.3.0.zip
Oct 20 2012 BizHawk_mac_1.2.0.zip
Oct 8 2012 BizHawk_mac_1.1.1b.zip
Aug 3 2012 BizHawk_mac_1.0.5.zip
Jul 5 2012 BizHawk-1.0.4b-mac.zip
Jun 19 2012 BizHawk_mac_1.0.4a.zip
Jun 16 2012 BizHawk_mac_1.0.4.zip
Jun 16 2012 bizhawk-linux_1.0.4.tar.gz
Apr 14 2012 BizHawkMac_103a2.zip
is there still any way to allow my PS3 controller to be able to be read by bizhawk so i don't have to use my keyboard?
If this does not work,
http://osxdaily.com/2014/12/28/connect-playstation-3-controller-mac-os-x/
then no. New versions might have better support since I'm using a newer version of the library that allows controller support, but that's still a ways away. I'm averaging about 2 lines of code a week right now, it's not moving quickly.
Anyone who's interested in the work in progress can find my fork here and compile from source code:
https://github.com/Sappharad/BizHawk
It's under BizHawk.Client.EtoHawk. None of the native cores work and probably won't for some time, input mappings and firmware configs are not even saved, and video is not even hardware accelerated, but Game Gear and ColecoVision games are playable. Nothing is a specific priority right now, each week I do what I decide to do at that time.
Would this benefit a Genesis core? Since it uses a Z80? And Hoorah for accurate Sega stuff!
Are you suggesting something other than the existing GPGX core, which is already one of the best Genesis cores?
Alyosha wrote:
I guess it might help a little, but the z80 is probably only about 10% of the work associated with a genesis core. You'd also need the 68000, the sound and graphics chips, and all the infrastructure putting it together. I'd be willing to work on the 68000 but someone else would have to do everything else, I'm not that interested.
Not sure if you're aware, but there was already a C# Genesis core a few years back with that stuff, but it was highly buggy. It got replaced by GPGX. As to how complete/bad it was, someone has a video of it on YouTube here:
https://www.youtube.com/watch?v=eufJpZJjgfA
Even SSD presents a problem unless there's firmware to control the timing of it.
There are quite a few drive replacement projects for various CD based consoles now. I have one in my Dreamcast, which brings with it wonderfully improved load times. (But it has the ability to restrict to the original speeds via a setting) Even there it's not 100% predictable because the random read times on the flash media aren't 100% consistent. That could probably be accounted for in firmware of a drive simulator though, just have a consistent algorithm to decide the timing of various responses and if the medium you're reading from isn't ready in time too bad, fail completely.
The release notes for Bizhawk 1.12.0 seem to indicate that it's expected to run on OS X 10.9.5, but I'm getting an instant crash on startup with all 1.12.x versions under Mavericks. (1.11.x works.)
The Console log says:
"8/25/17 12:56:14.335 AM com.apple.launchd.peruser.501[152]: (org.tasvideos.BizHawk.104576[2604]) Exited with code: 1"
When I try to run the executable from the command line, I get the following, which may or may not be relevant:
Unhandled Exception:
System.MissingMethodException: Method 'Array.Empty' not found.
at MonoMac.AppKit.NSApplication.Init () <0x7d8780> in <filename>:0
at MonoMacWrapper.Program.Main (System.String[] args) <0x7d6f70> in <filename>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method 'Array.Empty' not found.
at MonoMac.AppKit.NSApplication.Init () <0x7d8780> in <filename>:0
at MonoMacWrapper.Program.Main (System.String[] args) <0x7d6f70> in <filename>:0
Also, do any more recent versions support the RAM Watch or RAM Search features in OS X? I tried using RAM Watch, but 1.11.9 simply crashes if you try to create a new watch, and RAM Search simply gives the same blank screen that earlier versions show for both RAM Watch and RAM Search.
I'm trying to find some way of auditing Game Boy RAM under OS X, but maybe it can't be done.
The version problem might be that you just need a newer version of the Mono runtime installed. It sounds like it can't find some .NET stuff, which a fresh mono install might fix.
No, most of the debugging tools haven't been fixed under macOS. You might be better off running the Windows version for that at the moment. Sorry about that.
=================
Update 2017-09-26
BizHawk for macOS is still dead at the moment. We need 64-bit compatibility to move forward, which meant switching from MonoMac to Xamarin.Mac. That's fine, but there's a compatibility issue between Xamarin.Mac and OpenTK which they know about but have no one to fix it. I have yet to figure out the cause, which is preventing this from continuing. Until I can actually get everything working again against a 64-bit Xamarin.Mac build, there will be no progress.
As I've previously mentioned, I'm only spending a couple hours each week on this right now. I'm not even working on the new UI, because if I can't compile it for macOS then what's the point.
Update 2017-10-31
I fixed the OpenTK issue, and now have a very basic native UI running GameGear games again. 64-bit like it needs to be. Hoping to have something basic done before the end of the year. It'll be a huge step back compared to the last 1.x release on macOS, but better than nothing.
it would be good to see an update of Bizhawk OSX. i wouldnt mind seeing N64 being ported over eventually.
I agree.
The cause of the 64-bit linker issue that I mentioned above has been resolved, it was the result of unused Lua DLL's that I hadn't excluded from the build. Work can now progress again on building a new UI so that 2.0+ can be brought over. Still not going to happen in the near future, but perhaps once the basics are hooked up again I can do a preview build.
Update 2017-08-16: Actually, the next time I worked on it after posting that, I migrated to the 2.0 codebase and ran into the same problem. Something besides Lua is causing the same problem in 2.0 now. :-(
I'll get it working some day...
That's a complicated question! xD I think it is the last version before ver. 2 was released.
I am not sure which version I pulled because I disable that annoying thing that generates the Version.cs file from SVN because I hate working with branches with git-svn...
Anyway, my version is rather different. I have merged the waterbox2 branch into master and mono-portable, to start getting the waterbox cores to work. I haven't moved my repo forward to the TASvideos repo yet, I'll do that after I get a waterbox core working.
If you want to replace the mono-portable branch with your own, let me know. I could either integrate your changes, or replace the branch completely.
At this point I'm only using it to test against the backend for EtoHawk just to have a place to commit those changes. But I haven't even made any progress there over the last 3 weeks, because I'm still trying to resolve a problem with the 64-bit linker on macOS. I need to come up with a minimal project to give them that reproduces the problem so they can fix it, but I have yet to isolate the cause. I suppose going forward I could just release some 32-bit builds of 2.0 WinForms with the waterbox cores missing, but that's not feasible long term since macOS will be dropping 32-bit support in 2 years.
(2017-06-25) Mac Build of 1.13.1 has been released:
http://projects.sappharad.com/bizhawk_mac/BizHawk_mac_1.13.1.dmg
Same changes as the Windows version, when applicable.
========================
This will be the last release of BizHawk on macOS in the near future. I have no estimate for when another release will happen, if it ever does.
With BizHawk 2.0 moving to 64-bit, I can't support the current UI on macOS anymore. It's based on WinForms still, and Mono does not support 64-bit WinForms on Mac. WinForms support in Mono was written back in 2005 against an API that was already considered deprecated at that time, (it only existed to provide compatibility with apps written for classic MacOS 9 and 8) and it was never re-written against the API that replaced it. Microsoft doesn't even advertise support for WinForms in Visual Studio on Mac (even though it works for 32-bit applications like the current release of BizHawk) and has no plans to ever add 64-bit WinForms in the future because they recommend building native UI's on each platform.
This leaves me with basically two options:
1. Port WinForms to 64-bit macOS myself. This is huge undertaking and I'm not familiar with the inner workings of the Windowing system on macOS that would be required to do such a thing. It would be a large amount of stuff to learn just to be able to get it running again, and then I'd also have to fork mono and offer custom builds of Mono with 64-bit WinForms support or distribute the entire WinForms implementation with every build.
2. Write a new UI from scratch. I did start this early last year, but abandoned it around April. There are so many features in BizHawk and I'm just interested in playing games with it. Most of the requests I get are for things I've never used, and it's much more fun to work on something in your spare time when you actually want it. This is probably the easiest option going forward but it's more work to maintain.
Trying to back-port 2.0 to 32-bit would be stupid, because Apple will be dropping support for 32-bit applications in macOS 10.15 which comes out in 2019.
tl;dr - Mono doesn't have things that I need to support BizHawk 2.0 on macOS, and adding them myself would be very time consuming. The current Mac port as it as right now is unlikely to continue. I haven't figured out what I'm going to do about it yet.
===============
Status Update (2017-07-16)
Option 2 above was deemed the most logical choice. The UI I mentioned previously has been partially updated so it at least builds and slightly works against 1.13.1's code, but it's still 32-bit only. I ran into a compiler bug in Visual Studio which I've filed with Microsoft, that prevents a 64-bit build from linking. I checked out the source code to the Xamarin Mac linker last week and started looking into their bug because the issue is currently marked as Triaged and I doubt they're going to try and fix it any time soon since I'm not a business customer. The linker is used on newer macOS builds because it scans the binaries for parts of the .NET Framework being used and automatically bundles them into the app so you don't need to install Mono. It appears this cannot be avoided. I believe the linking problem has something to do with OpenTK and its native wrappers, but that's as far as I got last week. I'm only spending about 3 hours each week on this right now.
Thanks for the comments, Sappharad. I suck at setting up builds using IDE's, so I didn't have any idea of what I was doing when I changed those .csproj, if you could make a pull request, I'll sure review it fast.
As for the large commit, I am going to revert. It simply doesn't work. After closing wiindows about ten times it almost always crashes. This is probably because of the garbage collector, it must be accessing the X server when it's finalizing the objects. Mono probably has a way to stop the GC from crashing other stuff when GUI is accessed, but if another thread is also using X, it has no way to know. Since the GC is pretty much unpredictable, I don't think there is a way to circumvent Mono's limitation at all. All X things should be done in a single thread.
About the UI, is there any possibility of using another toolkit, like Gtk#? It doesn't seem to have the same limitations in Mono that WinForms has.
Based on the fact that you're still deciding what to do, I'll wait until you've found an approach that you like. :-)
Regarding other toolkit, this is why I mentioned the /BizHawk.Client.EtoHawk/ solution in my previous post. Eto Forms uses GTK on Linux. It provides a cross-platform UI API very similar to WinForms. I started building the Eto UI in March of 2016, but BizHawk is so big and the WinForms UI has so much that I abandoned it about a year ago. Before I stopped you could load roms, configure controllers & play games with it, although I hadn't integrated OpenGL yet at that point so it was just outputting to a bitmap. Eto seemed like a good way to go forward at the time, because the actual BizHawk.Emulation.* projects will build fine on Mono so we could eventually start working on that directly in master without worrying about Windows and benefit from any core changes there.
The current EtoHawk code no longer builds on MacOS, due to some API changes after Microsoft bought Xamarin and started migrating MonoDevelop into Visual Studio for Mac, but it should still build on Windows and Linux. (I need to fix the macOS side)
I'm not suggesting EtoHawk as the best option going forward, but when I was looking for options with a native UI back in late 2015 and saw GTK# someone mentioned Eto Forms on IRC and I liked that API better along with the fact that it was native across Windows, Linux and Mac.
If you're interested in building a brand new cross platform UI, I'm willing to help. But the main reason I kept porting the WinForms one is because of all of the features. I just want to use BizHawk to play games and sometimes watch videos posted on the site, so I don't really have any personal interest in developing the TAS tools.
Wow, I completely missed all of this stuff because I don't check the forum daily anymore. Congrats on getting it working on Linux again.
I knew about the GDI+ problem, because about a month ago I tried to see if it would still build on Linux but after omitting those PNG's completely I ran into some other problem and I don't even remember what that was anymore. I'd love to pull in your changes if we can keep everything without breaking the macOS build. I'll take a look at that over the next few days.
I only look at this for a couple hours each week, and at the moment I'm trying to figure out how I can continue even offering macOS support in the next major release. The problem is that in the experimental branch they're going 64-bit only, and Mono's WinForms implementation doesn't support 64-bit on macOS. I've got 2 options at this point...
1. Ditch the WinForms UI and continue developing the Eto one. (Check that out by the way, it's in the /BizHawk.Client.EtoHawk/ directory, but last time I tried it on Linux it was crashing. That might've been the OpenAL problem you mentioned.) I don't like this idea much because it's not fun to rebuild the UI from scratch when I can use WinForms for free
2. Port Mono WinForms to 64-bit macOS. This actually seems like the easier option, but I don't know the internal OS windowing stuff at all so it's a huge learning curve.
And this is assuming that I can even get the new method of hooking up native cores to work with Mono.
I'm really glad that someone who cares about Linux and knows what they're doing is actually taking a look. I've left some comments on your commit, it looks pretty destructive right now and I think we can come up with something that won't cause as many merge conflicts in the future.
p4wn3r wrote:
feos wrote:
Do the tools like tastudio launch?
The tools where the menu entries are not greyed out are launching. TAStudio is unavailable at the moment, I will try to get a core compiled and see if it works.
TASStudio doesn't work on the mono branch and won't without some effort. There are custom controls in TASStudio that make native Windows wrapper calls to directly to GDI. All of that stuff would need to be re-written in pure C# without using the calls that were needed for those controls to function well in the first place. See CustomControls/GDIRenderer.cs
I stubbed out some of the native stuff for the custom list view control so that you could playback and record TAS input files, but any work to get TASStudio working outside of Windows will have to be completely new.
awesome stuff to hear man... keep your updates comming man.
thankyou for the advice about disabling rewind. i turned some features off and i have noices even less slow down than before but still not sound perfect yet.
also a thing to note. it seems the idea of the DMG signing didn't work. my OSX kicked Bizhawk and it still freezes when trying to play. but the trick you gave us works still.
Weird. I ran it directly from inside the .dmg on a different machine and it worked there. :-(
I guess I'll add the applications folder and an arrow to the disk image like some do and just make people "install" it.
I still think the performance issue you're experiencing is a settings problem, I just have to dig around and figure out what settings I was including before that aren't part of the default besides the audio sync and rewind stuff. The SNES core pushes my 9 year old Mac to the limit, and although it can still handle full speed, I noticed behavior similar to what you were reporting when I use default settings. If I use my old config file it doesn't stutter, and it also doesn't stutter if I enable MKV recording while I'm playing. (Which is weird because that should use more CPU)
========================
(2017-05-03) Mac Build of 1.12.2 has been released:
http://projects.sappharad.com/bizhawk_mac/BizHawk_mac_1.12.2.dmg
Same changes as the Windows version, when applicable.
Note: If you downloaded before 2017-05-16, the FFMpeg video writer was broken. Re-download 1.12.2 if you need that feature to work.
macOS specific improvements are:
- Tweaked a minor thing which may result in the appearance of slightly improved performance, but probably makes no difference.
========================
(2017-06-04) Mac Build of 1.13.0 has been released:
http://projects.sappharad.com/bizhawk_mac/BizHawk_mac_1.13.0.dmg
Same changes as the Windows version, when applicable. This probably includes C64 too, although I haven't actually tested it.
i have exactly those settings. what should i change my graphical settings too?
EDIT: hmmmm so with a bit of testing 1.11.7 works at normal speed. there must be something wrong with my computer coding effecting later versions of bizhawk.
Another thing that might have slowed it down is the rewind feature. Go into the rewind config option and disable it if it's enabled, performance may improve.
========================
(2017-04-02) Mac Build of 1.12.1 has been released:
http://projects.sappharad.com/bizhawk_mac/BizHawk_mac_1.12.1.dmg
Contains the same Intellivision and NES improvements as the Windows version.
macOS specific improvements are:
- Fixed compatibility with macOS 10.12 by distributing as a signed .dmg instead of .zip (This slightly increases the download size)
- Fixed ffmpeg related stuff. MP3 CDDA for Sega CD should work again, and the AVI Writer feature should work when you pick FFMPEG MKV output. Some of the other codec options work and some don't. I suggest MKV because it does, and just use VLC to convert it to a different format if you didn't want MKV.
- SNES is now supported on macOS builds.
No new release yet, but maybe that will finally happen in 2019.
As mentioned in a previous update, when BizHawk went 64-bit in version 2.0 I was unable to use the existing UI because WinForms on macOS only supported 32-bit and it didn't look like they were ever going to update that because Microsoft doesn't officially support WinForms on MacOS. (BizHawk 1.x Mac builds were using the 32-bit Mono WInForms implementation that was written against the old macOS Windowing system that was deprecated over 10 years ago.) It didn't seem like anyone was going to create a 64-bit implementation against the modern APIs, so I had started EtoHawk which was going to be a brand new UI native to macOS & Linux. I had that barely working (Load Rom, configure controls, sound + input, that's it) but when I tried to implement OpenGL for video I ran into problems and got stuck for a few months where I could see the screen border color but not the actual video.
In September of last year, I discovered that some guy had released a 64-bit macOS implementation of WinForms earlier in the year that his company was using to port their product to Mac. Unlike the Mono implementation, this one substitutes native macOS controls (buttons, menus, checkboxes, open/save dialogs) whenever feasible. The only downside to this because it's a replacement for a system library, I either have to build my own separate copy of Mono to use it as if it were built-in, or fork BizHawk to reference the unofficial version which makes the same code not build against Windows. I chose the latter, so that anyone else can check out the code for my fork and build it without needing an entirely different version of Mono.
After getting BizHawk running against it (as seen in the screenshot from last September) I had to fork OpenTK as well and port the OpenTK WinForms GLControl to work against the special Cocoa macOS WinForms implementation. Because I'm not very good at OpenGL, I had to throw some small hacks into BizHawk to get the native control / view handles, and also support 2x+ scaling for Retina displays. 64-Bit QuickNES is running again, so that's great.
What's left:
- Broken UI stuff, worse than before. For example controls don't appear in the control dialog to map them right now. (But the defaults mostly work.) Also, right now the menus are eating inputs from buttons that overlap to them, in other words if something is mapped to C and you press that, the config menu actually opens. I need to make sure that when the video has focus that the menus don't eat keyboard inputs.
- Rest of the previously supported native cores. QuickNES is working, it was the first one I did.
- Re-enable gamepad support. It's commented out right now just because I didn't feel like plugging in controllers to re-implement and test that.
- Some stability issues, but also caused by UI stuff.
- Menus are still native, but they're attached to the window like a Windows application. I may or may not fix this and put them back at the top of the screen.
Advantages of the new version so far over 1.x:
- Supports Retina displays, as pictured above. (View full image if using a normal monitor)
- UI is faster and more responsive. No more sluggish menus, windows usually draw faster.
- 64-bit. It will still work when Apple drops support for 32-bit applications in the next release of macOS, 10.15, which is due in September or October of 2019.
- It can be built using the Xamarin.Mac Linker. This results in a massive executable (probably twice the size of the last 1.x release... sorry) but you no longer need to install the Mono runtime to run the app. It automatically includes only the parts needed to run the app, so you can just download and install on a new machine without worrying about Mono.
I'll try to post another update in a few months, but I am still committing to the fork on my GitHub if another developer wants to build their own copy. My OpenTK fork is also checked in under a branch for the Cocoa WinForms GLControl. (But the binaries are committed to the BizHawk fork, so you don't need to build your own copy of that)