3D Graphics: OpenGL, Metal, Vulkan, Direct3D...

About 10 years ago I decided that OpenGL was the way to go for my cross-platform (Mac, Windows) app. In hindsight - right idea at the time but maybe a lot of pain that was un-necessary:

Windows OpenGL driver support is horrible - just this week I found that several major GPU driver brands have serious bugs even in their most modern Window 10 drivers.

MacOS OpenGL support has been different, in that they tend not to have “modern” support but the drivers do tend to be less buggy.

It sounds like OpenGL drivers for both platforms are not a high priority.

And for iOS of course, OpenGL ES is used.

I’m afraid to even look at what Android uses :slight_smile:

Long story short; a lot of time spent writing special-case code for various OSs x Driver combinations, all in support of doing something “standard.”

In the last year or so, things have become more complex: OpenGL is being replaced (?) by Vulkan, but Apple seems to not be interested in supporting it, instead pushing their own Metal. All the while, Direct X goes on.

What to do?

I’m tempted at this point to write my own wrapper library that encapsulates internally the Metal (mac) and Vulkan (win) APIs - the idea would be that I have fast performance and at least a little standardization.

1 Like

This sounds like the right idea, I think this is probably what most games companies do is create a wrapper for each OS and their respective technologies and then build upon that.

So I wrote this long message about how If I were you I’d also support OpenGL as Metal is only supported on 10.11 or newer. Only to then dig up enough evidence to suggest that 3/4 of the Mac users who are online, are already running El Cap or newer. 71% of the respondents to our beta testing program are running Sierra (poor souls).

I’m only using OpenGL to display CoreImage content, looking at these numbers, next year I’ll probably drop OpenGL in favor for Metal. That is if I decide to stick with CoreImage as it’s a bit of a beast; it’s great for simple things and makes you feel like it’s a really great image processing library, but it’s so hard to get to operate efficiently once you start doing more complicated tasks.

Oh an one final thought, maybe you could get some sponsorship from Xojo so they can replace their OpenGL control as it’s not 100% compatible with the modern macOS versions, I suspect sometime in the near future OpenGL may even be dropped from OS updates.

The intent of OpenGL is to be used cross-platform. Unfortunately each operating system seems to be preferring their own graphics. Windows is biased towards fast Direct3D, and OpenGL drivers are slightly slower and still good. Direct3D is owned by Microsoft and can only be used on Windows and XBox platforms.

Mac OS X appears to be biased to its new Metal API for iOS and OS X. My guess is that Metal will eventually be the equivalent of the proprietary Direct3D for Windows, but for Mac.

Linux uses OpenGL and I am not familiar with any other graphic versions on Linux.

Vulkan Chronos seems to be the possible replacement for OpenGL and it looks like it is gaining popularity. I checked my Windows programs and it appears to be installed on all of my Windows 10 versions (Go to Programs and Settings and look for Vulkan Runtime Libraries).

The graphics landscape is changing, and I hope that the cross-platform API wins - (crossing my fingers)

I think the wrapper idea is definitely the way to go. It allows you to build your applications using your own standardized interface, while you can then change the underlying implementation as technology changes with time, without breaking compatibility with your applications.

Have you looked at SPIR-V yet Michael? It is part of Vulkan but its intent is to provide a cross-platform intermediate language for hardware accelerated rendering. Ideal for any kind of wrapper.

If you are interested, I’ve started a small open source SPIR-V project for Xojo on GitHub that can be used to test/debug SPIR-V binaries.

Metal may be 64-bit only on Mac.

Hi Michael,

I just looked up on the Vulkan wikipedia page, and it appears that this API is on Android, Linux, and Microsoft Windows. The wikipedia entry mentioned that third party support is available for iOS and macOS and is called MoltenVK. I think your right, Mac OS X and iOS probably would need to be programmed in Metal, as I can’t find official support for Vulkan on Macs.

I am paraphrasing the words used on article (that I can’t find at the moment) and he compared OpenGL to Vulkan is like Python/Xojo to C++. The author further mentioned that it would be best for graphics programmers to understand and program OpenGL before learning how to program in Vulkan. I haven’t personally programmed in Vulkan, and am curious if anyone has programmed graphics in Vulkan?

Hi Micheal,

If you are planning on writing a wrapper library, would it be open source (Like Github) or would you keep it proprietary?

Thanks to all for helpful suggestions. I think that if writing a wrapper is something I do, it won’t be right away - there’s probably some value to waiting to see how things shake out - for example if Apple decided to support Vulkan or MS ports Direct X to mac (ideas I have zero evidence for) that would make one path more clear.

