1.4 pre is out

[okamikk]

from what i've seen of some ( of direwolf's) videos, whats left for redpower for 1.3.2 is numerous bugfixes

[danidas]

I know that EE3 will not be released for 1.3 and instead is going right to 1.4 as indicated by its dev.

Also Thaumcraft 3 just hit a major snag requiring a large bit of code to be rewritten due to unintended world lag due to the aura system. - link

So a very low chance of seeing them released before 1.4 from what i can tell and most likely the change from 1.3 to 1.4 will be like past updates and be mostly painless. So I doubt that we will see all the mods for 1.3 or at least enough to update tenhnic with out missing major mods.

[GreenWolf13]

I have a couple inside sources with the mod devs.

Redpower will not release till 1.4.

Pics or it didn't happen. Who is your inside source, what other information is he giving you?

[Watchful11]

The inside source is slowpoke, and there's not much else i can say.

:)

[Lothos]

The inside source is slowpoke, and there's not much else i can say.

well, THAT source. That's what I call credible.

[jakj]

I haven't noticed any significant architectural changes so far from a distance between 1.3 and 1.4 branch, so in theory it should be non-traumatic, unless their new lighting code breaks too much of Forge. Somehow I doubt it, though.

[racingpro]

I believe they're leaving out the new lighting code until 1.5, unless something changed in the last few weeks. It was in for a week, but was removed the next week due to lag issues.

[jakj]

I believe they're leaving out the new lighting code until 1.5, unless something changed in the last few weeks. It was in for a week, but was removed the next week due to lag issues.

Definitely sounds like another Mojang-style hack, then, instead of an actual lighting-engine rewrite. Won't be a problem, then.

[danidas]

If I'm not mistaken I think the core of the lighting issues is that they are still using a very old version of openGL. Which is the true cause of a lot of the issues and limitations with the game along with its core engine. As it does not support advanced lighting which they are trying to hack into the game with out replacing the graphics engine.

From what I've seen it appears Eloraam (redpower's dev) is trying to hack in a new updated graphics engine into the game or at least playing with one. Which will allow for true colored lights and better graphics all around.

[jakj]

If I'm not mistaken I think the core of the lighting issues is that they are still using a very old version of openGL. Which is the true cause of a lot of the issues and limitations with the game along with its core engine. As it does not support advanced lighting which they are trying to hack into the game with out replacing the graphics engine.

From what I've seen it appears Eloraam (redpower's dev) is trying to hack in a new updated graphics engine into the game or at least playing with one. Which will allow for true colored lights and better graphics all around.

Uh...no. Unless we're talking about vastly different things, here, no. Minecraft's lighting is done by storing lighting values as a block property and propagating them under certain circumstances, which is why you get those shadowy places that update when you walk near them.

Minecraft has something called a "lightmap", which is just a very small texture in which one axis is relative to natural light (like the sun, or the nether glow) and the other axis is relative to artificial light (like torchlight). When rendering a block, Minecraft calculates a coordinate into this lightmap based on how much natural and artificial light is reaching the block, and then multiplies the block's base color by that color. (This is why torches make things slightly yellow, but only if they're not in sunlight, and why things appear reddish in the Nether.)

