101–110 of 163 posts
That's evolution. New graphics APIs are intended for engine developers, not for application programming. Application should use higher level engines, not low level APIs.
"Former Nvidia dev" - s/he did an internship there. Maybe too weighty a HN title.
I'd agree, but they certainly know what they're talking about so I don't really mind. They obviously did some form of software development at Nvidia if only as an intern.
Earlier quoted context omitted.
This might hold true if you're only looking at the actual design/code side of the lifecycle, but it sounds like a key point of the new APIs is to make new projects more testable, debuggable and optimizable. Given most project spend inordinate amounts of time in the those three activities (and it sounds like games moreso), this should be a win for everyone.
And even if it isn't, the video game industry just got revolutionized by most of the major engines becoming free, so indie devs don't have to drop down to a lower level of abstraction in order to have a chance at competitive performance.
Earlier quoted context omitted.
Hi, I'm working on a library to allow something like this (rendering web UI's with a WebGL backend). It's in very early stages. Feedback is very welcome: https://github.com/davedx/lustro
Good luck. Efficient 2D using OpenGL is very difficult. It will never approach the speed of a well designed 2D API. Microsoft gave a lot of insight about the hard it was to get Direct2D to be competitive with GDI/GDI+. If you do see any performance benefits it likely will be because you support less features than what a modern day browser supports with HTML/CSS. But in my opinion you could probably achieve faster spe…
It depends on what you are doing. Rendering thousands of sprites with independent rotation and scale is easy. Rendering text is a lot of work, but once you do it you can do all sorts of things with the text. Rendering simple things like bezier curves is very difficult. There are some things in the 2D world that HTML/CSS/GDI/GDI+ are very bad at, compared to OpenGL, and vice versa.
Very interesting post. So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold. This begs the question: what about DirectX 12 and Apple's…
>I wonder if/when web developers will reach a similar point of software layer implosion. "Easy to code against, but a bitch and a half to debug or tune" for me it was 3 years ago in web. And 6 years ago in Enterprise java.
I still love JS, and coding for the web. But I don't use frameworks now.
Performance gains are worth any trouble IMO, here is why: While at GDC I saw a DirectX 12 API demo (DX12 is more/less equivalent to Vulkan from an end-goal perspective). On a single GTX 980: DX11 was doing ~1.5 million drawcalls per second. DX12 was doing ~15 million drawcalls per second. This API demo will ship to customers, so I am pretty sure we can easily verify if these are bunk figures. But a potential 10x spee…
That's great, and for project like yours (Voxel Quest), it'll definitely help. I'm wondering though, if the demo also uses the CPU for other things - physics, audio, collision, path-finding or some other form of ai, state machines, game script, game logic. My point is that 10x might be possible (on a 10 core cpu) if the cpu's are only used for graphics, but there are other things that come into play... But even then,…
Its possible that these perf gains are actually working in a single thread, and the gains are from eliminating the default driver overhead that would be in these drawcalls. To some extent this could be mitigated by batching but it is still ideal to have the option to do far more drawcalls in a frame.
> What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. So true and yet, we have all those crazy JavaScript frameworks trying to abstract everything away from developers. There's a lesson in there.
You cannot abstract away complexity. This is a lesson people relearn every 2-3 years or so. From the javascript frameworks - I use only backbone and jquery - first as a simple router, second for easy dom traversal.
Earlier quoted context omitted.
Having shipped multiple PC games with separate D3D/GL backends, and one game with GL only, a contributing factor here is that OpenGL (at least on Windows) still totally sucks. To be fair, driver vendors have gotten a lot better. And the spec itself has matured tremendously, with some great features that don't even have direct equivalents in Direct3D. Sadly as a whole the API still sucks, especially if you care about…
If Vulkan solves some of these problems, does it seem likely to you that the tooling and community could grow up around it and shift the momentum?
Very interesting post. So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold. This begs the question: what about DirectX 12 and Apple's…
Whether or not the Extensible Web Manifesto is successful or not remains to be seen.
The idea that nVidia and AMD are detecting your games, and then replacing shaders, optimizing around bugs, etc should be absolutely terrifying. And vice versa, the idea of having to fix every major game's incredibly broken code is equally terrifying. And it's a huge hit to all of us indie devs, who don't get the five-star treatment to maximize performance of our games. So overall, I'd say this is a step in the right…