Attempt to fix incompatibility with bendy-lib (Emotecraft)

[KosmX]

see issue #13

I did modify args from colored-lights with a higher priority than bendy-lib

[Fourmisain]

When I originally wrote it I was thinking about that too and I was gonna suggest running tests on this - then forgot about it. There's no simple way around this overhead - there may be a way of directly changing the render method parameters, but since this method is recursive it would probably not be correct.

I did just run a quick and dirty comparison test, with the above mixin, vs an empty method mixin (not a fair comparison, but that's kinda the point). I had a lava source and sea lantern near ~50 zombies, so that should be 300 model parts. With the empty mixin I got around 101 fps, with the above mixin I got around 99 fps, with some fluctuation of maybe ±3 fps.

Because it was so unscientific, I ran a more controlled test in a flat world with increases entity cramming, I put a ton of zombies (entity counter says 325) in a 2x2 hole and put 2 sea lanters at each side. Got ~48 fps with above mixin, ~49 fps with an empty mixin, ±2 fps.

So the overhead might actually not be that bad. I also don't think GC will be significantly impacted by this - G1 should do fine with it, though maybe some more testing is required on this front?

[KosmX]

With the redirect, you copy variables on the stack.
Now, you do it in a function, not by a function call.

If you want to improve the render performance, you should do colored lights by shaders, not by Java code

[Fourmisain]

Just to complete the performance comparison, here's the @Redirect version vs the @ModifyArgs, only colored-lights:

@Redirect: @ModifyArgs:

So all in all: There is a measurable difference, albeit pretty small (<1ms, ~1 fps on my system).