search

snes9xgit / snes9x

Snes9x - Portable Super Nintendo Entertainment System (TM) emulator
http://www.snes9x.com
Other
2.64k stars 455 forks source link

macOS Catalina Support #586

Open MichaelBuckley opened 5 years ago

MichaelBuckley commented 5 years ago

Apple released macOS 10.15 Catalina today, and Snes9x does not run on it.

Earlier this year, I volunteered to update Snes9x for Catalina, but I severely underestimated the amount of work this would require. Every part of the code except the audio code has required large changes, and I have not had enough free time to finish the work before Catalina's launch.

I still plan to finish the work, but it will take time. I plan to release a version with the ability to load games/freeze states, and play with keyboard/joypad as soon as I can. It still may be a few weeks before this release is done. After that, I hope to add multicart, video options, video recording, cheats, and music box back as time allows. I'll prioritize features requested by users if we get any.

Snes9x isn't the only emulator in this boat. Dolphin recently released a statement warning users to delay upgrading to macOS 10.15. https://twitter.com/Dolphin_Emu/status/1180072169339883520

If users ask about the status of Snes9x on Catalina, you can point them to this Github issue.

pmaddox76 commented 4 years ago

Thank you Michael for your time and effort. It is appreciated.

viniciusmaltauro commented 4 years ago

Thanks for doing that Michael! I'm an user and I'm looking forward for the update.

sgreadly commented 4 years ago

Just wanted to say thanks too! Looking forward to a 64bit release I'm happy to test for you ^_^

MichaelBuckley commented 4 years ago

@pmaddox76, @viniciusmaltauro, @sgreadly, @viniciusmaltauro, @bryan-lunt, @daaku, @abderrahmane-tj, @sgreadly, @benvp, @marconett, @kethinov, @rchristi, and @johannes87

Thank you all for the encouragement. I have keyboard support, joypad support, and freeze/defrosting working, but I don't yet have UI hooked up properly for them. I'm hoping to get that done in the next week, maybe two weeks, then I'll release a build. The control configuration UI won't be pretty, but it will work, and I think it's more important to release something working.

Notably, it won't yet support any other Snes9x features, nor (probably) mouse, Super Scope and Justifier controls.

One thing that could really help me is hearing from people who use Snes9x on Mac about why they use it instead of (or in addition to) other emulators. It would really help me to prioritize what gets implemented next.

bryan-lunt commented 4 years ago

There are other emulators?

bearoso commented 4 years ago

Yes, OpenEmu and Retroarch can run the Snes9x and bsnes cores, and I think bsnes has a partly working standalone client.

MichaelBuckley commented 4 years ago

The last time I checked, the bsnes Mac UI wasn't working properly, but it's a nightly build, so that may have changed. Higan nightlies have worked for me, but they take considerably more CPU power than Snes9x. https://cirrus-ci.com/github/byuu/higan/master

viniciusmaltauro commented 4 years ago

Michael, I love that the Snes9x is light, simple and reliable. I use a keyboard (and always thinking about getting a joystick and afraid of it to not work). Frost/defrost is the key feature I use and sometimes I use cheating codes (what I wish it were simplier to do do). A big thank you again!

On Mon, 4 Nov 2019 at 22:30 Bryan Lunt notifications@github.com wrote:

There are other emulators?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=ANPQUQFNQXBVI6SZVFV4LLLQSDEDNA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDBJL5Y#issuecomment-549623287, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPQUQGNO3LRJAZ2GUHMXSTQSDEDNANCNFSM4I6KEKHQ .

kethinov commented 4 years ago

Notably, it won't yet support any other Snes9x features, nor (probably) mouse, Super Scope and Justifier controls.

I'm pretty sure mouse support is already broken. I tried to run Mario Paint a month or two ago and it didn't work on the Mac version at all for me.

One thing that could really help me is hearing from people who use Snes9x on Mac about why they use it instead of (or in addition to) other emulators. It would really help me to prioritize what gets implemented next.

