alinebee / Boxer

The DOS game emulator that's fit for your Mac.
http://boxerapp.com/
769 stars 138 forks source link

Make Boxer 64-bit compatible for macOS 10.14 #76

Open simonbrueckner opened 6 years ago

simonbrueckner commented 6 years ago

A couple of days ago, macOS 10.13.4 was released which starts issuing warnings that apps which don't support 64-bit will be retired with macOS 10.14 (expected in Autumn '18).

This means that Boxer will in its current setup stop working on the latest macOS later this year.

I get it that the main issue is that underlying DosBox is not 64-bit compatible - but at least it has been compiled with 64-bit support a couple of years ago: https://hexeract.wordpress.com/2016/09/10/building-dosbox-as-x64-binary-for-macos-sierra/

It would be great to keep Boxer running for the macOS community!

JoshuaPettus commented 6 years ago

The issue isnt that it doesnt compile. Its that the dynamic core doesnt run near as efficently as it does on 32bit. Especially for more demanding games

almeath commented 6 years ago

Still hoping someone can help me in compiling @MaddTheSane's 64 bit build:

https://github.com/alunbestor/Boxer/issues/56

As I had trouble with it, I have been spending time extensively testing out 64 bit DOSBox SVN and the results are a lot better than I would have first thought. It works well enough that it appears the end of 32 bit will not entirely end my DOS gaming in macOS.

almeath commented 6 years ago

If you get frustrated waiting for Boxer to ever be updated, Dominus at VOGONS is now providing his DOSBox SVN pre-compiled for both 32 and 64 bit.

https://www.vogons.org/viewtopic.php?f=32&t=59656&p=665727#p665727

alinebee commented 6 years ago

I'm working on a 64-bit build right now, based on @MaddTheSane's https://github.com/MaddTheSane/Boxer/tree/updateDosBox branch. There are a bunch of crashers and UI bugs to resolve before I'll be able to make a beta release off of it however.

@MaddTheSane's branch should compile right off the bat in Xcode 9.3; if you're getting missing header warnings then it's likely an issue with your build environment. Cleaning your build folder and/or checking out a fresh version of the branch into a new directory may cure those.

almeath commented 6 years ago

It is great to hear from you Alun and it is such good news that you are finding some time to look into updating Boxer. I should have had more faith that the cavalry would arrive! :)

clobber commented 5 years ago

Wow, after many years DOSBox 0.74-2 was just released (!!!) with 0.75 finally entering regression testing. From the release notes, there may be some changes that benefit Boxer.

mintho commented 5 years ago

To all coders working on this: Thank you very much. Your hard work is very much appreciated. Personally I lack the skills to contribute, but I hope that with DOSBOX 0.74-2 and its 64Bit support something can be done in time before macOS drops support for 32Bit applications.

DivineDominion commented 4 years ago

I seems joysticks are an issue. I don't have any to test and verify, though: https://github.com/alunbestor/Boxer/issues/102

@alunbestor Even then, I think it'd make sense to merge the functional 64bit branch into master without making a release to have a new baseline for development since games do seem to work.

seanbperiod commented 4 years ago