Real GL lighting is done by actual lighting sources, specified with ambient, diffuse, and specular values. (Minecraft does not use specular lighting at all.) When rendering standard items in the hand (what you're holding in the hotbar), Minecraft turns on GL lighting, which is why, if you turn in a circle, you'll notice the item in your hand gets brighter and dimmer: It's using ambient light, plus two diffuse lights above your head, one on each side, which are not related at all to the actual block-lighting conditions. It's still multiplied by the lightmap to get dim in caves.

Because most things in Minecraft never rotate, block-rendering code does not use GL lighting, but instead simulates it, and if you look at the code, you'll notice that Minecraft uses specific color multipliers based on which side of the block is being drawn. In my Imaginarium mod, I've had to re-create the Minecraft fake lighting with real ambient/diffuse lighting, which is why it doesn't always match: Basically, I'm using actual GL lighting to simulate Minecraft's fake lighting which is in turn a simulation of real GL lighting.

If Minecraft were to have a real lighting engine, it would simply keep a list in memory of current light sources: One ambient light based on sunlight and location (such as a cave), one diffuse light (the sun, if visible), and an array of diffuse lights (one for each torch/fire), that would get passed into a shader. For performance, if desired, this hypothetical lighting engine could set an upper limit on active light sources, or could select them only without a radius from each other, or several other options.

Even the shadows in Minecraft are not real: If you have a line of blocks (like a bridge) above other blocks, you'll notice they cast a shadow downward, but that is not done with GL lighting: It is an extra 2-dimensional quad (rectangle) drawn after the blocks, based (again) on the stored light level in the block.

[Silent]

I remember some old mod that made redstone torches actually release red light, is that kinda what you're talking about?

[jakj]

I remember some old mod that made redstone torches actually release red light, is that kinda what you're talking about?

You can modify the lightmap, yes, but only once per render frame. The mod would have to somehow detect there is a redstone torch nearby, and modify the lightmap, but that would make regular torches, lamps, and fire also emit the red light. The lightmap is generated conditionally per dimension (so each Mystcraft age could have a different lightmap, just as overworld/nether/end each have their own lightmaps.)

Sunlight, for example, is done by the lightmap. Even though Minecraft actually has 256 values for sunlight reaching a block (marked as opacity), every block is either completely transparent (subtracts 0 from the light that passes through it) or is completely opaque (subtracts 255 from the light that passes through it). (You can set different values for it, if you want, but no vanilla block does.) No matter the time of day, a block out in the open is always at sunlight value 255, but the lightmap is drawn with darker and darker shades of grey as the sun goes down, so when multiplied against the block's color, it dims.

(I might be a bit off: I haven't looked at that code recently, but it may be that it subtracts 1 from the light value for each block downward the light goes, so at the floor limit of block 0, the light would have reached 0. I think it probably does that, but I'd have to look at the code to remember.)

[Silent]

You can modify the lightmap, yes, but only once per render frame. The mod would have to somehow detect there is a redstone torch nearby, and modify the lightmap, but that would make regular torches, lamps, and fire also emit the red light. The lightmap is generated conditionally per dimension (so each Mystcraft age could have a different lightmap, just as overworld/nether/end each have their own lightmaps.)

Sunlight, for example, is done by the lightmap. Even though Minecraft actually has 256 values for sunlight reaching a block (marked as opacity), every block is either completely transparent (subtracts 0 from the light that passes through it) or is completely opaque (subtracts 255 from the light that passes through it). (You can set different values for it, if you want, but no vanilla block does.) No matter the time of day, a block out in the open is always at sunlight value 255, but the lightmap is drawn with darker and darker shades of grey as the sun goes down, so when multiplied against the block's color, it dims.

(I might be a bit off: I haven't looked at that code recently, but it may be that it subtracts 1 from the light value for each block downward the light goes, so at the floor limit of block 0, the light would have reached 0. I think it probably does that, but I'd have to look at the code to remember.)

Hmm I remember it only did redstone torches, this was also in alpha if I remember correctly, way before adventure update lighting changes

[NightKev]

Definitely sounds like another Mojang-style hack, then, instead of an actual lighting-engine rewrite. Won't be a problem, then.

Here's all Dinnerbone's twitter posts about it, in order (I think):

Remember that silly lighting bug where world would generate with big black patches? Well you may not remember it in the future; it's fixed.

— Nathan Adams (@Dinnerbone) September 26, 2012

It's such a small thing to look at, but this required unbelievable amounts of code changing :D http://t.co/Ew8tlqbm http://t.co/Pdtypn3q

— Nathan Adams (@Dinnerbone) September 26, 2012

Half slab with light: http://t.co/mDJ6Zv8X http://t.co/z6ugqqUp (there's a torch inside the box, one half slab on the front)

— Nathan Adams (@Dinnerbone) September 26, 2012

I think I'm going to revert the new lighting stuff and come back to it for 1.5. I'd rather get other (actually working) bugfixes in 1.4.

— Nathan Adams (@Dinnerbone) September 28, 2012

Looks like we can keep the lighting code; Managed to selectively revert the worldgen portion. Nether is good, but blackspots are back.

— Nathan Adams (@Dinnerbone) October 1, 2012

Lighting is really annoying me now. Reverting everything I've done to it, will come back to it in 1.5 : (

— Nathan Adams (@Dinnerbone) October 4, 2012

[jakj]

Yeah, that confirms it: Not actually changing the system from the current, and it's still light values stored in blocks. He's just altering the ways it's calculated, stored, propagated, or whatever, and that'll barely have an effect on Forge.

It's really frickin' annoying, because right now, it's impossible to set a block to be opaque (as in it casts a shadow beneath it and kills grass below it) with a custom renderer without Minecraft drowning the thing in darkness. Even if you disable every single part of the block's Vanilla rendering code, it still uses the block's opacity value to draw a shadow on it.

[GreenWolf13]

Yeah, that confirms it: Not actually changing the system from the current, and it's still light values stored in blocks. He's just altering the ways it's calculated, stored, propagated, or whatever, and that'll barely have an effect on Forge.

It's really frickin' annoying, because right now, it's impossible to set a block to be opaque (as in it casts a shadow beneath it and kills grass below it) with a custom renderer without Minecraft drowning the thing in darkness. Even if you disable every single part of the block's Vanilla rendering code, it still uses the block's opacity value to draw a shadow on it.

So here's the real question then. Why didn't Notch use a real lightning engine like openGL instead of making a crappy simulation of it?

Oh wait, this is Notch we're talking about, and everyone knows he has to go out of his way to do things as bass-ackwards as possible.

[jakj]

So here's the real question then. Why didn't Notch use a real lightning engine like openGL instead of making a crappy simulation of it?

Oh wait, this is Notch we're talking about, and everyone knows he has to go out of his way to do things as bass-ackwards as possible.

Well, it wasn't that he didn't understand GL lighting, because he does use it in a limited way in the code already. And it wasn't that it's less work to do it this way, because it's a whole lot more work to do lightmaps and light-value propagation in the chunk handler and all this other business.

The only thing that I can possibly think of is that somehow he felt he had to do it this way, that since the world was made up of blocks, and the liquids were blocks, and even the sun and moon were blocks, that the light should be blocks too.

It's not like occlusion was a concern, either: That's the code that Jeb's just getting around to now, years later, getting light to wrap around stuff and pass through stuff horizontally (though reflectivity is clearly well beyond even his current motivation). The same code that would handle the lighting in the first place (ambient is a simple multiplication; diffuse is a dot product followed by a multiplication) would also handle the very basic computation of vertical occlusion like the chunk handler does now.

-And- it could still stick to GL 1.1 like it does now, with no shaders at all, for maximum portability.

[freakachu]

if I had to take a guess, I'd say that it is probably representative of an evolution in notch's understanding of openGL as he made the game. I think he may not have had much of a grasp on lighting initially, created the hacked together system the blocks use, then when he decided he wanted stuff in your hand to be lit somehow too, he had enough of a grasp on openGL lighting to use that instead. he just never went back and redid the old code, and now it's impossible to mess with because it's so backwards. or he did the held items differently specifically to try it out and learn how it works. I know I have done similar things, with results that wouldn't make any sense to an outsider like this.

[Silent]

It would be quite amazing if Minecraft was somehow redone from the ground up, I feel like everything might be smoother

[NightKev]

Of course it would be, since they have all this experience to draw on now. As shown by Dinnerbone's attempt to fix the mess that is the Minecraft codebase, they NEED to massively overhaul the code and release a "Minecraft 1.0 2.0" instead of wasting time adding a bunch of mostly useless features (and a couple of good ones).

[bwillb]

It would be quite amazing if Minecraft was somehow redone from the ground up, I feel like everything might be smoother

Eloraam is essentially doing just that, I think.

[jakj]

Freakachu, that makes a scary amount of sense. I didn't think of that because it's so opposite of the way I work: I have trouble getting things done at all, because every time I learn something new, I go and rewrite everything, and then I keep reviewing everything I've written to see what can be made better, so after days of effort I end up with 1-3 extremely-tight classes instead of 8-9 functional ones. :D

[Lethosos]

To be fair, if Notch was attending the same game design classes as I did before, he'd be slapped for not bothering to optimize his code.

Then, again, he would be coding in C++.

[jakj]

To be fair, if Notch was attending the same game design classes as I did before, he'd be slapped for not bothering to optimize his code.

Then, again, he would be coding in C++.

Java is a fine language if used well. Of course it'll be slower than a bare-metal language like C (or C++ without STL), but on modern processors (even most newer mobile ones), the difference is negligible with good code. It's even gotten to the point that some smaller uses of pools instead of reallocation (basically, uses where no OS resources are leveraged and only new/GC is in use) are recommended against as being no performance gain.

If you recall, Notch wrote a blog post a long time ago about how he tried to get a professional programming job and was turned down because he was so clearly self-taught and probably wouldn't work well in a group, and how surprised and enlightened he was about that. Well, there you go.

When you are not writing something super-freaking-essential, like drivers for CERN hardware or Crysis 3, the benefits of Java (ease of development, portability, extensibility, and deployment) vastly outweigh any detriments (additional overhead, installation of VM required).

[GreenWolf13]

Since 1.4 comes out in 2 days, do you think I stop working on development of my mod and wait until Forge updates, or keep working on development and then try porting it over to 1.4 when Forge does update?