Client rewrite β-testing

[loftar]

Is there a quick and dirty way to get this error out of the way, so that I could check if there are any new errors occuring?

Unless you can find a way to enable compatibility profiles in OSX, I can't think of any such quick-and-dirty way, unfortunately.

[boshaw]

Just curious is the concept of gobs being static or not gone now or is it done in a different way? I noticed staticp() is commented for the time being and gobs in MapView are handled differently than before. Will it all come back?

[loftar]

Just curious is the concept of gobs being static or not gone now or is it done in a different way? I noticed staticp() is commented for the time being and gobs in MapView are handled differently than before. Will it all come back?

It is gone, I just haven't gone through and removed all of those sections yet.

[boshaw]

Just curious is the concept of gobs being static or not gone now or is it done in a different way? I noticed staticp() is commented for the time being and gobs in MapView are handled differently than before. Will it all come back?

It is gone, I just haven't gone through and removed all of those sections yet.

Interesting. I had used it in the past to get good fps around like lots dead animals and others, but it seems the trick is just to use ":par on" as without it I do find myself at ~30 fps in areas of lots of dead animals for example. With it on i find myself never going below 60 really.

[loftar]

Interesting. I had used it in the past to get good fps around like lots dead animals and others, but it seems the trick is just to use ":par on" as without it I do find myself at ~30 fps in areas of lots of dead animals for example. With it on i find myself never going below 60 really.

To be sure, :par should be switched to be on by default. As I mentioned previously, the only reason I haven't is because I've sometimes seen it play tricky with the GC, where it has seemed like it has significantly increased the frequency of major collections, which is a real nuisance, and if that is so, then there is an argument that those who need it should have to turn it on, rather than those who don't need it suffering from the consequences, so to speak. I'd be happy if y'all could report your findings about that. (I also suspect that the GC issue should be mostly solved on versions of Java that default to the G1 collector.)

[loftar]

So I've been debugging the MacOS issue with the ubersheva's help (thanks, I couldn't have done it without you), and what I've found merits some public feedback, I reckon.

The TL;DR first: The OpenGL implementation on MacOS forces me into one of three choices:

• 1) Dropping support for MacOS completely
• 2) Dropping support for OpenGL 2.0 completely, and instead requiring support for OpenGL 3.0
• 3) Spending more than a trivial amount of work and complexity (that also needs to be maintained) in order to support OpenGL 2.0 and 3.0 separately

While I'm sure there are many who would enthusiastically argue for option 1, I'd obviously like to avoid that if at all possible. I'm leaning towards option 2, both because it's less work, but also for technical reasons. Option 3 is available; it's not like supporting both 2.0 and 3.0 is weeks and months of work, but unless it's necessary I'd rather avoid both the work, and the resulting ugliness.

And that is the main reason for posting this: Are there any among you who require support for OpenGL 2.0? I do notice a few error reports now and then trickling in from OpenGL 2.0 users, but it's hard for me to determine how important this is for you. (Like, is it just to try the client out on an old PC just for the fun of it, or are you actually playing the game like that and would be totally locked out without it?) I realize of course that not everyone will see this, and perhaps those that need support for OpenGL 2.0 don't even know how to find out, but I can't think of anything better than to ask. For those of you who see this post, please pass it on to anyone else you know in-game who might be affected!

As for the technical details: It turns out that MacOS effectively has two separate OpenGL implementations: one that supports OpenGL 2.0 strictly and not a single feature that comes after it, and another that supports OpenGL 3.0 strictly with not one ounce of backwards compatibility, whereas most (all?) other implementations support a compatibility profile which includes the functionality from both. The client requires support for VAOs, which MacOS's 2.0 implementation does not support, but it also uses GLSL 1.20 in order to be compatible with pre-3.0 implementations, and MacOS's 3.0 implementation only supports GLSL >= 1.40 (which is all that the OpenGL 3.0 standard mandates). The difference compared to the standard client is that it actually still supports non-VAO rendering (even though VAOs are in fact supported even by far older OpenGL implementations than 3.0, but Apple nonetheless decided to not support it for whatever reason), but that is for pure legacy reasons and very definitely not something that I'm bringing back.

Arguing from pure principles, dropping OpenGL 2.0 support would be the nicest, as that would allow the client to only require an OpenGL core profile rather than an ugly compatibility profile, even though it doesn't really even require any compatibility functionality. There are several different reasons why supporting OpenGL 2.0 and 3.0 separately is a bit complex. It's not just about only using functionality in the intersection of both of those, but there are other things that simply work differently between the two; for instance, sampling depth textures returns data in the z component in OpenGL 2.0 and compatibility profiles, whereas in core profiles, it returns data in the r component, and switching between these subtle differences depending on version not only feels quite unnecessary, but is also pretty error-prone since I won't even detect if I'm doing something wrong unless I do all testing separately on both versions.

[shubla]

So I've been debugging the MacOS issue with the ubersheva's help (thanks, I couldn't have done it without you), and what I've found merits some public feedback, I reckon.

The TL;DR first: The OpenGL implementation on MacOS forces me into one of three choices:

• 1) Dropping support for MacOS completely
• 2) Dropping support for OpenGL 2.0 completely, and instead requiring support for OpenGL 3.0
• 3) Spending more than a trivial amount of work and complexity (that also needs to be maintained) in order to support OpenGL 2.0 and 3.0 separately

