Metal renderer

[Graf Zahl]

Thanks for doing that work. In that case it's pointless. I really was expecting it'd add some glue to make it easier to use. But this looks like a lowest common denominator implementation that's ultimately worthless for any serious development. Especially the non-mappable GPU buffers are really a joke and sound like they really cared more about low end support than providing something good.

Pity.

Microsoft moving D3D12 over to SPIR-V is news to me. If they do that, a native D3D12 backend may be feasible.

[Guest]

If you got a working Cocoa backend for ZWidget feel free to PR it. You can already use ZWidget on macOS via its SDL 2 backend, but a native Cocoa one would be preferred once it reaches a similar level of maturity. Even without a Metal renderer it would be useful for GZDoom as it would allow the transition from platform specific launchers to be completed (*).

Regarding writing a Metal renderer, note that porting over the GLSL by hand will only get you partially there as lots of mods come with their own shaders that are also written in GLSL. With the Vulkan backend the MoltenVK layer converts it (GLSL -> SPIRV -> Metal IR whatever that's called), so if you're planning on full support you'd have to find a way to deal with the GLSL coming from mods.

Having worked with Direct3D 9, 11, 12, OpenGL and Vulkan on various projects, it has been my experience that there are no obvious performance benefits to be gained by using the newer ones. You can, theoretically, get better performance with D3D12/Vulkan/Metal, but it depends heavily on re-architecting the entire rendering subsystem to build up command buffers on multiple threads. Simply converting existing commands from an older API to a newer one generally won't do anything. Half the times I've done it I've actually lost performance compared to the older API. Driver heuristics in the older APIs do a lot of stuff that newer APIs simply don't offer (you have to do it yourself), which means stuff was using multiple threads with OpenGL and now it all runs on a single thread on Vulkan and so on. In any case, good luck!

*) Can it already do it with the SDL backend? Don't have an Apple hardware anymore so I didn't try it to find out.

I'll pr soon when the code is more stable. It'll build though, I've turned off the metal renderer code for now as it's only a stub. Took me ages to refactor the ZWidget library though due to scope collision with MacOS headers. https://github.com/johncurley/gzdoom/tr ... nderer-dev

[johncurley]

Ugh, I put the submodule build files into the repo. I'll delete the branch and create a clean one but the code will work. There's bugs though in the window from i_video.mm that need addressing and implementations/clean ups. It's a mess but nearly there. Also worked on the cmake file for macOS.

[dpJudas]

I took a quick look at the branch and here's a few comments of mine:

Partially converting zwidget to use a namespace will not be a proper way to do it. Either the entire library needs to be namespaced or the scope collision would have to be resolved a different way - maybe by moving CocoaDisplayWindow::Impl out of the main class and isolating Cocoa from ZWidget's main headers. I can live with the partial rename for a PR though. I'd rather do the full namespace rename myself if that turns out to be required as its a library wide change.

Note that ZWidget is an external library (https://github.com/dpjudas/ZWidget) inlined into the GZDoom codebase via git subtree. The ZWidget main repository is usually ahead of what GZDoom is using currently, so you may find that all those namespace changes could give you trouble if you ask git subtree to convert it into a PR for the main repository.

About all the other changes to the GZDoom repository (the cmake changes in particular), someone else will have to comment on those as that's base GZDoom stuff. Only question I have for that part is that it looks like its now trying to use Apple's OpenAL implementation? Correct me if I'm wrong, but last I owned a mac (10 years ago) the Apple implementation was basically broken and abandoned by Apple.

Other than that is looks quite interesting what you've done so far.

PS. this post was written before your last post - not sure if what you did now changed what I commented on

[johncurley]

Hi dpjudas,

I agree about the namespacing issues with ZWidget. It was a quick hack, it had me stuck for a long time and maybe namespacing and isolating the Impl sounds brilliant. I'll keep working on it as I wasn't happy about that change either. I was embarrassed really to release it but I wanted to show a proof of concept. Most of the drawing is happening in the platform directory rather than ZWidget for the main application itself. So once ZWidget is supported, I'll focus my efforts there. Thanks for the tip though, I'll definitely try doing that to isolate the library. There's also some unimplemented class methods in ZWidget itself that I'll take a look at.

In terms of the OpenAL implementation, it's actually a really nice fix. There's no static library in Homebrew, so it calls the dynlib but there's a workaround for the non standard path detection and also the mac build calls the correct headers hence the deprecation warnings when it's built. I had to ask Ai for help with that one but it's a beautiful piece of code and everything is functioning using the correct OpenAL-Soft implementation with no calls to system headers unless openal-soft is not installed. Once the VULKAN_SDK is set you can just run cmake .. now instead of having to pass it command line arguments for path detection as outlined here: https://www.mtmckenna.com/posts/2025/04 ... n-mac-os-x

Code: Select all

# *** FIX for Homebrew .dylib issue: Force DYN_OPENAL ON if a .dylib is found. ***
  if( OPENAL_LIBRARY MATCHES "\\.dylib" )
  # Force dynamic loading since the static library is unavailable from Homebrew.
  set( DYN_OPENAL ON CACHE BOOL "Dynamically load OpenAL (forced ON due to Homebrew .dylib)." FORCE )
endif()

[johncurley]

I ended up patching ZWidget with some Apple specific preprocessor macros so I'll pull request to the main ZWidget repo soon and you can decide whether you want to namespace the library in the near future but for now it's perfectly functional. And also the logic for the OpenALSoft detection is not entirely correct so I'll try update that. But the ZWidget:: namespacing is now outside the main repository and it's all functional as far as I'm aware.

[dpJudas]

Cool. Looking forward to taking a look!

I'll probably rename the namespace to lowercase and possibly shorter (zwidget:: or maybe zui::). C++ namespaces is such a pain.