Adam Reece
- Adambean
- adambean
- Europe/London
- Yes
- No
MC-63020
Added Attachments:
adambean-2014-07-23_16.52.02.png
Added Attachments:
Added Attachments:
Hi EvilSeph, thanks for fixing this. I guess you thought "haha wtf are they on who cares" etc, but I will appreciate this fix.
It provides a good warning that mobs will spawn even during daylight, and is overall a nice effect.
This has been bugging me since it never worked in SMP from the arrival of rain/thunder in MC Beta 1.5.
Bugged me even more since it broke in SSP too. (when SSP became a local-only SMP to simplify the code base)
Looking at the times you set for assigning and resolving the issue was this fix as simple as I thought it might be? (simply a case of setting the correct weather effect state in conjunction with sending this correct state as a network message to clients)
Shame this has been "fixed". I agree with Kumasasa and zombie hunter. An ocean is meant to be big. It's an ocean, not a pond.
Could we at least have the option for large oceans to make them generate in their traditionally massive size? They were good at dividing up continents on large worlds, especially in the large biome world. Or just keep oceans at their massive size for large biome worlds.
I'm fine with oceans being pretty empty. That's how oceans generally are. Small islands every now and then (even if somewhat rare) was also good.
IMO oceans were pretty much perfect from beta-1.8 to release-1.6.4. I do like that deep oceans are now here, but I'd have just used them for the main/middle section of large oceans and not put them near the shores at all – standard depth ocean near the shores/beaches then deep oceans when you travel far out enough (like 0.5 to 1 KM).
If you must travel fast between them either build a bridge with a powered railway or use the nether. Check the definition of "ocean" – they are meant to be massive bodies of water in which divide continents, so crossing them won't usually be quick.
I've not been able to reproduce this on 1.7.9. I've definitely had it on previous 1.7.x versions though.
Same, though mine happen just by the angle I'm looking – if I rotate usually slightly it's a gamble as to whether chunks draw or not.
Added screenshots of this happening on 14w30b. VBO doesn't appear to affect this much, only the sky colour behind chunks not being drawn.
I get this too.
Oddly I had a rather annoying chat with AMD about bad performance with OpenGL games, especially Minecraft. Their support team blamed the games for their bad and unoptimized code, though my much older (and slower) nVidia based GPU rendered Minecraft around 10x faster! AMD even said I had to update OpenGL myself...
Now that snapshot 14w30b is making use of vertex buffer objects and a more modern version of OpenGL this would highly suggest AMD have something significantly wrong with their OpenGL implementation in their drivers.
Old GPU: Gigabyte GeForce GTX 560 Ti overclocked edition
New GPU: Sapphire AMD Vapor-X R9 280X overclocked edition
I still have the email chain available.
@Bob: I see you're running Java 1.6 there. It's very advisable you upgrade to 1.8 (or 1.7) as there were some useful graphics performance improvements in Java 1.7. Would also be worth you dropping your chunk distance to 16 and try with VBO both on/off. Your GeForce 9800 GTX+ is also 6 years old now and even pre-dates Minecraft, so I wouldn't expect very grand frame rates from that. I didn't experience very grand frame rates with GeForce 8800 GT – even with two of them in SLI.
I would say this issue may still be valid as it happens on my much more modern GPU (less than 1 year old), should I post a fresh issue on that?
Looks like a duplicate of
MC-63020.Looks like a duplicate of
MC-63020.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).
I use FOV 80, probably why I saw it happen pretty frequently then.
Looks like
MC-63070covers this issue when caused by 3rd person and high FOV's (higher FOV = more likely). Likely that the two issues are related.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)
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 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.
If this is FOV related then this will be a duplicate of
MC-63020.Odd.. this appears to be fixed entirely for me in 14w30c.
Confirming as fixed in 14w30c.
Did you try in 14w30c? A bunch of the new rendering glitches got repaired.
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.
I guess this can be marked as resolved then.
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.
Ah I forgot about the brightness setting. For some reason mine keeps putting itself on +100% (even though I don't want it there).
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%.
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 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.
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.
)
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.