DRD Team

Now that the core profile is working on Mac, I have been thinking about providing an official macOS download for the upcoming release.

To see what the current Mac version has, I did a comparison of my GZDoom repo with the GZDoom-Mac one, here's what I found:

- the GZD-Mac repo contains all the license files. These should be added to the ZDoom repo, so that every fork gets them. (I already did that)
- the GZD-Mac repo has the HQnX stuff completely differently organized with identical content, this should be aligned to use the same layout.
- the GZD-Mac repo implements an FXAA postprocessing shader. Is this something that could/should be backported? I read up on it and it sounds like an interesting concept.
- the GZD-Mac repo adds two files "file_chasm_bin.cpp" and "celtexture.cpp", but never references them from any other piece of code. So A) What is this and B) is this of any use for backporting?
- the GZD-Mac repo adds 4 MAPINFOS for x360 and xbox versions. Are these still needed? I thought the current BFG edition definitions took care of these already.
- the GZD-Mac repo contains xbr scaling code, which of course is not really usable due to license conflicts.

If this becomes an official release it should of course use the same version number.

Any thoughts?

Graf Zahl wrote:- the GZD-Mac repo has the HQnX stuff completely differently organized with identical content, this should be aligned to use the same layout.

Honestly I have no idea why I spent time on this. This single (probably) useful thing is an ability to select different upscalers for fonts, textures and sprites.

Graf Zahl wrote:- the GZD-Mac repo implements an FXAA postprocessing shader. Is this something that could/should be backported? I read up on it and it sounds like an interesting concept.

I'm not sure about the license, asked the author but got no response. It's heavily based on the original FXAA article and I guess it can be rewritten from scratch using textureOffset() in Core Profile.

Graf Zahl wrote:- the GZD-Mac repo adds two files "file_chasm_bin.cpp" and "celtexture.cpp", but never references them from any other piece of code. So A) What is this and B) is this of any use for backporting?

Useless for everyone and can be removed freely.

Graf Zahl wrote:- the GZD-Mac repo adds 4 MAPINFOS for x360 and xbox versions. Are these still needed? I thought the current BFG edition definitions took care of these already.

They have subtle difference from BFG edition. Also there is a loader for .disk files but I doubt that someone uses it.

Graf Zahl wrote:- the GZD-Mac repo contains xbr scaling code, which of course is not really usable due to license conflicts.

The author allowed to use xBRZ with ZDoom derived ports for non-commercial purposes.

Graf Zahl wrote: If this becomes an official release it should of course use the same version number.
Any thoughts?

