Adam Reece

Thanks for the resolution.

This appears to be resolved for me. No longer getting any lag when chat messages are sent (by anyone, including me) after a period of not getting any. (I'd migrated to a Microsoft account too.)

[Edit] I run version 1.18.1.

Nah, it happens with Wurm too (Java based) – both their online MMO and Unlimited releases.

We also had this issue at Sven Co-op, which uses Firelight's FMODEX for sound. Turns out we had to implement a listener for a "device change" event, then completely re-initialise the sound output.

It's almost always games it happens with though, as it takes additional effort to reset sound engines at the middle of runtime. Other applications get around the problem because they just offload their sound output to a built-in provider from the OS, like DirectSound, which handles these events for the app at a lower level. That makes it kinda on the fence as to whether its a genuine bug or feature request, because a specific implementation has to be worked out to resolve this.

(Not saying I don't want it resolved though. 🙂)

I agree but apparently this works as intended.

I can't say how thunder would sound underground as I've never been deep underground while a thunderstorm is roaring on the surface. (Perhaps a current/former mining industry professional could share their experience of this, if they have it.) I would definitely expect the sound to be attenuated strongly though. All the high pitch frequencies would not likely travel through the thick rock leaving just the deep bassy notes perhaps highly reverberated according to the size and shape of the cavity you're in.

That's all likely too realistic for Minecraft anyway. Some basic attenuation functionality of all sounds based on blocks between you and the sound source should be a given no matter if you're surface or subterranean though.

This issue is actually more complicated in that it really applies to ANY sound produced in Minecraft. This is because all the sound you hear is radius based, meaning no matter what is between you and the origin of the sound (be it air or 3 metre thick iron) you will hear the sound exactly the same because you're in the correct radius. It's only more noticeable for thunder because of the high radius it has. This same issue could also apply to for example hearing hostile mobs in caves very clearly, even though there could be a metre or two of solid rock between you both. There is no form of attenuation other than distance amplitude loss.

While reducing the radius could fix this I don't believe this would be a ideal. Partly because thunder is ruddy loud and can be heard for miles in our reality (so if anything the radius should be increased), but also because if I'm at Y10 (or lower) I should be able to hear thunder if there is a clear shaft to the sky where the sound would easily reach me without obstructions.

Sound audibility should ideally be dependant on what lies between you and the origin of the sound rather than radius and amplitude alone. I've noticed some modern games, particularly those using FMOD (which Minecraft does not), do account for obstructions when calculating sound attenuation pretty well. Perhaps a feature for a future major release.

Edit: What could also go really well with such a major sound update is distance based delay. For example, sound travels at ~343 metres/second. If a lightning strike is 343 metres away then you should see the visual effect immediately but not hear it for a whole second. Probably not that difficult to calculate this in Minecraft considering each cube seems to be roughly 1 cubic metre anyway. (FYI this is a little tip on knowing how far away a storm could be IRL.) Minecraft of course was never designed with realistic physics in mind. 🙂

I think it was a mod doing it (Optifine), or perhaps all the version switching I do. Just started up and it's on my desired +50%.

Ah I forgot about the brightness setting. For some reason mine keeps putting itself on +100% (even though I don't want it there).

Added 5 screenshots in snapshot 14w30c. I've only tested this on single-player, but as for a long time now single-player uses the same code base and such as multi-player (of which the issue originated at including crossing over to single-player later), this should be sufficient.

The first two show a visual scene difference between just rain and a thunderstorm. The main point is the sky scene DOES correctly switch to thunderstorm, of which is the primary way to recognize a thunderstorm against just some rain. Though the land scene doesn't appear to get much darker, it does just a little.

The next three show a technical representation of the ambient light level through all 3 weather conditions, up to light level 15. These clearly show the light level correctly drop from 15 to 12 and 10 for just rain and a thunderstorm respectively. These are also taken at exactly noon.

In my opinion a slightly lower light level (perhaps 8) would be more suited to the wide difference visible in the sky. The land doesn't really appear to get as dark as the sky, which doesn't look brilliant (the land glowing a bit?). However from an issue perspective, this is resolved.

I guess this can be marked as resolved then. 🙂

With that many entities there is a good chance your CPU is too busy to give enough attention to the code that delivers stuff to the GPU, which would mean your GPU is idle whilst waiting for this data to arrive. Remember that all those entities have to be processed with physics, A.I., and stuff like that ... every frame. This will ramp up the CPU time consumption, particularly as it's all run on one thread.

I'd definitely try again with none or nearly no entities to confirm (or de-confirm) this is a rendering bug. I'd suspect it isn't though. You could use something like SysInternals Process Explorer to monitor the consumption of CPU and GPU time to further verify this. (providing you're running Windows)

Oh, and update your Java 😉 Apparently 1.8 isn't supported, but certainly get the latest build of Java 1.7.

Did you try in 14w30c? A bunch of the new rendering glitches got repaired.

Confirming as fixed in 14w30c.

Odd.. this appears to be fixed entirely for me in 14w30c.

If this is FOV related then this will be a duplicate of MC-63020.

That happens because you're in very shallow water, and is intended. Try again in something deeper.

Added two screenshots of my view at the bottom of a deep ocean, one with night vision.

Bad issue description, not enough detail. Please include your GPU brand, model, and drivers.
Also worth updating your very out of date Java 1.7_25. Version 1.8_11 is out now.

That just looks like chunks haven't finished being created in a brand new world. Give it a minute and it'll be fine. (your lack of description doesn't help us know if this world is new or not)

Looks like MC-63070 covers this issue when caused by 3rd person and high FOV's (higher FOV = more likely). Likely that the two issues are related.

I use FOV 80, probably why I saw it happen pretty frequently then.

Java 1.7 has been very healthy with Minecraft for some time now. I seem to remember reading support for Java 1.6 has pretty much finished here, so definitely update to 1.8_11 (or whatever the current build is).

Looks like a duplicate of MC-63020.