The massive battle part will bring massive performance requirements. Though i would be worried more about Server performance there than client performance.
My guess is that the procedural stuff is the performance hog, not the ships, so rendering a hundred ships might have a fractional impact comparing to rendering a planet.
On client side yes, on server side definitely a question of player number / networking load.
1 Like
Iâm not sure how asset streaming will impact performance: if anything, it will worsen as the game now needs to load assets on the fly, rather than prestaging it all.
I think youâre underestimating the impact of the 100+ ships in a single area pew-pewing and dying. There are certainly optimizations that need to be made, but there will also be an increase in quality of texture/render, and Iâm not sure how they will balance out.
All-in-all, I feel that the switch to a new API would greatly benefit the intended hundreds-to-thousands of players and drastically lower the required hardware.
1 Like
And this is best done with staying on a more than OK API such as D3D11, instead of yet losing more time on a new API.
Now once again, this discussion is sterile unless thereâs a real benchmark from INovae (which will come in quite a few months from now) or an annoucement from Vulkan concerning their shader compiling.
Besides, whatâs a game with beutiful graphics if thereâs nothing to be done? I donât want a âyet-another-ED-nice-screenshots-wow-thatâs-allâ game.
1 Like
Alright, i think i understand the gist of it, correct me if iâm wrong. From a purely laymanâs perspective:
Vulkan and DX12 seem to be the same across the board. There seems to also be a huge performance gain going from DX11 to DX12/Vulkan. The main advantage of Vulkan is that it can run on almost anything while DX12 is forcibly locked to Windows 10. Vulkanâs shader compiler, the thing that translates game code into graphics commands, doesnât seem to exist at all and the devs are forced to use âshader translatorsâ for a roundabout way to translate game code into graphics commands in a process similar to translating between French and English with a German-native translator with the sequence: French->German->English then English->German->French instead of French<->English directly. (man thatâs a long sentence)
This translation process takes up time and thatâs what drives down the framerate, with a net result of little to no performance gain compared to DX11. So what we need is a direct translator (shader compiler) either done by someone else (coin toss luck) or developed by Khronos (unlikely). While inovaestudios would love to develop its own shader compiler it is currently impossible given the limited funding. Funding would be needed to hire and support one or several programmers working full time on game engine and shaders for initial development and continued support of the game. Ideally the game would support both Vulkan and DX12 but it is impossible under current resources.
The Vulkan Programming Interface itself is working well, itâs the shader compiler that âis a messâ.
Does that sum it up?
Sort of. A better analogy would be driving to a friendâs house. Your friend gives you a set of directions which contain a large number of turns, detours, and getting on/off expressways. You Google maps the location of his house to double check its location and realize that itâs just 2 miles straight up a single road with no traffic lights or stop signs. Google maps directions estimate it will take you 15 minutes to get there whereas if you had followed your friends directions it would have taken 3 hours.
In the above analogy:
- Directions -> shader code
- Google maps -> the D3D11/D3D12 HLSL compiler
Youâll notice thereâs no entry for Vulkan. Thatâs because Vulkan just takes the 3 hour long directions as-is unless you first translate them into Klingon, find and use a Klingon Google maps to figure out itâs actually a straight line, and then translate the new directions back into English.
10 Likes
/QAPLApalm
3 Likes
I see⌠i wonder what would it take if bigger studios just got some funds together and crowdourced this compiler âŚthen licence it âŚhmmm.
Hope some of em read this⌠
It looks like the poor performance on Vulkan was mainly caused by the Steam Overlay. Here is a recent benchmark with latest drivers + updated Steam + latest TTP release on Linux and a 980 Ti.
4 Likes
Just spotted this.
1 Like
Nice! I think significant improvements are most likely to come from Google given its importance to Android.
1 Like
4 Likes
The summary of the video is that uncapped* frame rates on Doom with a Vulcan 1080 run around 120, but as high as 150.
*capping frame rates is done so that the game only generates one display frame for each monitor refresh, avoiding wasting GPU processing (power, heat, etc). Ideally, non-display tasks run at a separate rate.
Why wouldnât I be able to buy good component for my Linux box?
Seems to be interesting, indeed. With this, choosing Vulkan over DirectX12 shouldnât be a problem.
This article by a uni developer who is using both DX12 and Vulkan might be a good read for you guys.
3 Likes
GLFW 3.2 added Vulkan support : http://www.glfw.org/changelog.html
GLFW is similar to SDL, but focus on GL applications. And it is multiplatform, of course.
1 Like
Vulkanâs glslang compiler has started adding [support for HLSL] (https://github.com/KhronosGroup/glslang/commit/21472aee755d4a6d234488ecc606ffe2ace4673b) which is a very exciting development.
6 Likes
I hope HLSL isnât Windows only.
HLSL is just a programming language, if itâs compiled to SPIR-V it works on any platform that supports Vulkan.