I use it to playtest the numerous ROM hacks I've been working on for Secret of Mana since my primary computer right now is a Mac.

Obviously Geiger's Windows version with the SNES debugger is something I have to bust out in a Windows VM every now and then to do any serious reverse engineering, but the Windows version is understandably a bit janky in a VM, so I only really use it for debugging. For actual playtesting, I prefer the buttery smooth performance of the Mac version.

sgreadly commented 4 years ago

I wasn't aware of alternatives, but then again I didn't go out looking for any. To me, snes9x is a choice due to the excellent support, development, and loyalty over the years (since Linux days too). It worked, was easy to use, and lightweight.

MichaelBuckley commented 4 years ago

Obviously Geiger's Windows version with the SNES debugger is something I have to bust out in a Windows VM every now and then to do any serious reverse engineering, but the Windows version is understandably a bit janky in a VM, so I only really use it for debugging. For actual playtesting, I prefer the buttery smooth performance of the Mac version.

I originally decided to check out the Snes9x source code because I wanted to see about adding a debugger to the Mac version, to assist in homebrew development. I can't promise I'll get there, since the Cocoa rewrite is taking much longer than I expected, but maybe someday.

I know there's been talk about a cross-platform UI in some of the other github issues. Maybe if that effort gets off the ground, and it has a debugger, my time would be better spent in the long-term helping with the Mac side of it.

marconett commented 4 years ago

One thing that could really help me is hearing from people who use Snes9x on Mac about why they use it instead of (or in addition to) other emulators. It would really help me to prioritize what gets implemented next.

For me it's just that bsnes and higan eat through my macbook battery when playing while traveling, so I prefer snes9x when I'm on the go.

johannes87 commented 4 years ago

One thing that could really help me is hearing from people who use Snes9x on Mac about why they use it instead of (or in addition to) other emulators. It would really help me to prioritize what gets implemented next.

For me it's just that bsnes and higan eat through my macbook battery when playing while traveling, so I prefer snes9x when I'm on the go.

I also feel that Snes9x uses less computing resources. My CPU temparature is lower and my fan keeps quieter in comparison to bsnes. Haven't tried higan.

MichaelBuckley commented 4 years ago

Snes9x.app.zip

Here's a barebones build which works on 10.12 through 10.15. The code for this has all been uploaded to a branch called mac-minimal-changes in my GitHub fork. Please test it out. If no major problems are found, I'll submit a merge request.

A few important notes:

Please reply to this issue with direct feedback on this build. I'll ahve a blog post in the next few days about the process of porting, and what the plan is going forward.

MichaelBuckley commented 4 years ago

Oh, one more thing. When you first launch on 10.15, it'll throw up a dialog asking for permission for the app to access your keyboard. I'm not sure what's causing that, but I think it might be required for joypad support. I promise the app isn't doing anything evil. It's safe to grant the app keyboard permissions.

spotanjo3 commented 4 years ago

Its working properly now on Catalina . What version is it now ? Starting with v1.0 again ? Not v1.61 ? Confusion.

MichaelBuckley commented 4 years ago

@azoreseuropa It is between versions. There is some code that has changed since 1.61, so it did not feel right calling it 1.61. However, 1.62 (or whatever the next release will be) is not finished yet. Therefore, I did not set a version number, and macOS is displaying it as 1.0 because it lacks a version.

When the next version is released, I will be happy to produce a build with that version number and deal with Apple's notarization process. There may be more intermediate Mac builds before then.

spotanjo3 commented 4 years ago

Thanks.

On Fri, Nov 29, 2019 at 12:27 PM Michael Buckley notifications@github.com wrote:

@azoreseuropa https://github.com/azoreseuropa It is between versions. There is some code that has changed since 1.61, so it did not feel right calling it 1.61. However, 1.62 (or whatever the next release will be) is not finished yet. Therefore, I did not set a version number, and macOS is displaying it as 1.0 because it lacks a version.

