OpenGL or DirectX for 64k PC
category: code [glöplog]
mudlord: Right. Then I guess it's an easy choice to set the mental troll-bit on you. Good bye.
Quote:
Quote:Not investing time in dying technology
OpenGL is dying since more than 20 years now.
If it keeps dying for another 20 years, it's probably not much of a problem to care about...
the scene has already been dying for longer than that anyway
Quote:
OpenGL is dying since more than 20 years now.
If it keeps dying for another 20 years, it's probably not much of a problem to care about...
Excellent point. Furthermore, there is a high chance that some of the new features of dx12/vk (and even raytracing) might be made vailable via GL extensions sooner or later by the GPU vendors anyway.
Case in point: See all the bindless / "approaching zero driver overhead" (AZDO) extensions by nvidia/ati which gives you a lot of the new low-level stuff.
maybe a vulkan based framework/skeleton-code people can use would make it more convenient to use for many.
somebody call nehe
isn't a boilerplate/framework exactly besides the point of using Vulkan? Then you can just stick to any other existing API if building your own low-level framework from the ground up to maximise performance towards the implementation of your ideal demo engine is not your cuppa
Quote:
maybe a vulkan based framework/skeleton-code people can use would make it more convenient to use for many.
I believe there's a promising one called Zink :D
Zink looks nice.
use whatever you feel comfortable with. for what it's worth: opengl is the ONLY cross platform standard we have offering a decent amount of backwards compatibility, so i sincerely hope it's gonna be there for quite a while into the future, purely due to pragmatic "software industry" reasons. for demos/intros: use what ever the fuck feels comfortable.
^^^^^^^^
OpenGL hasn't been dying for 20 years, that's just plain wrong. For the last 20 years, there's been 16 new versions of the OpenGL specification released. But for the last six years, there's been one version released, which was mostly about interoperability with Vulkan. And there's no talks about OpenGL 4.7 or 5.0.
It's right now that OpenGL is dying. What's there isn't going to go away anytime soon, we're trying to make sure of that with projects like the Zink and D3D12 Mesa drivers. But do not your OpenGL applications to be super-performant of power-efficient, because most platforms are moving towards emulation.
jco: If people have OpenGL based engines, sure, they'll be good for a few more years, as long as they are comfortable sticking with the current feature-set. But new features aren't arriving, apart from as vendor-specific extensions. And starting new projects based on OpenGL isn't a very good idea, at least if those projects are expected to last for more than a blink of an eye. This is the time to start to get comfortable with something else if you want to stay in graphics development.
It's right now that OpenGL is dying. What's there isn't going to go away anytime soon, we're trying to make sure of that with projects like the Zink and D3D12 Mesa drivers. But do not your OpenGL applications to be super-performant of power-efficient, because most platforms are moving towards emulation.
jco: If people have OpenGL based engines, sure, they'll be good for a few more years, as long as they are comfortable sticking with the current feature-set. But new features aren't arriving, apart from as vendor-specific extensions. And starting new projects based on OpenGL isn't a very good idea, at least if those projects are expected to last for more than a blink of an eye. This is the time to start to get comfortable with something else if you want to stay in graphics development.
That's the thing: I'm not in graphics development, I just make demos.
That may sound flippant to you - and I know we've discussed tangential things like this in person last year - but I'm not a highend graphics programmer, I don't do that for a living, and I don't have the know-how on the theoretical level to be one either. To be "forced" (for the lack of a better word) do that as a hobby would probably ruin it for me, because the amount of catch-up to do in my spare time would be crazy.
Will that affect the way my demos look? Of course, it always has, but I'm at peace with that, to me that's become a means to an end.
Personally my bigger concern is that there's about ~5 people in the scene who can do higher-than-mid-tier 3D, so no matter how fancy your engine is, if there's no art to drive it, it's gonna dull the edge. But that's just me.
That may sound flippant to you - and I know we've discussed tangential things like this in person last year - but I'm not a highend graphics programmer, I don't do that for a living, and I don't have the know-how on the theoretical level to be one either. To be "forced" (for the lack of a better word) do that as a hobby would probably ruin it for me, because the amount of catch-up to do in my spare time would be crazy.
Will that affect the way my demos look? Of course, it always has, but I'm at peace with that, to me that's become a means to an end.
Personally my bigger concern is that there's about ~5 people in the scene who can do higher-than-mid-tier 3D, so no matter how fancy your engine is, if there's no art to drive it, it's gonna dull the edge. But that's just me.
well said.
Gargaj: Yeah, sure. If you don't want to do low-level graphics coding, then that's fine. But this thread is a very strange place to make that complaint; this is a thread about graphics APIs.
The thing is, a lot of people seem to think "Vulkan and D3D12 is too hard". But that's not quite true. It's harder to get started with, because you need to adapt to new paradigms. But these APIs are actually easier to build somewhat complicated stuff with, because the API better reflects what the hardware can do, so you don't need to go through a series of guessing-games to figure out what's going to work (I'm looking at you, GL_UNSUPPORTED_FRAMEBUFFER). OpenGL isn't as easy as people are trying to make it. It's clunky and archaic, and it takes quite a lot of code to get things right. It's easy to spin an RGB-triangle, or draw a fragment-shaded quad, but that's about it.
Maybe you don't want to build complicated stuff, so explicit APIs doesn't sound like a good value-proposition to you. But if so, that's going to become a problem for you going forward, because nobody is building the world for making it easy to make 64k intros. The direction things are being pushed is towards low-level and use middle-ware. There's a fair chance that Windows will no longer ship OpenGL32.DLL by default in the not-too-distant future, for instance. Similar thing on other platforms.
If we want to keep making it easy to build intros, we're the ones that needs to make that happen. And that isn't going to happen by itself, we need to build those tools ourselves.
The thing is, a lot of people seem to think "Vulkan and D3D12 is too hard". But that's not quite true. It's harder to get started with, because you need to adapt to new paradigms. But these APIs are actually easier to build somewhat complicated stuff with, because the API better reflects what the hardware can do, so you don't need to go through a series of guessing-games to figure out what's going to work (I'm looking at you, GL_UNSUPPORTED_FRAMEBUFFER). OpenGL isn't as easy as people are trying to make it. It's clunky and archaic, and it takes quite a lot of code to get things right. It's easy to spin an RGB-triangle, or draw a fragment-shaded quad, but that's about it.
Maybe you don't want to build complicated stuff, so explicit APIs doesn't sound like a good value-proposition to you. But if so, that's going to become a problem for you going forward, because nobody is building the world for making it easy to make 64k intros. The direction things are being pushed is towards low-level and use middle-ware. There's a fair chance that Windows will no longer ship OpenGL32.DLL by default in the not-too-distant future, for instance. Similar thing on other platforms.
If we want to keep making it easy to build intros, we're the ones that needs to make that happen. And that isn't going to happen by itself, we need to build those tools ourselves.
Quote:
OpenGL hasn't been dying for 20 years, that's just plain wrong.
I was jokingly refering to Microsoft's regular announcements to drop all OpenGL support with basically every new version of Windows.
Right, but people took it seriously ;)
Quote:
The direction things are being pushed is towards low-level and use middle-ware.
that's another concern actually: that api-level graphics knowledge is dying out because so much graphics is built in middleware nowadays. it's become far more niche to roll your own.
Kusma, you make some very valid points. And I agree with you that in the long run vulkan et al. are the way to go. At the moment we‘re at the beginning of a transition phase to a major change how rendering code is written.
We had similar phases before: SW rendering vs. first 3d cards, then fixed-function hw-tnl, then shaders, then compute, etc.
You are most likely right when saying that the new APIs will be what everybody is using in like 5 years.
However, I personally would just like to post-pone rewriting my own rendering stuff as long as I can. Once finally there is some more usable tutorials and sample code out there and people have uncovered some best practices how to cut down on complexity, I‘m happy to dive in.
Sounds selfish and lazy, but I‘m not 20 anymore :)
(and I still have bad memories about the dx3 execute buffer era)
We had similar phases before: SW rendering vs. first 3d cards, then fixed-function hw-tnl, then shaders, then compute, etc.
You are most likely right when saying that the new APIs will be what everybody is using in like 5 years.
However, I personally would just like to post-pone rewriting my own rendering stuff as long as I can. Once finally there is some more usable tutorials and sample code out there and people have uncovered some best practices how to cut down on complexity, I‘m happy to dive in.
Sounds selfish and lazy, but I‘m not 20 anymore :)
(and I still have bad memories about the dx3 execute buffer era)
Quote:
We had similar phases before: SW rendering vs. first 3d cards, then fixed-function hw-tnl, then shaders, then compute, etc.
The scene was slow/unwilling to transition back then as well, so it will probably work out just fine eventually.
Quote:
The scene was slow/unwilling to transition back then as well, so it will probably work out just fine eventually.
I think in 2015+ we forced by corporations to move
GLES3 are perfect for minimal code size+minimal binnary(exe) size, it crossplatform and work for many years
in 2019-20 corporations just say "we no longer support GLES3" that all
what we can do
nothing
What about those APIs built on Vulkan?
Are they a problem. Take for instance something like bgfx, which does support DX12 and Vulkan? Are they a problem?
Are they a problem. Take for instance something like bgfx, which does support DX12 and Vulkan? Are they a problem?
Quote:
What about those APIs built on Vulkan?
Are they a problem. Take for instance something like bgfx
then I vote for or Godot, or UE4, its also opensource and support many graphic api
for real - best option and most realistic is WebGl, or WebGPU API, that will work everywhere include mobiles, and can be coded anywhere
but... Web-browser as mega-framework exist for very long time 10+years for sure, and no one want use it as "demoscene platform for everything"...so...
by the time WebGPU finally gets its first browser implementation, the demoscene is dead apart from kusma and 3 other Vulkan enthusiasts
Bruno Valero lul I expect Corona joke, anyway nice one xD
spike: I wasn't trying to suggest people throw away their perfectly working engines, just saying that I wouldn't start new projects using OpenGL. There's nothing wrong with working code; I used my old DX9 engine for a good 11 years myself.