Metal API better format

[matthus 0]

Currently, Metal API support in game articles is only displayed if set to true. It should be displayed with a red cross if it set to false, to differentiate with games with unknown Metal support.

Also it should be displayed as "Metal" and not "Metal support", like others API : D3D, OpenGL and Vulkan...

To test this behavior, check Firewatch game article for game without Metal support and Hollow Knight game article for a game with Metal support.

Edited Sunday at 05:49 PM by matthus
I misclicked Tab and send the post half-written ;(

[radioheadsucks 0]

On 4/12/2026 at 7:45 PM, matthus said:

Currently, Metal API support in game articles is only displayed if set to true. It should be displayed with a red cross if it set to false, to differentiate with games with unknown Metal support.

Also it should be displayed as "Metal" and not "Metal support", like others API : D3D, OpenGL and Vulkan...

To test this behavior, check Firewatch game article for game without Metal support and Hollow Knight game article for a game with Metal support.

wouldn't this be kind of pointless, though?

just looking through the editing guide, graphic API support is listed based on what is available for a game, not on what isn't - so if what you're proposing was to be implemented, every single game that doesn't have, say, support for Vulkan would have to be explicitly edited in order to mention that they don't support Vulkan, which (in my opinion) is just more confusing than simply editing a game article in order to explicitly note Vulkan support for a game

I will say though - changing the header name to simply "Metal" is a solid idea

[Aemony 162]

I've dropped the "support" part of both Metal and Mantle (precursor to Vulkan). Note that the parameters remain unchanged so they'll still be called "metal support" and "mantle support".

On 4/13/2026 at 8:57 PM, radioheadsucks said:

just looking through the editing guide, graphic API support is listed based on what is available for a game, not on what isn't

This hits the nail on the head -- all of the render APIs are handled the same right now: if you set an API to "false" or "unknown" it'll be hidden from the page to minimize the amount of unnecessary data that is shown for visitors. This is in contrast with many other templates, yes, but it is correct and works exactly as intended for the API template/table.

[matthus 0]

I understand why it works like that, but I still feel like there is something wrong without knowing exactly what.

Just for context most mac game articles are lacking this API section (support or not of Metal), and knowing if a game supports Metal is kind of a deciding factor and key information. Because if it doesn't, then it will very probably have performance issues (Vulkan and DirectX don't officially exist, and OpenGL is somewhat deprecated on MacOS).

So that's why I think it would be great for Mac users to know if a game does NOT have Metal support on a game article (without having to go to the article source to check if someone actually filled it).

I think it would not add unnecessary clutter to make APIs marked as "false" visible to visitors. Especially because most (if not all) of the time, if an API is not supported then it is not even marked as false (at least on the few articles i checked). So the only time it would really be visible, is when it is important to know it's not available (for the Metal API for example).

I hope I made myself clear enough and that I'm not too insisting on this, and if you still think it's wrong I will gladly read your opinion on this matter.

Thank you for removing the "support" part of Metal and Mantle by the way 🙂