Jump to content

Recommended Posts

1 hour ago, WhiteTreePaladin said:

There is a point where cards that don't support more recent standards won't have enough power to run the game well anyway. I don't know what that level is, but I somewhat doubt we need to support less than OpenGL 3. OpenGL 4 would be debatable, but 8 years is a still a long time.

Thinking about openGL in terms of version numbers isn't really useful. People seem to have this idea that higher numbers are better, but that's not how openGL works. Really we should be using the lowest version number that has features that are highly useful to improving the performance and/or appearance of the game. Using a version higher than that doesn't actually do anything besides preventing people with older cards (like me) from playing. That said, I think 3.3 is a good idea, and there are some major performance and quality enhancements that could be had by upgrading. However there's also GLES to consider which I'm not actually certain about. We should really look into the consequences before making any major changes like that.

Honestly we keep going around in circles with this. It'd be good to make a decision sooner rather than later. Technically only model and particle drawing would need to be changed, I'm pretty sure. Upgrading to openGL3 doesn't mean that every shader would need to change, only the ones that would need to handle instancing and depth readback for soft particles would need to be updated. That and the model drawing code would need to be updated to use real instancing. It's less of the engine than you might imagine (although if we decided to throw out arb or ffp that'd be a lot of cleanup).

10 hours ago, vladislavbelov said:

I meant to calculate a end pixel shadow color with different number of probes that depends on the alpha value. It's not exactly what did you say about, but just a near idea. Because for more transparent pixels we can have a lower quality of shadow, because it's less visible.

Hmm. That could actually be done. It's certainly worth testing though.

  • Like 3

Share this post


Link to post
Share on other sites
4 hours ago, aeonios said:

Thinking about openGL in terms of version numbers isn't really useful. People seem to have this idea that higher numbers are better, but that's not how openGL works. Really we should be using the lowest version number that has features that are highly useful to improving the performance and/or appearance of the game. Using a version higher than that doesn't actually do anything besides preventing people with older cards (like me) from playing. That said, I think 3.3 is a good idea, and there are some major performance and quality enhancements that could be had by upgrading. However there's also GLES to consider which I'm not actually certain about. We should really look into the consequences before making any major changes like that.

Honestly we keep going around in circles with this. It'd be good to make a decision sooner rather than later. Technically only model and particle drawing would need to be changed, I'm pretty sure. Upgrading to openGL3 doesn't mean that every shader would need to change, only the ones that would need to handle instancing and depth readback for soft particles would need to be updated. That and the model drawing code would need to be updated to use real instancing. It's less of the engine than you might imagine (although if we decided to throw out arb or ffp that'd be a lot of cleanup).

Hmm. That could actually be done. It's certainly worth testing though.

Would it be possible to use opengl 3.3 features only when the graphics card supports it? So that too old cards can still run the game, but won't profit from 3.3 features?

Share this post


Link to post
Share on other sites
39 minutes ago, Imarok said:

Would it be possible to use opengl 3.3 features only when the graphics card supports it? So that too old cards can still run the game, but won't profit from 3.3 features?

Possible? Certainly. However currently the engine only supports picking between GLSL, arb, and fixed-function modes and doesn't actually check gl version and probably doesn't support picking between different shader versions based on what the hardware is capable of. That would need to be added.

I think a reasonable compromise would be to drop arb and ffp support (it's not like anyone actually does any work on arb/ffp anymore anyway) and replace it with support for choosing between GL2 and GL3, with support for using GL4 in the future if we ever find a definitive use for GL4 features. If we have it choose the highest shader version supported it'd give us a lot of flexibility in terms of upgrading things incrementally.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, stanislas69 said:

Can't we rely on glew library to make the switch when GLSL is enabled ?

I don't think so. It's the engine and not glew that loads and manages the shaders. That means we need to change the shader management code to be version aware. glew can't turn a drawinstanced call into regular draw calls, either. The engine needs to know which one to use.

EDIT: Also back to the main topic, I tried reducing the number of samples based on tex alpha for transparent objects, but the improvement was only marginal. Still far below playable for gold oasis.

Edited by aeonios

Share this post


Link to post
Share on other sites

3 years old stats about OpenGL versions here: http://feedback.wildfiregames.com/report/opengl/feature/GL_VERSION

Only about 4% users with OpenGL < 2, surely a lot less by now (and likely with the game lagging or even unplayable anyway).

As discussed elsewhere recently, dropping OpenGL < 2 was anyway already approved 6 years ago, just never done (probably due to myconid developer disappearing):

So, if you are motivated, you are free to propose something. :)

Also somewhat related: https://trac.wildfiregames.com/wiki/GraphicsFeatureStatus

About OpenGL 4, you may even consider Vulkan as an alternative with similar card support, no idea how it's worth however.

  • Like 2

Share this post


Link to post
Share on other sites

I think going far forward we should probably try to find a library abstracting over vulkan, metal, and other low-level stuff, and use that. Apple seems determined to never support OpenGL correctly, sadly.

Share this post


Link to post
Share on other sites
13 minutes ago, wraitii said:

I think going far forward we should probably try to find a library abstracting over vulkan, metal, and other low-level stuff, and use that. Apple seems determined to never support OpenGL correctly, sadly.

I don't think there is such a thing, and apple seems dead set on never supporting anything correctly (including the technologies they themselves vetted, like openGL). Linux even supports D3D through MESA, although I don't actually know how to make that work. If we wanted to upgrade our media library I'd suggest the Small Fast Media Library. Apparently it compiles properly on all platforms and is better than SDL or even GLFW in terms of features and usability.

Share this post


Link to post
Share on other sites
9 hours ago, aeonios said:

doesn't actually check gl version and probably doesn't support picking between different shader versions based on what the hardware is capable of.

It's not actually true, engine checks versions, but doesn't use it widely. I.e. we use VBO (AFAIK FBO too) only if it's supported as extensions. Also shaders uses "requires" and fallbacks, so it's pretty easy to add switching between real versions of GL for shaders. But the engine needs improvements for it.

1 hour ago, aeonios said:

I don't think there is such a thing, and apple seems dead set on never supporting anything correctly

It exists, and it's called ANGLE, i.e. it's used in Chrome. But it's pretty limited as all universal instruments.

Share this post


Link to post
Share on other sites
33 minutes ago, vladislavbelov said:

It's not actually true, engine checks versions, but doesn't use it widely. I.e. we use VBO (AFAIK FBO too) only if it's supported as extensions. Also shaders uses "requires" and fallbacks, so it's pretty easy to add switching between real versions of GL for shaders. But the engine needs improvements for it.

Hmm.. the requires for shader techniques don't work quite the way we'd need them to. Those aren't "minimum version" requires, they're "selected this mode" sort of requires. Materials have fallbacks but shader techniques don't. We need a clear means for specifying that.

Share this post


Link to post
Share on other sites
7 minutes ago, aeonios said:

Hmm.. the requires for shader techniques don't work quite the way we'd need them to.

But it's easy to add as I said.

8 minutes ago, aeonios said:

Materials have fallbacks but shader techniques don't.

True, and materials use shaders, so we can add additional requirements here. Why not only shaders? Example (abstract), a shader uses the texture reading in the vertex shader from the material texture. But if it's not supported this texture isn't needed. So we don't need to load this texture. Shaders don't manage this kind of flow, but materials do.

Share this post


Link to post
Share on other sites
4 hours ago, aeonios said:

I'd suggest the Small Fast Media Library. Apparently it compiles properly on all platforms and is better than SDL or even GLFW in terms of features and usability.

It won't be easy to change the core lib. Also do you have strong arguments, why SFML is better? I had used it only few times, so I found some posts (SFML vs SDL):

People prefer SDL for rendering and low level things, that needed for us by obvious reasons.

Share this post


Link to post
Share on other sites
On 5/5/2018 at 5:36 PM, wraitii said:

I think going far forward we should probably try to find a library abstracting over vulkan, metal, and other low-level stuff, and use that. Apple seems determined to never support OpenGL correctly, sadly.

Such as https://www.khronos.org/blog/khronos-announces-the-vulkan-portability-initiative, which does have an active GitHub https://github.com/gfx-rs/portability, though obviously it's not finished. Haven't dug much beyond that.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×