Looks like Boxer is dead for 10.15 :( really hoping for an update. Love this app!

shakalaca commented 4 years ago
Screenshot 2019-10-08 08 09 27

Struggling :(

srvrguy commented 4 years ago

I'm sure work will eventually continue on Boxer for 64-bit support, if someone has the skills and is willing. Until then, you could use DosBox directly and a different GUI.

@shakalaca Download Steam fresh from the site (steampowered.com) and you should get the 64-bit version installed.

DivineDominion commented 4 years ago

The 64bit changes appear to be functional, but the code isn't released as an update, yet.

gr33k commented 4 years ago

Welp - Seems like this AWESOME fellow named YOZY decided to make it work (or compiled the 64-bit branch?) on 64-bit - I tested and verified it's working in Catalina 💃

Forum I found it from: https://www.dosgameclub.com/forums/topic/boxer-app-64-bit/

File Link: https://yozy.net/files/downloads/2019/Boxer-2019-03-03.zip

Would be great to see this officially updated for Catalina 👍

wanrming commented 4 years ago

Boxer is good

gc505 commented 4 years ago

Yes, just here to say thank you to the original author of Boxer, YOZY, and everyone here, for keeping Boxer around.

MaddTheSane commented 4 years ago

Does anyone know what repository/fork YOZY is using?

AstroChckn commented 4 years ago

Seems to be this, but I can't be certain: https://github.com/alunbestor/Boxer/tree/64bit/master

almeath commented 4 years ago

@MaddTheSane, isn't your fork significantly ahead of the 64-bit master in terms of patches and improvements over the last 18 months? I have been building off your MaddsV2 branch - is that the best one to use?

I have been tempted to go back to using vanilla DOSBox, but if your branch or the master is integrated with DOSBox 74-3 and can be updated as DOSBox progresses then I would much rather stay with Boxer.

MaddTheSane commented 4 years ago

Yes, my fork uses a slightly newer version of DOSBox, but Boxer hasn't been updated to use the newer features.

getaaron commented 4 years ago

@almeath Would you be willing to release what you have today as an official update?

almeath commented 4 years ago

I do not actually alter any of the code from @MaddTheSane's release. However, I understand that some people have trouble getting Boxer to build using Xcode. It is not exactly straight forward, so I do not mind linking to a pre-built copy of the maddsV2 fork (hopefully @MaddTheSane does not mind).

I will periodically update the build in this link as the code gets updated:

http://userweb.eftel.com/~almeath/mac/boxer/

Note that this is not the 64-bit 'Master' branch - this is the fork referenced above, which provides certain patches and improvements that are not currently in the master.

Also note, I build for personal use using my Apple ID, so I am not sure if this will cause problems for those running Mojave and Catalina, due to all of the notarization/code signing/quarantine flag stuff that Apple has forced upon us.

What I have done is build the Boxer app, Bundler and Standalone, using my Apple ID in Xcode. Then I manually codesign them, again using my personal Apple ID. Lastly, I manually remove any quarantine flags using "xattr -cr", as I notice that sometimes when I move apps to other Macs it falsely tells me they are damaged and should be moved to the trash. Why does Apple make things so hard these days..

Anyway, if I am breaching any terms by offering these builds someone tell me and I will remove them if necessary. Secondly, I would be interested in knowing if these actually run on Mojave and Catalina systems without causing any errors or security warnings etc.

MaddTheSane commented 4 years ago

I have no issue with anyone using my fork.

getaaron commented 4 years ago

@alunbestor

Here is the install experience downloading maddsV2 10.19.2019.zip on macOS 10.15 Catalina:

The server it's on is pretty slow:

image

The .zip file automatically extracts to this folder:

image

I think I only care about Boxer. If I double-click it, I get the error because it's not notarized:

image

If I right-click it and select Open, I get a similar error but with an Open button:

image

Once I click that I get the Accessibility Permissions dialog:

image

After I grant that permission, Boxer runs great:

image

You can Notarize the app from inside Xcode: Organizer -> Archives -> Distribute App -> Developer ID -> Upload:

getaaron commented 4 years ago

BTW, if you want to notarize using the command line, there's instructions for that here — you can even notarize older already-released builds (although not sure that'll do much good since they're all 32-bit).

almeath commented 4 years ago

Thanks for testing. That seems to be the standard process for a non-notarized app in Catalina. Once you go through those initial steps it should not have to be repeated for future launches.

Going forward, there could be problems in 2020 when Apple enforces notarization, so I will look into that. However, at the moment it costs $99/year to be an Apple Developer, so it is prohibitive for a hobbyist like myself.

I will also look into a faster server, thanks for pointing that out.

ideologysec commented 4 years ago

Thanks very much for providing prebuilt binaries!

As far as faster servers go, perhaps just use GitHub Releases, or put the zip in GDrive or Dropbox, etc?

On a very different note, is there any actual progress on moving Boxer to 64bit?

getaaron commented 4 years ago

@almeath I’d be happy to notarize it with my company’s Apple ID if that would be helpful.

almeath commented 4 years ago

On a very different note, is there any actual progress on moving Boxer to 64bit?

It depends what you mean by progress. The fork I am building from is focused on patching and fixing minor issues on what is currently an alpha release of Boxer 2, so that it is stable enough to keep using on newer versions of macOS. Being alpha software, it actually performs extremely well. @MaddTheSane's work has been very helpful in keeping Boxer going within that context. I do not think anyone other than @alunbestor would be able to add new features, especially not before an official 64 bit version is released. Hopefully, he will find the time to work on it because there is really nothing else comparable out there, in terms of ease of use and feature set. It is a great piece of software.

almeath commented 4 years ago

@almeath I’d be happy to notarize it with my company’s Apple ID if that would be helpful.

Thanks, but I think we are fine for now. I have been reading up on notarization, and there is no sign that Apple will remove the ability to run apps that have not been notarized. Maybe in a future version of macOS they might, but in Catalina you just have to follow the process you outline above, by right-clicking and selecting open.

ThrashinVictim commented 4 years ago

When importing a game, it asks for and finds the intall.exe and I click next, but then gives the error "session is not ready".

Is there a work around for this?

THank you

almeath commented 4 years ago

When importing a game, it asks for and finds the intall.exe and I click next, but then gives the error "session is not ready".

Is there a work around for this?

THank you

I think I have seen that behavior in all versions of Boxer 2 Alpha. If you just click "Finish Importing" at the bottom, you should then be able to finish creating the game box. Once you open the game box you should see a list of executable files on your C drive to choose from, which should include the install.exe. It should launch properly from there.

Also, if anyone gets a crash when browsing to your specified DOS games folder, go to General Preferences and untick “Use shelf appearance in Finder’s icon view”.

almeath commented 4 years ago

Providing a Dropbox link to the above mentioned build of 64-bit Boxer (Maddsv2 fork):

https://www.dropbox.com/s/u4s58x7cgbzgcv4/maddsV2%2010.19.2019.zip?dl=0

johannes87 commented 4 years ago

When trying to build the maddsV2 branch, I get this build error: boxer build error.txt

Error is: "Undefined symbol: boxer_handleDOSBoxTitleChange(int, int, bool)"

HEAD: d05de606c6ab8529e6809ab82e96b03e1e0070b1

Steps to reproduce:

MaddTheSane commented 4 years ago

This should be fixed in 1c9819f58b86c77843e588e54c2bf75d612cc38e.

almeath commented 4 years ago

Link to 64-bit Boxer (pre-built from Maddsv2 fork) as of November 7, 2019:

https://www.dropbox.com/s/ezz0pqgiikogqep/maddsV2%2011.07.2019.zip?dl=0

tkieft commented 4 years ago

On my machine the performance of this 11/7/2019 build is slower and more stuttery than DosBox 0.74-3, are you seeing the same thing?

almeath commented 4 years ago

I used TIE Fighter (SVGA version) as a reference point and tested in:

I did notice a significant performance degradation in terms of the frame rate in all builds of Boxer 2.0 alpha, including master. Whatever is causing this, it does not seem specifically related to the Maddsv2 fork.

There have obviously been big improvements in 64-bit optimization in DOSBox 0.74-3

For those that are interested, I have noticed better performance in Mojave and Catalina with the (experimental) SDL2 version of DOSBox SVN, which is maintained by Dominus on VOGONS forum and is available here:

https://www.dropbox.com/s/dl/wx7p7flug5heef8/dosbox-sdl2.dmg

johannes87 commented 4 years ago

I compared the sound of Prince of Persia 2 with MT32 emulation in Boxer 1.4 and Boxer 2.0 alpha (Maddsv2). It sounds different with Maddsv2. I prefer the 1.4 audio, as it sounds more clear somehow. Thanks for all the effort!

MaddTheSane commented 4 years ago

Only thing that I can think of that would change that is the fact that I bumped the version of munt that Boxer is built against from 1.4 to 2.3. If the change of audio is a deal-breaker, I'll look into downgrading munt.

olgleto commented 4 years ago

Tested with Dune CD which extensively uses sounds/music. In regards to sound quality an old release from March'19 from Yozy works better than November'19 maddsV2. Not sure about other games, but added ticking sound is a deal-breaker for at least that game

MaddTheSane commented 4 years ago

I've reverted MT32Emu and munt to version 1.4.

almeath commented 4 years ago

Link to 64-bit Boxer (pre-built from Maddsv2 fork) as of December 7, 2019 with reversions for MT32Emu and Munt:

https://www.dropbox.com/s/nwvw2q9kwxxbd2l/maddsv2%2012.07.2019.zip?dl=0

olgleto commented 4 years ago

@MaddTheSane potentially that is smth else, but the ticking sound is still there after the change

tempfile commented 4 years ago

Thank you guys a lot for picking up Boxer here, I really hope we get it running properly in the 64bit age. I'd contribute if my coding skills were not completely inadequate for crazy things like virtual machines....

I noticed quite the performance issues with the MT32 emulation. For example, all sorts of 90s VGA graphics transitions (like that pixel-by-pixel screen blend or palette shifts for a fade to black) are insanely slow. Also, moving the mouse fast makes the music slow down and choppy, also animation slows down immensely... stop moving the mouse, frame rate back to normal This happens even at full speed emulation... but it almost, but not fully, disappears when choosing Adlib!

Maybe some strange interaction between SDL and munt or something like that?

I tried madd's 7 Dec build on an early 2015 Macbook pro running 10.15.2.

chrismaaz commented 4 years ago

I've run "Chris 3D Benchmark" and "Quake" time demo on Boxer 2.0 alpha (64-bit master) vs DosBox 0.74-3 and there are HUGE performance differences between the two builds.

Chris 3D Benchmark

Quake Time Demo (320x200)

DosBox 0.74-3 64-bit is seeing massive performance gains over Boxer 64-bit which generally feels very sluggish. Especially compared to its 32-bit build.

Can anyone look into this and find out where the problem is exactly? A build of Boxer 64-bit based on the 0.74-3 codebase should result in similar performance, right?

Ran benchmarks on MacOS 10.15.1 and 10.15.2 on a 1,4 GHz Quad-Core Intel Core i5 with 16 GB ram.

MaddTheSane commented 4 years ago

Part of it might be how it does its compositing/rendering of OpenGL.

Instruments suggest that the call to glDrawArrays on this line is taking forever (119x): https://github.com/MaddTheSane/Boxer/blob/591d209fb5d21fe0e747b49a593e29b5bf7b3dcb/Other%20Sources/ADBToolkit/OpenGL/ADBTexture2D.m#L507

But looking around, it seems like this behavior is normal, if not desired.

What needs to be done is probably migrating to a more friendly way of handling compositing and shaders. Most likely migrating to OpenGL 3/4.1, or even Metal, might alleviate the issue. I'd be wary of migrating to Metal, especially if/when DOSBox/Boxer adds support for Glide games (most Glide wrappers use OpenGL. While using OpenGL is not mandatory, using an existing project will make it easier.). That and DOSBox is mainly OpenGL.

MaddTheSane commented 4 years ago

This Vogons post contains patches that add OpenGL 3 support. Those could end up being the basis for Boxer going forward.

chrismaaz commented 4 years ago

Part of it might be how it does its compositing/rendering of OpenGL.

Instruments suggest that the call to glDrawArrays on this line is taking forever (119x): https://github.com/MaddTheSane/Boxer/blob/591d209fb5d21fe0e747b49a593e29b5bf7b3dcb/Other%20Sources/ADBToolkit/OpenGL/ADBTexture2D.m#L507

But looking around, it seems like this behavior is normal, if not desired.

What needs to be done is probably migrating to a more friendly way of handling compositing and shaders. Most likely migrating to OpenGL 3/4.1, or even Metal, might alleviate the issue. I'd be wary of migrating to Metal, especially if/when DOSBox/Boxer adds support for Glide games (most Glide wrappers use OpenGL. While using OpenGL is not mandatory, using an existing project will make it easier.). That and DOSBox is mainly OpenGL.

Any idea if/when this is coming? I've seen threads of various SDL/SDL2 projects but I have little knowledge of that they actually do. Also I can't find any builds of these projects, it seems you will need to compile them your self, which is out of my area of knowledge.

Would love to see Glide support in Boxer too! But more speed should be first priority as Boxer is no fun using on Catalina right now.

MaddTheSane commented 4 years ago

It looks like DOSBox migrated from glDrawArrays to glCallList. Also: SDL2 is better maintained than SDL 1.2.

almeath commented 4 years ago

If anyone likes their DOS games in macOS apps/wrappers and is impatient to wait for Boxer improvements, I reverse engineered a DOSBox based GOG wrapper to use the SDL2 version of DOSBox SVN, with all the performance gains of 0.74-3 (and more). It also seems to fix audio bugs and the MT-32 music/graphics lag issue noted above.

I have it working on a 2013 and 2019 iMac, so it appears stable across old and newer hardware. It appears to work fine in Catalina.The only downside compared to Boxer is that the wrappers have to be manually configured for each game and MT32Emu/Munt is required if you need support for MT-32/CM-32L music.

If anyone is interested in trying it out, PM me on VOGONS forum and I will provide the link and instructions. I do not want to post it publicly because it might be legally dubious, given that I utilized a GOG wrapper.