When the next version is released, I will be happy to produce a build with that version number and deal with Apple's notarization process. There may be more intermediate Mac builds before then.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=AD5X34WNBJNAEGFH2R66RUDQWFGHHA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFPKJ4I#issuecomment-559850737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34W3RISMBRGHFKO3PFDQWFGHHANCNFSM4I6KEKHQ .

-- In Memory of Spot (FOREVER)

TEETSmaGEETS commented 4 years ago

Thanks for all your work! This is working but is really choppy for some reason. Anyone else having this issue?

spotanjo3 commented 4 years ago

Like what? I can test it tomorrow or something.

On Sun, Dec 1, 2019 at 8:02 PM TEETSmaGEETS notifications@github.com wrote:

Thanks for all your work! This is working but is really choppy for some reason. Anyone else having this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=AD5X34R6QCLPOMVR62S7AELQWRNCTA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFR34ZQ#issuecomment-560184934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34RZZ44U7TEHQVGAEQLQWRNCTANCNFSM4I6KEKHQ .

-- In memory of Spot (FOREVER)

TEETSmaGEETS commented 4 years ago

The video is stuttering, like freezing momentarily and then continuing repeatedly. The built in Frame rate display doesn't show any frame rate drops though. Have tried on several roms.

spotanjo3 commented 4 years ago

What games?

On Sun, Dec 1, 2019 at 8:16 PM TEETSmaGEETS notifications@github.com wrote:

The video is stuttering, like freezing momentarily and then continuing repeatedly. The built in Frame rate display doesn't show any frame rate drops though. Have tried on several roms.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=AD5X34S6HAT6CC3VU4Y3IR3QWROVRA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFR4LTQ#issuecomment-560186830, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34VLIAQ6NUDVYGWJOTTQWROVRANCNFSM4I6KEKHQ .

-- In memory of Spot (FOREVER)

MichaelBuckley commented 4 years ago

It's definitely possible that the updated rendering code is slower for some games or on some hardware. I haven't had the ability to test on very many games, and have only tested on a 2014 Mac Mini and a 2015 MacBook Pro.

Knowing which games and which hardware are suffering from the studdering would be helpful for diagnosing the problem and fixing it. It would also be helpful to know how much CPU Snes9x is taking on your machine using Activity Monitor. Thanks in advance for any details you can provide.

misatosangel commented 4 years ago

Sadly this crashes as soon as a Rom is loaded here. Running catalina (10.15.1) on a 2017 15" MBP. The app runs and the preferences screen works. Open Rom dialogue comes up and then after select it just vanishes. Doesn't seem to matter what Rom, tried several.

Starting from the terminal gives the following output: % ./Snes9x.app/Contents/MacOS/Snes9x

Interval: 16ms, Frames: 512
Interval: 16ms, Frames: 512
Map_SDD1LoROMMap
TextureRange: enable
AUGraph started.
Illegal instruction

Machine details:

Model Identifier:       MacBookPro14,3
Processor Name:         Quad-Core Intel Core i7
Processor Speed:        3.1 GHz
Number of Processors:   1
Total Number of Cores:  4
L2 Cache (per Core):    256 KB
L3 Cache:               8 MB
Hyper-Threading:        Enabled
Memory:                 16 GB
Boot ROM Version:       202.0.0.0.0
SMC Version (system):   2.45f1
spotanjo3 commented 4 years ago

Can you try Mega man 7 ISA or europa. It works fine for me.

On Mon, Dec 2, 2019 at 3:48 AM misatosangel notifications@github.com wrote:

Sadly this crashes as soon as a Rom is loaded here. Running catalina (10.15.1). The app runs and the preferences screen works. Open Rom dialogue comes up and then after select it just vanishes. Doesn't seem to matter what Rom, tried several.

Starting from the terminal gives the following output: % ./Snes9x.app/Contents/MacOS/Snes9x

