ambient

@unknown seriously?

The requested videos have been attached.

The following videos were taken in a friend Xbox Live world in 1.21.0.3. Each of the 4 emotes are paid, and the spectator is the world host. The spectator never opened the Emote Menu or persona screen throughout the entirety of the Minecraft being open.

This is most likely intentional, to mitigate performance loss; the lava texture you see outside a certain radius is most likely the first frame of the flowing lava flipbook. It would be wasteful for all those textures to animate from so far out as you wouldn't notice it as much.

Moreover, based on your screenshot, I don't really notice any blurriness per-se. Regardless, I'm pretty sure that this would also be caused by a performance improvement technique called mipmapping (without mipmapping, all textures far away would look extremely grainy).

I attached a pack that seems to fix this issue. I just played around with the depth bias for some relevant name/nametag materials and it seems to now behave as it did in 1.19.63.

I attached some images comparing idling in a flat world between 1.18.12 x86 and 1.18.12 x64. I had to test in 1.18.12 because it was the last version that included the old engine in its x86 builds. The results are as follows:

1.18.12 x86:

• fps average: 1350-1450

• memory usage: 265mb-275mb

• cpu usage: 10-15%

• gpu usage: 28-32%

1.18.12 x64:

• fps average: 600 - 700

• memory usage: 740mb - 750mb

• cpu usage: 20-25%

• gpu usage: 18-22%

I have a rtx 3060 with 6gb of vram, 32gb of 3200mhz ddr4 ram, a ryzen 7 5800h cpu with 16mb cache running at ~ 3.9ghz

The graphical settings I had on for this test were 10 chunk render distance, all anti aliasing off/all the way down, smooth lighting, and fancy graphics on. I am running windows 10 build 19044 and a dx12 capable device

Flying around and generating new chunks with my iPhone 12 is absurdly slow. This is a top-of-the-line phone and the game seems to struggle. Considerably longer world load times as well. Opening the chat window for the first time in a session freezes the game for approximately 10 seconds. 

It turns out that switching to Dx11 with a render dragon build increases performance immensely, at least on Minecraft for Windows. Why does Mojang insist Dx12 be used when it was implemented so poorly on bedrock? Is it possible for the developers to introduce a toggle to switch to Dx11 for a future build of Minecraft for Windows? From what I can see, Dx11 is still supported on the client, it just needs to be activated.

This bug was referenced in the 1.18.31 hotfix changelog. Performance is still more or less the same (poor) with the Render Dragon engine, even in with the hotfix. So just want to reiterate that this still affects 1.18.31.

Affects 1.18.30. This update is special because now, nobody has a choice. Windows 10 players cannot use x86 in order to take advantage of the stability and better performance of the older engine. 

affects 1.18.12 and every version since 1.16.210. why hasnt this bug been fixed? 

please fix this, its such an eyesore to look at now

Apparently, people are relating this bug report to the performance degradation of render dragon / recent versions. While it is true that the performance of later versions is absolutely horrendous, I actually do not experience a drastic CPU usage spike while running the render dragon version of the game. I noticed that render dragon seems to use less CPU than versions preceding 1.16.200. Note that I don't mean for this to come off as a good thing; as I said the game performs terribly. Not even my 3060 and 8 core processor can match my display refresh rate on low settings anymore in moderate loads. Ideally I'd love to see Mojang remove all the bloat and terribly slow systems they put in place over the last couple major versions and actually focus on what the community is saying. It has gotten out of hand and at this point, Mojang is only riding off of Minecraft Java's popularity (mainly in 3rd party content) and the legacy that old bedrock (when it was more stable) has created.

The 1.18.10 bug seems to be completely separate from what this report describes. Servers used to be able to send MovePlayerPackets back to the client to report movement just fine up until 1.13. Starting from 1.13.0, the game changed how the client interpolated raw positional movement when receiving this packet, causing it to look choppy and discontinuous, as if they were teleporting to a new position every tick. Servers got around this by sending the same packet that normally gets sent when mobs move (MoveActorAbsolutePacket), and that solution has worked very well, up until this update.

enchanted bows appear translucent regardless of dimension on 32 bit win10

@Maciej Piornik, with all due respect, what makes you think it could potentially not still be a problem? Has anything been done to optimize the game engine since it came out? People are flocking to the 32 bit version of the game now. We don't care about RTX, as if most of us even could get our hands on, much less afford such a graphics card. We are seeing performance degrade with each successive update. So yes, this is still very much an issue. My computer seriously struggles to run this game now on x64, and not even my beefy specs seem to improve performance that much. Its not our devices, its your engine. RIP android players in 1.18.20.

 bug was actually NOT fully fixed. I can still reproduce for 1.18.0+ on 32 bit / x86 releases. I experience no crash on the x64 / Render Dragon engine though.

please close, this issue was fixed sometime recently and I falsely assumed it was in latest because no patch note was mentioned

whats even the point of reporting these fall damage related bugs. The source of these problems are just the fact that fall damage is server authoritative and the misplace is terrible with server-authoritative movement. Mojang, do everyone a favor and add back the actorFallPacket. Its caused so many problems since fall damage became server auth. Presumably this change was brought about to eliminate the possibility of noFall hacks, but its a pretty harmless hack compared to literally being able to give yourself items and the server just accepting the transaction. NOTIMPLEMENTEDTODO 😉

why hasnt this issue been fixed? Its honestly ridiculous. Can we please get an update on the matter?

this seems to be caused by a mismatch with the client's entity gravity and the server's. Similar to experience orbs, item entities use clientside gravity calculations but my guess is that the jitteriness is caused by the server correcting/rubber banding the item entity's position while its falling.