While I'm sure there are many who would enthusiastically argue for option 1, I'd obviously like to avoid that if at all possible. I'm leaning towards option 2, both because it's less work, but also for technical reasons. Option 3 is available; it's not like supporting both 2.0 and 3.0 is weeks and months of work, but unless it's necessary I'd rather avoid both the work, and the resulting ugliness.

And that is the main reason for posting this: Are there any among you who require support for OpenGL 2.0? I do notice a few error reports now and then trickling in from OpenGL 2.0 users, but it's hard for me to determine how important this is for you. (Like, is it just to try the client out on an old PC just for the fun of it, or are you actually playing the game like that and would be totally locked out without it?) I realize of course that not everyone will see this, and perhaps those that need support for OpenGL 2.0 don't even know how to find out, but I can't think of anything better than to ask. For those of you who see this post, please pass it on to anyone else you know in-game who might be affected!

As for the technical details: It turns out that MacOS effectively has two separate OpenGL implementations: one that supports OpenGL 2.0 strictly and not a single feature that comes after it, and another that supports OpenGL 3.0 strictly with not one ounce of backwards compatibility, whereas most (all?) other implementations support a compatibility profile which includes the functionality from both. The client requires support for VAOs, which MacOS's 2.0 implementation does not support, but it also uses GLSL 1.20 in order to be compatible with pre-3.0 implementations, and MacOS's 3.0 implementation only supports GLSL >= 1.40 (which is all that the OpenGL 3.0 standard mandates). The difference compared to the standard client is that it actually still supports non-VAO rendering (even though VAOs are in fact supported even by far older OpenGL implementations than 3.0, but Apple nonetheless decided to not support it for whatever reason), but that is for pure legacy reasons and very definitely not something that I'm bringing back.

Arguing from pure principles, dropping OpenGL 2.0 support would be the nicest, as that would allow the client to only require an OpenGL core profile rather than an ugly compatibility profile, even though it doesn't really even require any compatibility functionality. There are several different reasons why supporting OpenGL 2.0 and 3.0 separately is a bit complex. It's not just about only using functionality in the intersection of both of those, but there are other things that simply work differently between the two; for instance, sampling depth textures returns data in the z component in OpenGL 2.0 and compatibility profiles, whereas in core profiles, it returns data in the r component, and switching between these subtle differences depending on version not only feels quite unnecessary, but is also pretty error-prone since I won't even detect if I'm doing something wrong unless I do all testing separately on both versions.

Option 2.
Could you do some gathering about what version of opengl people's computers support?
I think it's safe to assume at least 4.0 and maybe 4.5-

[loftar]

Could you do some gathering about what version of opengl people's computers support?

I thought about that, but I'm not sure. To begin with, I'm not too keen on doing silent data collection (the error reports that the client sends are already on the outer edge of my comfort zone), but I'm also not sure how useful any data would be. For instance, as I said, Mac OS defaults to 2.0 by default, so that's all I'd see there (since I'm certainly not rewriting the current client to do 3.0 support), and it also wouldn't tell me if non-MacOS users of 2.0 really need it (like I said, I already see from error reports that there do in fact exist 2.0 users), or how important it is for them. I'd also have to depend on custom client makers to merge said collection tools. And so on.

Fun fact: I've even seen error reports from someone "running" the client on something as odd as a PowerVR SGX545 (from 2019, no less!). I can only assume that's some kind of oddball testing rather than actual playing.

I think it's safe to assume at least 4.0 and maybe 4.5-

I'm sure that's true for the vast majority, but it would still be a bit dickish of me to drop support for a minority who currently play and enjoy the game, unless that minority is absolutely super-tiny as long as I at all have the ability to support them.

[MagicManICT]

To begin with, I'm not too keen on doing silent data collection (the error reports that the client sends are already on the outer edge of my comfort zone), but I'm also not sure how useful any data would be.

Primarily, you only want to know what GPU model, driver version, and OpenGL support it has. I think it would be reasonable to post up a utility that users can voluntarily download and run.

When it comes to Macs, don't be surprised if this problem is encountered again in just a few years (before 2025 for sure) and OGL 3.x is no longer well supported. It's the way Apple runs.

As for global stats, I'd say cross-reference Steam's hardware survey information for OpenGL 2.x hardware vs 3.x. I looked and didn't see OGL specific stats listed through Steam launcher, but specific graphics devices are listed. Since the OGL 3.x standard was released during the DX10 period, you can work with a relatively small number of devices that would still be OGL 2.x, but not 3.x, compatible. I don't know of any other comprehensive surveys of hardware out there.

[borka]

Fun fact: I've even seen error reports from someone "running" the client on something as odd as a PowerVR SGX545 (from 2019, no less!). I can only assume that's some kind of oddball testing rather than actual playing.

Which in fact is (identical to) Intel GMA 3650 of the Atom N2600, N2800, D2550 und D2700 CPU Series:
Left 4 Dead (2008) 640x480 with 14 fps