Interval: 16ms, Frames: 512 Interval: 16ms, Frames: 512 Map_SDD1LoROMMap TextureRange: enable AUGraph started. Illegal instruction

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=AD5X34RW2QBT6CZNALEGHXDQWTDWFA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFSWWQA#issuecomment-560294720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34UWWTH3YJEUQY36ELTQWTDWFANCNFSM4I6KEKHQ .

-- In memory of Spot (FOREVER)

spotanjo3 commented 4 years ago

Try good dump roms only. I tried Mega man 7 Europe and it works fine.

On Sun, Dec 1, 2019 at 8:16 PM TEETSmaGEETS notifications@github.com wrote:

The video is stuttering, like freezing momentarily and then continuing repeatedly. The built in Frame rate display doesn't show any frame rate drops though. Have tried on several roms.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=AD5X34S6HAT6CC3VU4Y3IR3QWROVRA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFR4LTQ#issuecomment-560186830, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34VLIAQ6NUDVYGWJOTTQWROVRANCNFSM4I6KEKHQ .

-- In memory of Spot (FOREVER)

MichaelBuckley commented 4 years ago

@misatosangel Two things stand out from those logs. The first is the line Map_SDD1LoROMMap. That indicates that the emulator is using the S-DD1 mapper, which I believe is only used in Star Ocean and Street Figher Alpha 2. Can you confirm that you were loading one of those games? If not, it may mean there's something in the code that's misidentifying the game.

Second, is the line Illegal Instruction. I usually see that only when running on older hardware or an older than the minimum requirements. However, you're using a newer OS with newer hardware than the machine on which it was compiled. Could you please zip up the crash logs and attach them to this ticket? You can find instructions for getting to the crash logs here, just replace Day One with Snes9x.

spotanjo3 commented 4 years ago

You are absolutely right. I tested Street fighter Alpha movie and it stutter alot and I am sure that they will release v1.63 soon. This is only v1.0 beta for macOS.

On Mon, Dec 2, 2019 at 9:26 AM Michael Buckley notifications@github.com wrote:

@misatosangel https://github.com/misatosangel Two things stand out from those logs. The first is the line Map_SDD1LoROMMap. That indicates that the emulator is using the S-DD1 mapper, which I believe is only used in Star Ocean and Street Figher Alpha 2. Can you confirm that you were loading one of those games? If not, it may mean there's something in the code that's misidentifying the game.

Second, is the line Illegal Instruction. I usually see that only when running on older hardware or an older than the minimum requirements. However, you're using a newer OS with newer hardware than the machine on which it was compiled. Could you please zip up the crash logs and attach them to this ticket? You can find instructions for getting to the crash logs here https://help.dayoneapp.com/en/articles/450930-getting-crash-logs-from-day-one-for-macos, just replace Day One with Snes9x.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/snes9xgit/snes9x/issues/586?email_source=notifications&email_token=AD5X34VCUMGFDH4CZBJYZL3QWULIXA5CNFSM4I6KEKH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFTU5MQ#issuecomment-560418482, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD5X34QVJUQX6TG6Y4NBSF3QWULIXANCNFSM4I6KEKHQ .

-- In memory of Spot (FOREVER)

misatosangel commented 4 years ago

Can you confirm that you were loading one of those games?

Not sure which Rom I tried that time it probably was Alpha 2.

However, they all fail, trying some others just now (Chrono Trigger, Megaman 7) . Only difference is that the line in question is replaced by Map_HiROMMap, which makes sense.

Here's the last crash log zip'd for you. Snes9x_2019-12-02-194953_rin.crash.zip

(I should add that all the Roms in question work fine on the old 32bit Snes9x)

MichaelBuckley commented 4 years ago

Snes9x.app.zip

@misatosangel Thank you for the crash report. It pointed directly and unambiguously at the lone of code that was crashing. Unfortunately, it's not clear why it's crashing. I have uploaded another build to this comment. It may solve the problem, but if it does not, it will hopefully contain more information. If you have a few minutes, would you give it a try, and if it crashes, attach the new crash report? Thank you in advance.