I think the official releases should be made from the master branch. There are some questions about packaging and use of third-party libraries (static or dynamic OpenAL, Apple's framework or OpenAL Soft, what about FluidSynth, etc). I'm doing this by shell script hard-coded for my fork. It won't help much with the master branch.
Possible approach would be to create a separate repository with third-party libraries and build script that does source code checkout and produces a disk image with application bundle, licenses, etc.

_mental_ wrote:

Graf Zahl wrote:- the GZD-Mac repo contains xbr scaling code, which of course is not really usable due to license conflicts.

The author allowed to use xBRZ with ZDoom derived ports for non-commercial purposes.

If that's the case it'd be great. Do you have this in written form? If so it should be added to the licenses so I canl add support for it.

Graf Zahl wrote: If this becomes an official release it should of course use the same version number.
Any thoughts?

I think the official releases should be made from the master branch. There are some questions about packaging and use of third-party libraries (static or dynamic OpenAL, Apple's framework or OpenAL Soft, what about FluidSynth, etc). I'm doing this by shell script hard-coded for my fork. It won't help much with the master branch.
Possible approach would be to create a separate repository with third-party libraries and build script that does source code checkout and produces a disk image with application bundle, licenses, etc.

My main problem is, I have very little experience in creating a Mac distribution. Ideally, CMake should output something that can be readily compiled into a .dmg file, even when the third party dependencies are not shipped along in the repo.

Graf Zahl wrote:If that's the case it'd be great. Do you have this in written form? If so it should be added to the licenses so I canl add support for it.

I asked a permission here.

Graf Zahl wrote:My main problem is, I have very little experience in creating a Mac distribution. Ideally, CMake should output something that can be readily compiled into a .dmg file, even when the third party dependencies are not shipped along in the repo.

I can make some sort of build environment for the master branch, like run script to make .dmg with everything included.

_mental_ wrote:

Graf Zahl wrote:- the GZD-Mac repo adds 4 MAPINFOS for x360 and xbox versions. Are these still needed? I thought the current BFG edition definitions took care of these already.

They have subtle difference from BFG edition. Also there is a loader for .disk files but I doubt that someone uses it.

Are these even used? I do not see them referenced anywhere. Same about .disk files. None of the files which are different to GZDoom's master repo handle this.

Xbox Live verion's .disk files are handled in src\resourcefiles\file_wad.cpp and that code referenced in src\resourcefiles\resourcefile.cpp.
Xbox WADs can be loaded from them or directly. These WADs have two extra levels each, so new MAPINFO files and IWADINFO entries were added. Xbox 360 WADs use the title picture different from the original Xbox. That's why there are four new files/entries.
I did it just out of curiosity as I believe noone is interested in those changes except me.

Yeah, my error. The compare tool was configured incorrectly.

I just now did a real comparison. One thing I noticed immediately is that the configuration file lookup has been changed completely. Since you are the Apple expert, my question: Would it make sense to backport this to ZDoom?

Hard to say. If users are already familiar with this setup for years, we must keep it. Apple requires to use a folder like in my fork for AppStore submissions as it's a part of so called sandboxing.
I think we don't need to change this for official (G)ZDoom releases. At least it shouldn't be done without user friendly migration procedures: read config from old place, save to new one as a bare minimum. So it's better to keep it as is to avoid unnecessary complains about hand made changes in .ini that have no effect.

EDIT: I did lots of non well thought changes over the years which are not worth being integrated into the master branch. That's why I'm promoting the official release from it instead of my fork.
Also I hope Blzut3 will help us with information and maybe scripts to do it better. I'm talking mostly about signing and .dmg packaging.

For the config file, my standpoint is to obey the rules of the operating system, if the file cannot be stored in the application directory. If GZDoom can obey sandboxing rules it's something I'd do.

Roughly speaking the rules are the same as for Windows. A well behaving app will store its config files in its AppData folder, which it queries from the OS. This isn't really different from Windows where you also cannot place the config files in the Program Files folder.

I was wrong, changes in user's files placement was unrelated to sandboxing at all. They were done for two reasons: Apple suggested to use this location and it was convenient to me to have the single directory with all IWADs, saves, config, screenshots, cached nodes...

Now the first reason appeared to be wrong. At the moment the Library folder is hidden from users by default. I even created a helper tool (and put it to .dmg) to access the user's directory because of this. The old guide was removed from developer's site and the current documentation says the following:

The Application Support directory is where your app stores any type of file that supports the app but is not required for the app to run, such as document templates or configuration files. The files should be app-specific but should never store user data. This directory is located inside the Library directory.

Are saved games or screenshots qualified as user data? The answer is very subjective I think.

Sigh... As I said most of changes in my fork weren't well thought. Number of users were very small and I received almost no complains, so I was changing everything I imagined.
I already thought about giving up with my fork and using it for pull requests only. Lacking of devbuilds and official releases for macOS is the only cause to continue.

I think ZDoom gets most things correct. The only one I wasn't certain about is the INI. Interestingly, this is done differently on Windows than on macOS. On Windows it goes into the roaming app data, which is normally a hidden folder.

To be honest, I am not sold on depending on a deprecated API to get these system paths. As a first step, m_specialpaths should be split up into 3 different files, one for each of the major OSs, then make the macOS version Objective C++ and use whatever Apple currently recommends to get these paths - and use the correct ones for everything.

(On the other hand I guess, we are again stuck in "We must support the oldest OS version possible for the handful of users with antiquated hardware" land here, so maybe retain the old stuff for PowerPC?)

FSFindFolder and friends are old Carbon function, only needed for OS 9 support. I thought those functions didn't even work for 64 bit builds. Should be switched to NSSearchPathForDirectoriesInDomains, or NSFileManager if its changed into a .mm file.

I thought about the same, at least to implement special paths with Cocoa. I'll try to do it without dropping support for old OSes.

dpJudas wrote:if its changed into a .mm file.

I'll take care of that part ASAP.