Welcome to the ZDoom Forums!

by **johncurley** » Tue Oct 21, 2025 4:42 am

I assume the errors for not finding SDL2 were because the variable to enable cocoa support was not turned on or present in the cmake defaulting to SDL2. I'll look into it and also finish the implementation of the Cocoa backend, then start porting the main engine code to this and enabling it by default. I'll send some more pull requests through to ZWidget when I'm ready. Also what's the best way to contact the main engine developers for the work to integrate the renderer into the build? I'll probably have to add metal-cpp as a git subtree module as well.

by **dpJudas** » Sat Oct 18, 2025 3:17 am

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.

by **johncurley** » Sat Oct 18, 2025 1:50 am

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.

by **johncurley** » Thu Oct 16, 2025 12:55 pm

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()

by **dpJudas** » Thu Oct 16, 2025 6:05 am

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

by **johncurley** » Thu Oct 16, 2025 5:25 am

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.

by **Guest** » Thu Oct 16, 2025 5:13 am

dpJudas wrote: ↑Mon Oct 13, 2025 8:53 am 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

by **Graf Zahl** » Mon Oct 13, 2025 3:17 pm

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.

by **dpJudas** » Mon Oct 13, 2025 3:13 pm

OK I took a quick look at SDL3 since I got curious to the answers to my own questions and here's a few things I found:

Shader language depends on the backend you're targeting (SPIRV for Vulkan, MSL for Metal, DXIL for Direct3D)
GPU buffers can't be mapped
Vertex, fragment and compute shaders are the only shader types supported
No raytracing and acceleration structure support
Descriptor sets must be ordered a certain way (set 0 is for vertex shader, set 1 is for fragment shader)
No triangle fan support

So that means it can't do the persistent mapping current OpenGL and Vulkan backends are doing.
It can't do the raytracing dynlights VKDoom did.
It needs a workaround similar to the one I did for MoltenVK to draw the triangle fans.
It needs the GLSL compiler that the vulkan backend also uses to produce SPIRV, but now the sets are restricted to a certain format (doable).
The GLSL solution only works for when SDL3 targets Vulkan (and actually probably Direct3D 12 in the future as Microsoft is moving D3D12 over to SPIRV).

by **johncurley** » Mon Oct 13, 2025 2:39 pm

The first time I used GZDoom was on Linux and I remember that Ashes 2063 had quite atmospheric dark areas. When I played the game with the latest stable version on Mac, I thought maybe a change in monitor as I was using the laptop screen was causing issues with the gamma or the monitor was a TN panel and just couldn't get dark enough. However it turns out I managed to get the native version compiling and what a difference it makes! Color profiles and gamma curves seem to be translated accurately over, giving much darker and accurate rendering on macOS given the native window system.

I made some bug fixes to the codebase and it's put me into namespace scoping hell with ZWidget. But once I get it going I'll push my changes and people can see for themselves. I don't know much about SDL3 but I know that while Vulkan has tile rendering support being on mobile GPU's, it's not as tightly integrated as what Metal is on Mac. I'm also having some strange issues like the window system is trying to double load between ZWidget and the native cocoa backend. But I'll have to wait and see until I get everything namespaced properly due to forward declarations and variable name ambiguity.

by **dpJudas** » Mon Oct 13, 2025 2:24 pm

Graf Zahl wrote: ↑Mon Oct 13, 2025 1:33 pm The real problem is not that the new APIs may be faster but that the old ones are falling out of support. OpenGL never worked well on Macs, AMD and Intel - and Vulkan on Windows also never really delivered on its promises because again driver manufacturers do not care.
TBH, I'd rather invest my time into transitioning GZDoom entirely to SDL3 and using its 3D rendering interface which should map to what each platform supports best. I wouldn't want to write that middleware myself, actually.

I don't have any data to back it up, but my impression has actually been that OpenGL has become rather reliable to use on all platforms except Apple. Probably because Intel switched to using some Mesa solution and their old hardware got so old nobody uses the drivers anymore, solving the original problems we had with the Intel GLSL compiler and so on. That said, you're of course right that its only a matter of time where it be like using Direct3D 9 today. You can, but nothing new ever got added so you're out of luck the moment you want anything that wasn't already there.

I have never looked at SDL3's abstraction so I can't really comment on it. I did however get endless messages on Discord about how amazing WebGPU was and when I finally then took a look at it I was greeted by something that couldn't utilize the RT cores of the GPU. In other words, at least 7 years behind what D3D12 and Vulkan can do. They wanted me use a completely new shading language and their setup stuff was almost as complicated as what Vulkan itself uses. It DID have the advantage of at least validating the setup between shader and pipeline, and they did deal with the image transition insanity from Vulkan, but that was about it. Is SDL 3 better? I have no idea, but if I were to try port GZDoom over to it I'd at least first figure out how they imagine shaders to be compiled. For WebGPU the deal basically was that you had to write your own transpiler or drop support for all current material shaders out in the wild.

by **Graf Zahl** » Mon Oct 13, 2025 1:33 pm

dpJudas wrote: ↑Mon Oct 13, 2025 8:53 am 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!

The real problem is not that the new APIs may be faster but that the old ones are falling out of support. OpenGL never worked well on Macs, AMD and Intel - and Vulkan on Windows also never really delivered on its promises because again driver manufacturers do not care.
TBH, I'd rather invest my time into transitioning GZDoom entirely to SDL3 and using its 3D rendering interface which should map to what each platform supports best. I wouldn't want to write that middleware myself, actually.

by **dpJudas** » Mon Oct 13, 2025 8:53 am

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.

by **Chris** » Mon Oct 13, 2025 7:09 am

Wouldn't it be better to either help improve MoltenVk (a Vulkan -> Metal wrapper), or alternatively adjust GZDoom's use of Vulkan to work better with MoltenVk/Metal's quirks? Improving MoltenVk would benefit more than just GZDoom, and maintaining a few MoltenVk-specific code paths on top of the more widely usable cross-platform Vulkan renderer would probably be a lot easier than maintaining a whole separate renderer that can only be used on a single platform.

by **MartinHowe** » Sun Oct 12, 2025 2:19 am

Redneckerz wrote: ↑Sat Oct 11, 2025 1:55 pm Hard math means actually the maths behind things considering you feel the need to use AI to help you instead of learning the entire thing yourself.

But judging by this and your other response i also feel you are overly ambitious and won't accept anything other than ''i can make it happen'' so... you make it sound like you already have a renderer ready to go, but you don't.

Why don't you start smaller or show something you have made yet? Why instantly go for the moon without building the rocket first?

I don't see anything in the OP's statements as arrogant. If he wants to do this let him. He clearly has a game plan in mind. I will judge him by the final results. He makes it clear the AI is for something other than the core rendering, so it's no different than me writing 10000 lines of elite level ZScript but hiring Nash or Neoworm to do the spriting, which is something I regard as just a means to an end.

More importantly, if he's not accepting anything but "I can make it happen", then clearly (as mentioned) he has determination, perseverance, and a roadmap in mind and is likely to get there eventually, though maybe not as quickly as he might like. That isn't arrogance, it's being sure with reason of one's ground.

I speak from experience regarding what those three qualities can achieve, as anyone who knows what a "morph style flag" is will recognise.

Welcome to the ZDoom Forums!

Metal renderer

Post a reply

Expand view Topic review: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer

Re: Metal renderer