misatosangel commented 4 years ago

Now works! Though frame-rate is pretty terrible on a few Roms I tried. Thevisible FPS counter stays resolutely at 60 (occasional jitter to 61) but the games are clearly drawing well below that.

(btw, thanks for all your time spent on this, I looked at this a few years ago myself and just "noped" out at the sheer amount of code)

MichaelBuckley commented 4 years ago

@misatosangel Glad to hear it works. That this build works while the other did not might point to an issue in your OS install. It may also be something as simple as needing a reboot (as strange problems like this can often be solved that way.) Let me explain.

The crash you posted showed that Snes9x was crashing on the third line of this code snippet.

os_unfair_lock_lock(&renderLock);
S9xMainLoop();
os_unfair_lock_unlock(&renderLock);

Specifically, when unlocking, the an exception was thrown that we were trying to unlock a lock owned by another thread. However, that code is very straightforward. We locked it, so we should be able to unlock it. There was also no possible way renderLock could be uninitialized at this point. The S9xMainLoop() function, as far as I can tell, does not call into any code that messes with the locks. However, whenever locking is involved, and the problem reproduces on one machine but not another, it's always posible that there's a race condition somewhere, and that I was mistaken about S9xMainLoop().

So I replaced the os_unfair_lock with pthread_mutex_t. These should be slightly slower than os_unfair_lock, but not significantly so. Either way, if it was a timing issue, I hoped the crash report would contain better info. It's true that the slightly slower locks may have resolved the timing issue, but since you're the only person to report this so far, it's also possible that there's something wrong with os_unfair_lock on your machine.

As for the slowdown, I suspect it's being caused by the move to NSOpenGLView. The deprecated Carbon OpenGL code allowed us to draw on the background thread, which meant we could make drawing part of the emulation loop. Since NSOpenGLView requires drawing on the main thread, I had to introduce a render lock. The emulation loop has to wait while the screen is drawing, screen drawing has to wait while the emulation loop is running. On my test machines, neither takes so long that the others are waiting much, but I could see how it could be different on other machines, especially machines with retina monitors, and especially when the image is stretched.

It turns out that automatic frame skip is also on by default, so when the emulator falls behind, it will emulate multiple frames without drawing them, thus the frame count remains relatively stable. I'll be adding a setting to control that in the near future, and probably turn it off by default.

The good news is that I should be able to return drawing to the background when rewriting the renderer to use Metal instead of OpenGL, which will allow me to get rid of the rendering lock.

That rewrite will probably take a good amount of time. In the meantime, since I can't reproduce the slowness issue myself, it would be helpful to have an activity sample to help confirm or disprove my hypothesis. I hate to ask more of you since you've already been so patient and helpful, but would you be willing to take a sample while Snes9x is drawing slowly and attach it to this ticket? Thanks.

MichaelBuckley commented 4 years ago

As I promised earlier, I have written a blog post which details, among other things, my plans for this port going forward. https://buckleyisms.com/blog/snes9x-on-macos-catalina/

misatosangel commented 4 years ago

Uploaded a couple of samples, playing in blocky windowed mode, rom was SF2 just sitting there letting the CPU do things. All Roms I tried show mostly the same jitter.

I had restarted the machine several times for the earlier tries of snes9x, so I doubt it was that. Tried nuking the preferences just now, and noticed there was a 0-length file ~/Library/Preferences/com.snes9x.macos.snes9x.plist.lockfile dated back to 24 Jul 2011 sitting there - not sure whether maybe that was related to your lock call - but I presume that's an in-memory lock from your description and the fact that you're replacing it with a pthread call, rather than an OS file-based lock.

samples.zip

misatosangel commented 4 years ago

Also just read your blog post:

[...] but what I didn’t realize when I volunteered to update it was that Snes9x was still using Carbon. Part of me wanted to give up right there

