So, a lot of people have been saying dynamic lighting is laggy, and too hard to code (the thing that makes a torch in your hand illuminate stuff).
There's an easy way to do this, without too much lag and coding:
Every tick, the game checks the player's position.
After that, it generates an invisible block in the front of the player, just like air, however the block emits light.
Just like this:
<---- invisible block that emits light
^
|
|
player holding a torch
I can't believe it's easy as that or they would have done it by now. I want proof that this doesn't cause severe lag in the form of a mod or video demonstration.
How does that make it any different from the torch itself emitting the light? Just doesn't make sense. The lag would be caused by the constant change in all of the blocks illumination levele around you
I can't believe it's easy as that or they would have done it by now. I want proof that this doesn't cause severe lag in the form of a mod or video demonstration.
I'm sure it doesn't cause lag, as this would require one block update per tick, while there are tons and tons of block updates every tick already
Redstone circuits, for example, require that each dust/repeater/etc updates every time, and their light level change every time, causing lag, but it's just a small drop on FPS. (maybe a 2-3 fps, I don't know)
I'm sure it doesn't cause lag, as this would require one block update per tick, while there are tons and tons of block updates every tick already
Redstone circuits, for example, require that each dust/repeater/etc updates every time, and their light level change every time, causing lag, but it's just a small drop on performance.
Unless you and I are both professional programers, I don't think this is something you can reason out with logic. I want a demonstration or credible evidence that this works. Otherwise I'm calling BS and I suggest you stop making claims outside your area of expertise.
I have some Java experience, but not much. I'm certainly not nearly as qualified as Notch or other programmers to say this, but I do believe that this would increase lag a fair bit. You have to render the block, and the light, all as the player moves. Redstone does not emit as much light, not nearly as much, and therefore is far easier to render. Not only that, but it is not as dynamic as the movement of the player.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
There's an easy way to do this, without too much lag and coding:
Every tick, the game checks the player's position.
After that, it generates an invisible block in the front of the player, just like air, however the block emits light.
Just like this:
^
|
|
player holding a torch
I'm sure it doesn't cause lag, as this would require one block update per tick, while there are tons and tons of block updates every tick already
Redstone circuits, for example, require that each dust/repeater/etc updates every time, and their light level change every time, causing lag, but it's just a small drop on FPS. (maybe a 2-3 fps, I don't know)
Unless you and I are both professional programers, I don't think this is something you can reason out with logic. I want a demonstration or credible evidence that this works. Otherwise I'm calling BS and I suggest you stop making claims outside your area of expertise.