There are transpilers (cross-compilers?) that translate from HLSL to GLSL and back and into every other shading language out there, there's really a lot of such tools.
> Secondly as I understand it the Vulkan API is much more low level and barebones than DirectX
Vulkan is about as low-level as Direct3D 12, which has not much in common with Direct3D 11 and lower, just like Vulkan has not much in common with OpenGL. OpenGL is (very roughly) equivalent to Direct3D 11, and Vulkan is more like Direct3d 12. The thing is that switching between the similar APIs is a lot of work, but does not require large refactorings, whereas switching from OpenGL/Direct3D11 to Vulkan/D3d12 requires more fundamental work.
Ironically Microsoft have open-sourced a Clang-based HLSL compiler that could be used as a front-end for a Vulkan backend.
https://github.com/Microsoft/DirectXShaderCompiler
https://blogs.msdn.microsoft.com/directx/2017/01/23/new-dire...
That would force them to show the results of the effort and the $texas-sized dollars contributed. As long as they can keep pointing to "well, we had to make a major architectural change.." they can continue pushing the idea that they'll deliver.
Dig into the criticism of them the last couple years. This one is from ~20 months ago: http://www.pcgamer.com/derek-smart-star-citizen/ or ~4 years into development.
https://archive.is/y1kMK#selection-3799.0-3964.0
Not to mention his even weirder obsession with Sandi Gardner, Star Citizen's community manager.
https://www.reddit.com/r/DerekSmart/comments/4w0w51/has_doct...
Still, star citizen is a train wreck. Wasn't the big thing last year to "rewrite all the net code".
They're just rearranging the deck chairs over and over waiting for the company to go under
I was a $20 backer on the kickstarter campaign and have since gone in for about $100 total. Obviously I wish it had come out years ago, but I'm still optimistic about the project, and fine with the drastically expanded scope. The alpha releases are far from perfect, but I've already had more fun with it than some other games that I paid much more than $20 for. That's what pushed me to back it further. There's just something incredible about the level of detail of the world, going from first person through a space station, out the airlock, walking over to the landing pad, hopping into a fully detailed spaceship (not just a disembodied camera in a cockpit), and flying off to fight space pirates.
This is a game that wouldn't be possible to make with the traditional publisher driven funding systems. Maybe it'll turn out to be impossible to make this way too, but I don't think so.
If you have a couple of hours to put videos on in the background, the last three "Around the Verse" studio updates have been pretty good:
March 2 (Frankfurt) - Hurricane and Character Customization https://www.youtube.com/watch?v=NGzDI2wUqf0
March 9 (Austin) - Weapons: The Game's Arsenal https://www.youtube.com/watch?v=c_v-hMu_h5s
March 16th (Manchester) - Level Design https://www.youtube.com/watch?v=-c2DogQL95o (watch past the credits for in-progress ships)
Or for a quicker coverage, here's a list of short excerpts from the last video. Quality isn't great, but it gets the point across: https://www.reddit.com/r/starcitizen/comments/5zu3of/atv_gfy...
On the other hand, CryTek's financial trouble over the last several years was an enormous benefit to Star Citizen, because it let them build the Frankfurt office with a bunch of CryEngine experts who were tired of not getting paid on time. They're the folks who made the full scale and crazy detailed procedural planets possible.
When alpha 3.0 lands later this year (hopefully...) you'll be able to fly down and land on these from orbit: https://www.youtube.com/watch?v=uU0hDriMqXo (short excerpt from one of the studio updates linked above)
Not necessarily. Vulkan now supports HLSL input too, which is compiled into SPIR-V, same way GLSL is. You don't need HLSL → GLSL translation step.
GLSL is just one option to write shaders for Vulkan (the only inmportant thing is that SPIR-V code can be generated). I can even imagine quite well that one could write a compiler which generates SPIR-V code from HLSL shaders.
> Secondly as I understand it the Vulkan API is much more low level and barebones than DirectX, meaning it'll be a lot of work to shore up the differences.
DirectX 12 is similarly low level.
> I may be wrong here, but it seems to be like the developer is saying that a DirectX -> OpenGL change is no big deal
DirectX 11.x is similar in "level" to OpenGL 4.x (though the difficulties are a little different - I don't want to go into details here). Similarly DirectX 12 and Vulkan are similar in level (much more low level than their predecessors). No wonder since both Vulkan and DirectX 12 are "strongly inspired" by Mantle. Additionally Vulkan was intended as the succesor of OpenGL and DirectX 12 as the succesor of DirectX 11.x.
> surely just finishing the damn gameplay should be the focus?
That is what you wish. :-)
Khronos are working on building this into the official SPIR-V compiler: https://github.com/KhronosGroup/glslang/issues/362
Star Citizen definitely appears more like an ongoing crowd-funded video game research and graphics research project at times.
DX12 is not DX11+1. It's a clone of AMD's Mantle, which was eventually given to Khronos, so they make it into Vulkan. The main advantage of Vulkan is that it runs almost everywhere. DirectX 12 doesn't.
DirectX 12 runs on XBox One, while Vulkan does not:
> http://www.redgamingtech.com/directx-12-for-xbox-one-is-here...
And for OSX/iOS, you have to use OpenGL or Metal.
And the Switch uses Vulkan; while Vulkan on top of Windows (including 7 and 8/8.1) supports Linux and Android. For iOS and macOS there's MoltenVK, but I can't speak for its quality.
https://blogs.nvidia.com/blog/2016/10/20/nintendo-switch/
So it remains to be seen which one gets the love of game developers.
That's actually a fairly interesting question, given the percentage of games that come out for Nintendo platforms which are exclusive to that platform (or at least to the Nintendo family of platforms). There are all the first party titles, and then there are all the esoteric games which don't really fit the control schemes of the other platforms (but the switch is less unique in this aspect). I imagine games targeted purely at Nintendo platforms might use their proprietary API, especially first party games, which might get the API changed based on their needs.
It doesn't run on Sony PS4, Nintendo Wii U, XBox ONE, UWP, OS X, iOS, tvOS.
Even on Android it is going to take a while until most people exchange their handsets for ones having it, because the majority will never get an upgrade for Android 7.
Only OpenGL ES 3.2 is mandatory.
This was probably made for chipset producers; if Vulkan was made mandatory, you would see exactly 0 updated devices.
Source: Android 7.1 Compatibility Definition Document
Chapter 7.1.4:
Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodied and detailed in the Android SDK documentations. Device implementations SHOULD support OpenGL ES 3.0, 3.1, or 3.2 on devices capable of supporting it.
Chapter 3.3.1:
Note that device implementations MUST include libGLESv3.so and in turn, MUST export all the OpenGL ES 3.1 and Android Extension Pack function symbols as defined in the NDK release android-24. Although all the symbols must be present, only the corresponding functions for OpenGL ES versions and extensions actually supported by the device must be fully implemented.
Chapter 3.3.1.1:
Device implementations, if not including support of the Vulkan APIs:
- MUST report 0 VkPhysicalDevices through the vkEnumeratePhysicalDevices call.
- MUST NOT delare any of the Vulkan feature flags PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and PackageManager#FEATURE_VULKAN_HARDWARE_VERSION .
Chapter 7.9.2:
Android handheld device implementations MUST identify the support of high performance virtual reality for longer user periods through the android.hardware.vr.high_performance feature flag and meet the following requirements.
...
- Device implementations MUST support OpenGL ES 3.2.
- Device implementations MUST support Vulkan Hardware Level 0 and SHOULD support Vulkan Hardware Level 1.
....
If the engine needs two rendering interfaces, the effort is exactly the same as OpenGL ES + whatever else.
Unless you are suggesting game developers should be happy to sell only to LG V20, Samsung S7 and Google Pixel owners.
Turnaround in the mobile hardware space is even faster than on the desktop (let alone stagnating consoles), so Vulkan availability is much less of an issue there.
It doesn't matter if the drivers are available if those GPUs aren't on the motherboard.
Currently Vulkan is constrained to 2.8% of the Android market.
> Turnaround in the mobile hardware space is even faster than on the desktop (let alone stagnating consoles), so Vulkan availability is much less of an issue there.
Only in US, not everyone around the world, specially in countries where pre-pay is the way to go, changes their mobile every two years.
My point is, this situation will be shorter than on the desktop. Because as I said, the turnaround of mobile hardware is faster.
> ly in US, not everyone around the world, specially in countries where pre-pay is the way to go, changes their mobile every two years.
In US too, not everyone is going to buy every new model. I'm talking however about manufacturers making them. That happens pretty fast. So Vulkan support on new hardware is probably already a given and this whole thing is a non issue. Any new technology has adoption period.
Well, I would say, it is not a ordinary game. And even though I don't know about their Engine, but normally it should be possible to make those changes on the engine without any effect for the gameplay, since they wanted to support OpenGL before.
This feels like a pretty handwavey statement. For one, all shaders would need to be converted from HLSL to GLSL, which could become quite a big task depending on the amount of shaders, and testing of all changes.
Secondly as I understand it the Vulkan API is much more low level and barebones than DirectX, meaning it'll be a lot of work to shore up the differences. I may be wrong here, but it seems to be like the developer is saying that a DirectX -> OpenGL change is no big deal, but swapping out your foundations is a major big deal. The concepts may be the same but the APIs are still hugely different.
And why is this even a concern for a game started in 2011? It's mind boggling that they are making these kind of decisions 6 years into development, surely just finishing the damn gameplay should be the focus?