When I siad earlier I "noped" out, this is pretty much what I did, I'm amazed you took it on, as someone who has had their personal gaming projects busted by the move from 68k -> ppc, from classic macos -> OS-X (good buy inputsprocket, netsprocket etc, not to mention ppc custom assembler blitters in the transition from ppc(64) -> x86_64) I know the pain. Also that feeling which Apple gives off Re really holding their developers in disdain. OpenGL dying is just another.

Though that said, there are (or were) advantages of constantly modernising your OS; not having to carry all the legacy baggage Windows does - but nowadays, I feel macOS is far from the bastion of stability and usability it used to be. Catalina even more so. :(

knowing that it would be a large undertaking to rewrite the app using Cocoa, but as far as I knew, no one else was lining up to do the work, and when I thought about it, a Mac without Snes9x didn’t sit right with me. Snes9x has been on the Mac for 21 years, since the early days of the emulator. As strange as it sounds, I’m nostalgic for the emulator, not just for the old games, but for the software itself.

And that's really me in a nutshell too. I remember John Stiles and "emulation.net", even have a few emails of correspondence back in the day around when he did "Skittles" (renamed "Candy Crisis" for obvious trademark reasons) around the time he joined Blizzard. Lost track of him since.

Anyway, apologies for derailing this thread, but your blog didn't have a comments section. ;) Just wanted to let you know I understand all your feelings there (and the keyboard viewer!)

MichaelBuckley commented 4 years ago

Thanks for the samples. They do show a lot of time waiting in locks, but they're not substantially different than normal samples. My guess is that, since there's no guarantee on the order of acquiring locks, the main thread's NSOpenGLView is getting starved as the emulation loop keeps re-acquiring the lock. I could try to find a temporary workaround, but I think the only foolproof solution is to get rid of the locks entirely, and that will probably be a few weeks before I have a build.

not sure whether maybe that was related to your lock call - but I presume that's an in-memory lock from your description and the fact that you're replacing it with a pthread call, rather than an OS file-based lock.

Yes, that's correct. os_unfair_lock is basically the equivilent to a pthread mutex, just a bit faster. It ships on macOS as part of os.framework.

Also that feeling which Apple gives off Re really holding their developers in disdain. OpenGL dying is just another… There are (or were) advantages of constantly modernising your OS; not having to carry all the legacy baggage Windows does - but nowadays, I feel macOS is far from the bastion of stability and usability it used to be. Catalina even more so. :(

I had originally written a lot more on that subject in the blog post, but I threw a lot of it out since it got off topic and was a bit negative. Maybe I'll resurrect it for its own post. It turns out this isn't even the first time Snes9x has been impacted by a transition. The preferences stringified OSTypes in their keys, so in the PPC->Intel transition, the endianess swap changed all the preference keys, so you couldn't copy preferences from a PPC machine over to an Intel machine. For example, the keyboard settings were saved under the key "Preference_keyb" in PPC, but on Intel machines, the key became "Preference_byek".

And that's really me in a nutshell too. I remember John Stiles and "emulation.net", even have a few emails of correspondence back in the day around when he did "Skittles" (renamed "Candy Crisis" for obvious trademark reasons)

I also got into emulation from emulation.net (thanks to the article in MacAddict). Until I was doing research for the blog post, I had completely forgotten the "Try Skittles/Candy Crisis" John Stiles bundled with Snes9x downloads. But seeing that icon hit me with a wave of nostalgia. Hard to imagine An emulator being bundled that way these days.

Anyway, apologies for derailing this thread, but your blog didn't have a comments section.

Yeah, sorry about that. Moderating the spam comments became a huge pain so I switched to a static site generator and got rid of the comments. I probably shouldn't have helped derail this Github issue. You can always email me (my email address is in the project commits) or DM me on Twitter if you use that.

bearoso commented 4 years ago

I don’t think it’s a derailing if you’re just discussing the pitfalls of the newer Mac OS releases. It’s obvious that contemporary Apple no longer wants third-party applications on its computers anymore. The attempts at vendor lock-in are quite transparent.

I think Vulkan has them beaten, though. It’ll become the new defacto standard with the 2020 consoles, mobile devices, and Windows and open-source OSs all supporting it. It might be a good idea to look into MoltenVK and see if it’s workable.

MichaelBuckley commented 4 years ago

I think Vulkan has them beaten, though. It’ll become the new defacto standard with the 2020 consoles, mobile devices, and Windows and open-source OSs all supporting it. It might be a good idea to look into MoltenVK and see if it’s workable.

I haven't used MoltenVK for exactly this kind of task, but I've found it to be very good in other projects. Normally, it would be a shoo-in over Metal, especially in a cross-platform app, but there are a couple details that are holding me back.

The first is that the MoltenVK library itself is ~ 5 MB, whereas currently the total binary size of Snes9x.app is 3.6 MB. I know drives are large, and the emulator would still be under 10 MB, but something feels wasteful shipping a graphics library larger than the app itself.

The second is that, on Mac, MoltenVK ultimately translates everything to Metal, so there will be a performance hit for that translation, no matter how small. If One of Snes9x's selling points is that it's more CPU-efficient than other emulators, it seems like a bad idea to slow it down. But then again, the performance impact might not be so great.

On top of that, it looks like Metal has an easy-to-use API to do exactly what I want. It's a little more complicated in Vulkan. That said, if the Snes9x ports for other platforms are going to adopt Vulkan some day, perhaps using Vulkan on the Mac port would allow better code sharing between the ports.

MichaelBuckley commented 4 years ago

Snes9x.zip

Here's a lightly-tested build with an experimental Metal renderer. This will hopefully solve the issue with chunky frame rates that some people are experiencing. I'm currently on the road without access to my notarization password, so this build is not notarized. You'll get a scary warning when opening it and will need to right-click or control-click the app and choose Open to run the app. I won't be able to produce a notarized build until after the new year, but I will upload one as soon as I can.

Mainly, I'm interested in feedback on whether this build fixes the frame rate issue some were experiencing. I'm also unable to test on a non-retina screen, so feedback is welcome there too. Metal's smooth drawing mode appears to be not as smooth as OpenGL, so for anyone using smooth drawing, I apologize in advance.

misatosangel commented 4 years ago

Mainly, I'm interested in feedback on whether this build fixes the frame rate issue some were experiencing.

Fixes it for me, many thanks for your continuing work!

gtalusan commented 4 years ago

This is great!

MichaelBuckley commented 4 years ago

Snes9x.app.zip

Happy New Year. For those of you who need a notarized build, I have attached one to this comment. This build also fixes a crash that could occur when switching ROMs.

dailun commented 4 years ago

When I go to "Preferences" my USB game controllers do not appear, the only option is "Keyboard". In previous versions I would configure the controllers via "Config" on the main menu.

I checked to make sure my MacBook was still recognizing the two USB game controllers and it was. I also tried granting Snes9x full access to my keyboard which seems a bit unsafe and unnecessary however even with this access although my generic USB controllers were recognized and listed under "Keyboard" I was still unable to configure them.

Any suggestions on how to get this post-Catalina Snes9x to recognize my controllers and allow me to configure them? Preferably without having to grant full access to my keyboard in all applications. Thanks

MichaelBuckley commented 4 years ago

Snes9x.app.zip

@dailun Another user just reported a similar problem with a fix. I have attached a build with that fix to the top of this post.

I do believe you have to grant Snes9x full access to your keyboard for gamepads to work. Catalina comes with a new gamepad API that doesn't require keyboard access, but it only works with Xbox, PlayStations and Mfi controllers. I promise that Snes9x isn't doing anything with your keyboard except using it to control games, and the source code is open so you can confirm that.

If you need help enabling keyboard access for Snes9x, Apple has a help article. https://support.apple.com/guide/mac-help/control-access-to-input-monitoring-on-mac-mchl4cedafb6/mac

dailun commented 4 years ago

Thanks for the help but unfortunately I am still unable to configure the controllers. After I enable keyboard access they appear under "Keyboard" in the dropdown box however I am still unable to assign the buttons on my two "Generic USB Joysticks".

MichaelBuckley commented 4 years ago

@dailun You should be able to click into any of those text fields and hit a button on the joystick to assign it, but the fact that it's showing up as "Generic USB Joystick" means it might not be able to find the buttons.

Could you try creating mappings for these joysticks using http://generalarcade.com/gamepadtool/ and pasting them in a comment in this ticket? I'll be able to add those mappings to a build, which should hopefully allow them to be used.

dailun commented 4 years ago

I skipped over a lot of the buttons and just made sure I had registered the buttons needed on a Super Nintendo controller.

Searching gamepads... Found 2 gamepad(s): "Generic USB Joystick", 03000000790000000600000007010000 (mapping available) "Generic USB Joystick", 03000000790000000600000007010000 (mapping available) Mapping string: '03000000790000000600000007010000,Generic USB Joystick 2,platform:Mac OS X,a:b2,b:b1,x:b3,y:b0,back:b8,guide:b9,leftshoulder:b4,rightshoulder:b5,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0,' Searching gamepads... Found 2 gamepad(s): "Generic USB Joystick", 03000000790000000600000007010000 (mapping available) "Generic USB Joystick", 03000000790000000600000007010000 (mapping available)

MichaelBuckley commented 4 years ago

Snes9x.app.zip

@dailun Based on that information, it looks like you're using a DragonRise Inc. PC Twin Shock Gamepad. I did some research and it looks like it reports its button mapping in a different format than any other gamepad I have to test on, so I'm not confident that this build (linked above) will fix the issue.

However, this build will also log gamepad information to a file in your home folder called snes-gamepad.txt. It will log so much information that it will probably slow down the emulation on your machine.

Please run this build, select your gamepad in the preferences, press some buttons, quit Snes9x, zip up that file, and attach it to this ticket. I should hopefully have all the information I need to support that controller.

dailun commented 4 years ago

I have attached a photo of the controller along with the file you asked for however when I tried registering the inputs there was still no response. If there was only a way to make the pre-Catalina controller configuration work on this new build because before it worked great.

snes-gamepad.txt.zip

Oker game controller

MichaelBuckley commented 4 years ago

Snes9x.app.zip

I believe this build will solve your input issue. It will still create the log file, so let me know if this works for you and I'll produce a build without all the logging.

Unfortunately, I can't really go back to the old code. A lot of it was tied directly into the old UI, and some of it had design limitations. For example, it was impossible to reverse axes using the old code, and it was also impossible to use https://github.com/gabomdq/SDL_GameControllerDB to provide reasonable defaults for the most commonly-used controllers. I figured that as long as I was rewriting a lot of the code anyway, I might as well solve those issues, so the code will be more useful for most users. Rewriting from Carbon to Cocoa seemed like the best time to introduce any risky changes. The new code is less tested, and it is a bit more complicated, so there was always a chance it would break some controllers. I'm sorry it happened to you, but I'm thankful that the information you provided me should solve what I hope are the last remaining issues with the code.

For those curious as to what broke, the old code recieved cookies from the gamepads and allowed the user to configure what each cookie did. The new code reads the HID report from the controller, which reports what each cookie actually is. For example, it could tell you that the cookie 13 mapped to the start button.

Each element in the HID report can have one or more children elements. For example, the left stick element might have children elements for the X axis, the Y axis, and the stick's button. This gamepad's HID report listed all the buttons as chidren of the left stick's X axis. There's technically nothing in the HID standard that disallows this, but I never thought a stick axis would have child elements, especially not elements completely unrelated to the stick.

Previously, my code was not checking for children on axes, buttons, or D-pads. I fixed it to always check for children on every element.