I'm working on cross platform rendering library that will make it easy to create games with just Swift code.
It still has a ways to go, but will be open source once it reaches a state that would be useful to people.
If you like it, leaving a comment here or on the video will help motivate me to finish it quicker
Special thanks to @compnerd for getting DirectX into WinSDK for the Swift 5.4 release and making a fantastic sample project that saved me a ton of headache.
This looks great! Can't wait for it to be open-sourced!
Just 1 suggestion though. Given that the entire thing is written in Swift, I think it might be even better if all the identifiers drop the "UG" prefix. Prefixes such as "NS" and "UI" etc. exist in Apple's frameworks because symbols are global in Objective-C. Swift doesn't have this problem, so it shouldn't need the prefixes. Here is a video from WWDC 2019 that covers this (1:50 - 3:20).
Thank you! And thanks for taking the time to provide feedback.
You’re absolutely right, and I did my best to avoid the prefix. The problem is most projects using this package will want to use terms like Camera, Scene, and Geometry, so in most projects you’d have to type UniversalGraphics.Scene to avoid a collision. I concluded that this would happen to the majority of users, so I went with the prefix to make sure its a pleasant package for everyone to use.
My other packages, like GameMath don’t use a prefix as I don't expect overlap to be a common issue.
I also wanted to add that many people still opt for prefixes when using SwiftUI. Apple, in their infinite wisdom, chose some very common names for SwiftUI components. By prefixing everything, one can avoid this issue. An example is a SwiftUI is “Circle” which would cause conflicts with a locally defined Circle if you use Swift UI.
Your local types should override framework types every time, requiring you to use SwiftUI.Circle to use the SwiftUI type on a case-by-case basis, or import struct SwiftUI.Circle to override the the preference fo your Circle.
This projects sounds amazing!
But why have you choosed OpenGL instead of the successor Vulkan?
It’s much more efficient and works so much better on newer devices.
I can really recommend you to switch to Vulkan befor it’s too late.
I'll probably add Vulkan at some point, especially if I find a way to deploy to Nintendo Switch. But it's currently not worth the time. OpenGL is available everywhere Vulkan is and I already know OpenGL.
I'm not expecting Linux to be a popular platform for my games and that's the only platform Vulkan would improve. I need to get back to working on my games, so unnecessary complexity is a dealbreaker for now.
I'll definitely revisit Vulkan when I have time, but I'm trying to actually make games so I can't spend all of my time build libraries. PS4/PS5 will require a proprietary API too and that will also be higher priority than Vulkan.
That's very true. Mobile isn't currently a concern for me, but UniversalGraphics does support iOS out of the box simply because I wanted to target tvOS and I did make sure my OpenGL implementation is ES 3.0 compliant so Android support could come well before I add Vulkan, which again I plan to do eventually.