32-Bit and Carbon are already deprecated (unofficially), 64-Bit is the only way forwards for the macOS. This is after having lengthy discussions with an Apple engineer in trying to persuade them to fix a 32-Bit bug.

Many years ago I met a programmer for Sega, his role was within the intermediate layer team. So he and his team created a wrapper, whereby the game developers would write code against his wrapper. His team then wrote the code to interact with the different hardware (of course using conditional compiling).

If you are to embark on such a project, I think this is something that Xojo should get behind as it appears that in the near future OpenGL won’t work on the macOS and who knows if it will work on Windows. Ideally a good wrapper will also make Xojo’s 3D capability future proof as it could be updated to support whatever else comes along to replace the new tech today.

That’s just how the Xojo API works :slight_smile:

It’s the adapter pattern I think https://en.wikipedia.org/wiki/Adapter_pattern

Indeed in most instances, I think with OpenGL they’re done a lot to provide OpenGl for each platform, but it’s still tied into OpenGL, which the general consensus is that it’s no longer fashionable, thanks to each OS platform doing it’s own thang.

I’m hoping that a Xojo 3D wrapper, would be able to not only wrap OpenGL where appropriate, but also the newer replacements for OpenGL. Therefore those that use Xojo for 3D would in theory be largely undisturbed by the OS makers shift. It’s a monumental task, there is no denying it and Xojo already has their plate overflowing, and with only a small amount of people using it, I fear that it’s a too big of a task for just a couple of developers to handle.

Just thinking out loud - would a good alternative be the latest version of OpenGL? The last version runs on all systems, and would likely have a healthy performance boost over the current OpenGLSurface control. Just a thought…

Hadn’t Xojo pretty much dropped 3D? Wasn’t that the original reason for writing an OpenGL wrapper? Which Xojo then incorporated?

From the Docs: "“the OpenGL module are based on the OpenGLSurface plug-in from Tinrocket, LLC at http://2002-2010.tinrocket.com/software/openglsurface/index.html”.

I don’t think (and that is only my impression) 3D is of low priority for Xojo, I think it is not even on their radar.

MBS3D?

Should Xojo (or anyone for that matter) decide to implement an “adaptive pattern” for 3D rendering, it would be my opinion that they should focus on hardware accelerated rendering as a whole, not just 3D.

Something that can be used in both the 2D and 3D world will have more value for anyone who works with graphics.

Interesting thread, I also played a little bit around OpenGL and Xojo, but I have to say that this makes no fun. Most of the time you are programming workarounds. Things works well under macOS, a little bit under Windows, a little bit or not with linux and so on.
I tried to write a little 2D Retro Ego shooter. The first version was written with Objective C and Allegro 5 which works very well. Now I tried it with Xojo and the OpenGL Surface.

https://maurix.net/2017/01/22/writing-games-with-xojo/

Has anyone looked at writing Metal (Metalkit) code in Xojo?

I have not, but was reading the documentation and came across this

[quote]When building the sample, Xcode compiles the AAPLShaders.metal file along with the Objective-C code. However, Xcode can’t link the vertexShader and fragmentShader functions at build time; instead, the app needs to explicitly link these functions at runtime.
Metal shading language code is compiled in two stages:
Front-end compilation happens in Xcode at build time. .metal files are compiled from high-level source code into intermediate representation (IR) files.
Back-end compilation happens in a physical device at runtime. IR files are then compiled into low-level machine code.
[/quote]

from https://developer.apple.com/documentation/metal/hello_triangle

Does this mean that we wouldn’t be able to use Metal or Metalkit in Xojo? I’m worried about the “.metal files are compiled” part - it sounds like Xcode is required. Am I misreading this?

I’m trying to use Metal for Core Image as OpenGL seems royally borked in High Sierra; Metal requires 64-Bit, but Xojo tells me it can’t find the Metal or MetalKit library when compiling for 64-Bit. <https://xojo.com/issue/48376>

I guess the writing on the wall for OpenGL on macOS, it’s done.

@Sam Rowlands: did you get any progress on your Feedback case? I’m not in front of my Mac at the moment. Would a plugin instead of declares work?

This sounds weird, because by the documentation all macOS declares are soft declares, but …

soft Declare Function MTLCopyAllDevices Lib "Metal.framework" As Integer Dim thisValue As Integer = MTLCopyAllDevices
and no linker error anymore + a valid value.