As far as major features, there would be only one new one: the ability to customize your Minecraft 2 experience using packages. A package is basically a resource pack, but instead of just overwriting textures, a package overwrites and adds in new code. There would be the basic "Minecraft 2.0.0" package, and all updates would be added as a separate package. For example, let's the basic package didn't initially have alchemy in it. They could release another package, "2.1.0-Alchemy Update," which you could then apply to the game from the launcher. This means that the base package is never modified (except for maybe bug patches). However, this also means that every package is largely independent and wouldn't require any other package to be enabled to be utilized (they could require another package, for example if a mod is dependant on a particular API, but the vanilla packages wouldn't require another package to be enabled for the most part). So, let's say you didn't like the features of 2.1., but you wanted to play with the new features of 2.2. You could enable the packages you want, and keep the ones you dislike disabled. What if 2.2 added an item that had an alchemical use, but you had 2.1 disabled? The item would still be available, but because you don't have any ability to do alchemy, the item won't be able to perform its alchemical purposes. Mods would also be released as packages, and could just be installed by putting them in the packages folder, and would likely always be compatible with the base game and wouldn't be broken by updates. The only major problems I could see with this is that major overhauls would have to be avoided due to problems with balancing if you played with a later update with the overhaul disabled. However, this increases customizability, and I say one should be able to play Minecraft however you want. For an example of a game that has this kind of system, look at Bethesda game Skyrim.
All platforms of the game would be written in the same language, probably C++. This would allow for cross-platform play across all versions (where the platform owners allow), and all versions could easily be updated at the same time. The engine would likely run on DirectX 11, which would allow for better graphics and better performance. This would, unfortunately, increase the system requirements a bit, but most modern computers should be able to run it.
Minecraft 2 would be developed by a whole new team hired by Mojang to work on the game (Mojang YZ?) while the original team continues to work on the original game and provides guidance. Thus, we would still get updates to the prequel during the time (likely three or four years) it takes the sequel to develop. As for after release, I assume the original Minecraft would get one more update, and then only get bug fixes. The game would be released on all major platforms simultaneously (Xbox One, PS4, Switch, Mobile, Steam, and Windows App Store).
So, I'm only going to comment on this, as this is where I mostly know my stuff, and I feel the stuff I want to say hasn't been covered 100%.
In general, this is exactly what the Bedrock codebase is. Microsoft are designing the Bedrock version of the game to function using distinct packages, which are called resource packs, and they contain everything for the game, including code, even for the vanilla content. Mods under Bedrock are distributed as resource packs. So, for everyone saying that designing the game like this is hard, just saying, it's already happening.
"The engine would likely run on DirectX 11, which would allow for better graphics and better performance. This would, unfortunately, increase the system requirements a bit, but most modern computers should be able to run it."
The thing you have to keep in mind, is DirectX is an exclusive Windows library. It cannot operate outside of a Windows environment. So if you value cross-platform capabilities, you'll have to include OpenGL/Vulkan somewhere in there. This is also what's happening to Bedrock. The Windows 10 Edition uses Direct3D, where all other editions use OpenGL. The problem with this is the rendering code is platform-specific, though I've been told that the rendering team is thinking of ways to alleviate this.
For a "Minecraft 2.0" engine, I would personally like to see it use a modern version of OpenGL, such that it maintains compatibility on multiple platforms aside from Windows, and it allows the developers (and, by extension, us shader devs :p) the ability to use more modern rendering features, that we just cannot use now with Java, since it's stuck with OpenGL 2.0.
You should also consider the implementing of colored lights: an RGB lighting system; and the implementing of not-lagging hexadecs colour mechanics for specific blocks (that would to do possible the addition of until 16.777.216 colored blocks for each colorable block of the game); as well as a more complex and extended brewing mechanic and potion result diversity; and the addition of non-euclidean rendering portals (that would to do portals more realistic, more aesthetic and direct; basically, you would see your destination landscape through the nether portal; and give the possibility of have non-euclidean structures and mazes at the end dimension).
Depending on the specifics of the renderer, non-Euclidean rendering might not be practical. Outside of raytracers, actual non-Euclidean rendering is pretty much impossible to pull of with traditional rendering techniques that all games use today. Games using non-Euclidean rendering cheat by re-rendering the world to a separate render target / camera, but, if this "Minecraft 2.0" uses a deferred renderer (which I gather it would, to allow cheap lighting in the world), that won't be feasible since the entire process of rendering the world becomes very expensive, and would pretty much halve FPS to do it a second time, let alone n times.
Coloured lighting is more than possible, with an engine rewrite, full RGB colour values might be possible, again depending on the specifics of the engine.
@Triliton last time I had a driver update was June 28,2017 and it only started happening a couple days afterward out of nowhere.
When it first happened I was using SEUS shaders and localized weather & stormfronts mod/tornado mod.
Try backdating your driver to the one released June 9th, I believe. I was using that newer driver, and had some weird artifacts with my pack, so your issue might be related.
Look Why the heck do 1.5 and below updates Have lag. While Updates 1.11.2 1.11 and other dont include lag.
For the sake of me can you understand now?
... optimisation. Alpha, beta, all the older versions primarily developed when Notch was in charge had horribly inefficient code and did things in an inefficient manor. Mojang has slowly been working on redesigning the internals to be more efficient, which is exactly what optimisation is, redesigning with the intent of improving efficiency.
First of all.I'm very grateful to you.Thank you for making the Shaders Mod. It's a great Mod
But most of the Mod versions of MC remain at 1.7.10,such as optifine,fastcraft and so on.Except FORGE still stays at 1614 version,but that's no big deal.
I hope you can continue to update the version of Shaders Mod in MC1.7.10
Because the current version of Shaders Mod in MC1.7.10 is no longer compatible with the most basic MOD:OPTIFINE and fastcraft
I believe there are still a lot of players still playing MC1.7.10.Shaders Mod is a crucial and indispensable MOD for me (for everyone)
THANK YOU!
If you need shaders on 1.7.10 and can use Optifine, use the latest version of Optifine for 1.7.10. sp614x backdated a lot of the shader stuffs to all versions as far back as 1.7.10, so every shader should work now.
I also see another problem. The addition of dynamic lights, if bad implemented, could do to any shader mod non-compatible and impossible to apply to the game, that is a big and important problem.
I prefer have dynamic lights still being a client illusion easy to activate or deactivate, and not forced nor obligatory in the game.
It'd depend on how it was implemented. Optifine pretty much injects its own dynamic light directly into the light map when a block face is being rendered, which means it automatically, without any work on our, the shader dev's side, just works. My shader pack hasn't had dynamic lighting ever, but if I enable Optifine's, it just works. Optifine's solution is incredibly elegant from the shader dev side of the fence.
All that'd need to happen is dynamic lighting simply gets injected into the light map prior to rendering. If that happens, nothing needs to change with shaders.
I really, really, hope that Mojang makes it impossible for older versions to load 1.13+ worlds, because, well, remember 1.8 and items? Losing all your items is one thing but losing the entire world is another. Ideally, it should be like the conversion from MCRegion to Anvil, which created new region files with different extensions (.mca vs .mcr), as well as a backup of level.dat so it was easy to revert back unless you deleted the old files, and the NBT version inside level.dat was changed, making older versions unable to recognize the world (albeit they could still overwrite level.dat if you made a world with the same name).
Also, I thought the issue with insufficient IDs had to do with the 256 ID limitation due to legacy code that reserved the lower 256 item IDs for blocks (it should have been removed in 1.8 since numerical IDs are no longer used in the relevant classes within the code, such as the ItemStack class I mentioned before); we are still far away from using 4096 block IDs, or even 256 if Mojang had made more use of tile entities and data values (Pocket Edition uses a single ID for all wooden fences, storing their variants in metadata, while PC doesn't use it at all, and Shulker boxes could have stored their color as tile entity data).
Mojang could just use the additional 4 bits out-of-the-box to allow them to use 4096 IDs, but that's just moving the limit up. This solution is effectively going to completely remove the limit. Chunks will be able to store the same amount of block types that there is spots to place blocks, so even if you tried, you wouldn't be able to force the game to run out of IDs, because plainly there isn't enough spots to place blocks to do so. That's the beauty of this system, in my opinion.
It also removes the need for metadata to be stored as additional data. A block can just create instances of itself, so instead of "minecraft:wool", with a metadata value of 6 for pink wool, it instead now becomes "minecraft:wool_pink". Effectively, you're limited by the size of the array that block instances are stored in, not by some arbitrary ceiling that exists to make saves as small as possible, while also retaining saves being as small as possible. Pretty much you wouldn't ever run out of IDs, and there wouldn't be ID clashes externally or internally. No hacky methods to automatically assign blocks to IDs, it's all handled by the ID palette.
I'd also assume that they would add a way to convert worlds over. In theory, all you'd have to do is iterate over a chunk region, adding any blocks to the ID palette, then iterate over it again converting the old IDs to the new palette IDs.
They're going to be increasing the number if block IDs in 1.13 by moving numerical IDs to chunks. Chunk regions (16x16x16 sections of chunks, the save data code stores and works with chunks in 16x16x16 sections) will now store a map that translates the global names of any types of blocks stored in that chunk to a local numerical ID. This effectively moves the 4096 ID limit from the game to chunk regions, which incidentally 16x16x16=4096, so with this new system, you won't be able to run out of IDs. The most you can do is fill up an entire chunk, but you'll be forced into the next chunk due to no more places to place blocks being available.
This is good to know about the CPU, I will keep that in mind, most that I have been looking at have been at I5 or above with at least 8GB RAM. I used to think that that is what mattered and felt pretty confident in looking, but then I started seeing people say that the GPU or having an integrated graphics card was more important, and, I'm not techy enough to be able to investigate that confidently, so, again, I appreciate your examples and help
The GPU only becomes an important factor if the CPU isn't bottlenecking things. That's why there was a 130 FPS difference between my HD 4400 and my 840M, the i5 4210U was sufficiently quick enough to allow the GPU to flex a bit more. If I were running some low-end i3 or Pentium processor, on the other hand, I doubt the GPU would make that big of a difference.
The story does change with mods, though, which demonstrates my point even more. With 221 mods under 1.7.10, the 840M, and slightly lower settings than I'd usually run with (6 render distance instead of 8), my FPS hovers right around 50-60. The mods impose such an impact to the load on the CPU, that it makes the CPU a bottleneck, so the GPU doesn't matter at all.
With shaders, however, GPU plays a far more important role. At roughly 800x600, with my own shader (which can be considered a high end shader), 8 render distance, I'm getting anywhere between 20-40 FPS in a normal world. Compared to 180+ FPS without shaders, full screen, in the same world. Shaders impose a lot more work on the GPU, to the point where it becomes an even bigger bottleneck than what it normally would be.
Actually, you can find mid-range cards like that in business laptops. Business and work laptops do tend to come with somewhat beefy GPUs to support a workload that would benefit off of that, such as video editing or rendering. I know because my old multimedia teacher had a business-oriented laptop with an 860M in it. It was minimalistic with brushed aluminium, and a small keyboard.
But these really speak to having a dedicated graphics card, I can't really find anything with recommendations for an integrated graphics card, just people/articles saying it's not ideal, but I know it can be done, because I play it on a LenovoThinkpad with an integrated graphics card and it does pretty good for about an hour or two then I'll have to shut the game down and restart it, and it works fine again.
The card in my Thinkpad just has the name Intel HD graphics family, so, doesn't give me much to go off of.
So, can someone give me an idea of what integrated graphics card minimum/recommended specs would be on a 2 in 1? Thank you!
So long as the CPU isn't a total deadweight, you can run the game on anything, no matter the GPU. A dedicated GPU will help with FPS, but it isn't necessary to play it smoothly. My laptop with an i5 4210U, a rather low to mid end mobile processor, with its Intel HD 4400 integrated GPU, can run the game just fine at about 80 FPS in a normal world. Compared to my 840M, which runs at about 200 FPS. There is a pretty big difference, but the HD 4400 is still beyond playable.
jcm2606,
May you help us then? I have a prob with only Advance Warfare 2. I had some config file in my configs that contained a list of avaliable configs so I used it to fix AoA(Nevermine)'s config so it works in my modpack. But it doesn't exsist anymore so I dun know how to fix Advance Warfare 2. The configs do exsist.
What exactly is the problem? And keep in mind I haven't touched Java in years, so I'm a bit rusty.
I love this idea, but I think it would be tricky to get right if implemented. The game would have to distinguish between caves and other areas(as pointed out by BlackAbsence.) The echo should be subtle, so the creeper explosion doesn't blow people's ear drums out. If not done right, this addition would be nothing but an annoyance.
Ray casting. Sonic Ether's Sound Physics mod uses this; it shoots rays out in random directions from the source of whatever sound it's processing to get a general idea of the environment around the location, and from that work out how the sound should reverberate. Additionally, you can also cast a ray toward the player to work out if somehow sound is able to get to the player without hitting any obstacles.
Ok, is it so much hard to implement? They may work like shaders :/ I don't know
Even shaders cannot implement true coloured lighting without doing some ray tracing in some way. The colour of light is tied to the intensity of light, not the type of block emitting the light. All that blocks do in terms of lighting is set the intensity of light for adjacent blocks. When it comes time to render the world, the game then gets the intensity of both block and sky lighting for a given block, and uses those as coordinates to read a texture, which returns the colour of light for that block from a gradient. Coloured lighting would require storing the RGB colour of light for that block, then somehow mixing the inherent light colour from intensity, to the source colour. And that's not getting into mixing source colours.
For shaders, all we have access to is the texture the gradient is stored in, and the coordinates used to read that texture. From the coordinates we can derive the intensity of block and sky light for a given pixel. We don't know what block emitted that light or even where it's coming from in the world.
0
Try backdating to 382.53. Latest driver is known for causing issues with Minecraft shaders.
0
So, I'm only going to comment on this, as this is where I mostly know my stuff, and I feel the stuff I want to say hasn't been covered 100%.
In general, this is exactly what the Bedrock codebase is. Microsoft are designing the Bedrock version of the game to function using distinct packages, which are called resource packs, and they contain everything for the game, including code, even for the vanilla content. Mods under Bedrock are distributed as resource packs. So, for everyone saying that designing the game like this is hard, just saying, it's already happening.
"The engine would likely run on DirectX 11, which would allow for better graphics and better performance. This would, unfortunately, increase the system requirements a bit, but most modern computers should be able to run it."
The thing you have to keep in mind, is DirectX is an exclusive Windows library. It cannot operate outside of a Windows environment. So if you value cross-platform capabilities, you'll have to include OpenGL/Vulkan somewhere in there. This is also what's happening to Bedrock. The Windows 10 Edition uses Direct3D, where all other editions use OpenGL. The problem with this is the rendering code is platform-specific, though I've been told that the rendering team is thinking of ways to alleviate this.
For a "Minecraft 2.0" engine, I would personally like to see it use a modern version of OpenGL, such that it maintains compatibility on multiple platforms aside from Windows, and it allows the developers (and, by extension, us shader devs :p) the ability to use more modern rendering features, that we just cannot use now with Java, since it's stuck with OpenGL 2.0.
Depending on the specifics of the renderer, non-Euclidean rendering might not be practical. Outside of raytracers, actual non-Euclidean rendering is pretty much impossible to pull of with traditional rendering techniques that all games use today. Games using non-Euclidean rendering cheat by re-rendering the world to a separate render target / camera, but, if this "Minecraft 2.0" uses a deferred renderer (which I gather it would, to allow cheap lighting in the world), that won't be feasible since the entire process of rendering the world becomes very expensive, and would pretty much halve FPS to do it a second time, let alone n times.
Coloured lighting is more than possible, with an engine rewrite, full RGB colour values might be possible, again depending on the specifics of the engine.
0
Try backdating your driver to the one released June 9th, I believe. I was using that newer driver, and had some weird artifacts with my pack, so your issue might be related.
0
... optimisation. Alpha, beta, all the older versions primarily developed when Notch was in charge had horribly inefficient code and did things in an inefficient manor. Mojang has slowly been working on redesigning the internals to be more efficient, which is exactly what optimisation is, redesigning with the intent of improving efficiency.
1
If you need shaders on 1.7.10 and can use Optifine, use the latest version of Optifine for 1.7.10. sp614x backdated a lot of the shader stuffs to all versions as far back as 1.7.10, so every shader should work now.
1
It'd depend on how it was implemented. Optifine pretty much injects its own dynamic light directly into the light map when a block face is being rendered, which means it automatically, without any work on our, the shader dev's side, just works. My shader pack hasn't had dynamic lighting ever, but if I enable Optifine's, it just works. Optifine's solution is incredibly elegant from the shader dev side of the fence.
All that'd need to happen is dynamic lighting simply gets injected into the light map prior to rendering. If that happens, nothing needs to change with shaders.
0
Mojang could just use the additional 4 bits out-of-the-box to allow them to use 4096 IDs, but that's just moving the limit up. This solution is effectively going to completely remove the limit. Chunks will be able to store the same amount of block types that there is spots to place blocks, so even if you tried, you wouldn't be able to force the game to run out of IDs, because plainly there isn't enough spots to place blocks to do so. That's the beauty of this system, in my opinion.
It also removes the need for metadata to be stored as additional data. A block can just create instances of itself, so instead of "minecraft:wool", with a metadata value of 6 for pink wool, it instead now becomes "minecraft:wool_pink". Effectively, you're limited by the size of the array that block instances are stored in, not by some arbitrary ceiling that exists to make saves as small as possible, while also retaining saves being as small as possible. Pretty much you wouldn't ever run out of IDs, and there wouldn't be ID clashes externally or internally. No hacky methods to automatically assign blocks to IDs, it's all handled by the ID palette.
I'd also assume that they would add a way to convert worlds over. In theory, all you'd have to do is iterate over a chunk region, adding any blocks to the ID palette, then iterate over it again converting the old IDs to the new palette IDs.
0
They're going to be increasing the number if block IDs in 1.13 by moving numerical IDs to chunks. Chunk regions (16x16x16 sections of chunks, the save data code stores and works with chunks in 16x16x16 sections) will now store a map that translates the global names of any types of blocks stored in that chunk to a local numerical ID. This effectively moves the 4096 ID limit from the game to chunk regions, which incidentally 16x16x16=4096, so with this new system, you won't be able to run out of IDs. The most you can do is fill up an entire chunk, but you'll be forced into the next chunk due to no more places to place blocks being available.
0
The GPU only becomes an important factor if the CPU isn't bottlenecking things. That's why there was a 130 FPS difference between my HD 4400 and my 840M, the i5 4210U was sufficiently quick enough to allow the GPU to flex a bit more. If I were running some low-end i3 or Pentium processor, on the other hand, I doubt the GPU would make that big of a difference.
The story does change with mods, though, which demonstrates my point even more. With 221 mods under 1.7.10, the 840M, and slightly lower settings than I'd usually run with (6 render distance instead of 8), my FPS hovers right around 50-60. The mods impose such an impact to the load on the CPU, that it makes the CPU a bottleneck, so the GPU doesn't matter at all.
With shaders, however, GPU plays a far more important role. At roughly 800x600, with my own shader (which can be considered a high end shader), 8 render distance, I'm getting anywhere between 20-40 FPS in a normal world. Compared to 180+ FPS without shaders, full screen, in the same world. Shaders impose a lot more work on the GPU, to the point where it becomes an even bigger bottleneck than what it normally would be.
0
Actually, you can find mid-range cards like that in business laptops. Business and work laptops do tend to come with somewhat beefy GPUs to support a workload that would benefit off of that, such as video editing or rendering. I know because my old multimedia teacher had a business-oriented laptop with an 860M in it. It was minimalistic with brushed aluminium, and a small keyboard.
So long as the CPU isn't a total deadweight, you can run the game on anything, no matter the GPU. A dedicated GPU will help with FPS, but it isn't necessary to play it smoothly. My laptop with an i5 4210U, a rather low to mid end mobile processor, with its Intel HD 4400 integrated GPU, can run the game just fine at about 80 FPS in a normal world. Compared to my 840M, which runs at about 200 FPS. There is a pretty big difference, but the HD 4400 is still beyond playable.
0
What exactly is the problem? And keep in mind I haven't touched Java in years, so I'm a bit rusty.
0
Ray casting. Sonic Ether's Sound Physics mod uses this; it shoots rays out in random directions from the source of whatever sound it's processing to get a general idea of the environment around the location, and from that work out how the sound should reverberate. Additionally, you can also cast a ray toward the player to work out if somehow sound is able to get to the player without hitting any obstacles.
0
I forgot to set it to permanent... derp! Try this one.
0
Even shaders cannot implement true coloured lighting without doing some ray tracing in some way. The colour of light is tied to the intensity of light, not the type of block emitting the light. All that blocks do in terms of lighting is set the intensity of light for adjacent blocks. When it comes time to render the world, the game then gets the intensity of both block and sky lighting for a given block, and uses those as coordinates to read a texture, which returns the colour of light for that block from a gradient. Coloured lighting would require storing the RGB colour of light for that block, then somehow mixing the inherent light colour from intensity, to the source colour. And that's not getting into mixing source colours.
For shaders, all we have access to is the texture the gradient is stored in, and the coordinates used to read that texture. From the coordinates we can derive the intensity of block and sky light for a given pixel. We don't know what block emitted that light or even where it's coming from in the world.
0
Mind popping into the shaderLABS Discord? It'll make the process of debugging much easier.