I'll support this idea.
To resolve the issues, perhaps the tile where two slabs are placed is 'split' into two separate slabs, thereby preventing more block IDs from being used. However, only the tile where two slabs are placed would be split to prevent too many separate hitboxes and textures, which cause lag.
Rollback Post to RevisionRollBack
Quote from Fermat »
I have discovered a truly remarkable proof of this, which this margin is too small to contain.
[;/quote]
I'll support this idea.
To resolve the issues, perhaps the tile where two slabs are placed is 'split' into two separate slabs, thereby preventing more block IDs from being used. However, only the tile where two slabs are placed would be split to prevent too many separate hitboxes and textures, which cause lag.
Suggestion #2 is the closest I can think of to splitting the blocks. This does give me a few ideas for things to add to the suggestion.
With the current way the half slabs work, the double slab is a different id.
There are 13 different slabs
for every bottom slab, there needs to be 13 different ids for a different top slab.
that's a lot...
I can't understand about half of this, does that make me stoopid, normal, or smart?
anyway, it seems like a lot of possibilities but a major reprogramming, so i don't support it
It makes you normal, most people don't understand what I wrote, I may be really bad at wording things. >_<
I don't really know how much reprogramming it would take for Mojang to do. But coming from a modding point of view, I can think of anywhere from 200-400 lines of code. Just guessing though.
With the current way the half slabs work, the double slab is a different id.
There are 13 different slabs
for every bottom slab, there needs to be 13 different ids for a different top slab.
that's a lot...
From what you're saying: 302875106592253 different ID's to be exact lol
My idea is maybe this can be like item frames. Multiple item frames can be placed on a single block, so apply the same idea to a slab! I don't if this 100% works, but it sounds like a decent idea to me!
My idea is maybe this can be like item frames. Multiple item frames can be placed on a single block, so apply the same idea to a slab! I don't if this 100% works, but it sounds like a decent idea to me!
Item frames are entities, not blocks.
Rollback Post to RevisionRollBack
My avatar is a texture from a small block game I made in Python. It's not very good and it probably won't work if you install it.
I'm very alone in my Minecraft worlds as I don't have a very good internet connection to run a server. If you're like me, you might be interested in my Posse mod suggestion.
I'm for this, but can I also include unique looks for double slabs of wood and other slab blocks. 2 wood slabs stacked on top of each other looks just like a regular wood block right now. I feel that it's a waste in potential when a double slab looks the same as a full block.
The Meaning of Life, the Universe, and Everything.
Join Date:
7/6/2017
Posts:
51
Member Details
This has been an idea that people have wanted probably since slabs were first implemented but, due to Notch not liking the idea, it didnt go through (because at the time Notch held more than half the company shares so he always had the final say). Now though, without Notch's somewhat closed-minded view, Mojang will hopefully consider it.
im not entirely sure how placing redstone or torches on bottom slabs would work (though it would be nice if it did work) because all i can think of is them floating above the block. But, as i like the concept of this ( though i dont know what any of that coding means) im going to say i support this idea : )
You just can't store 2 blocks worth of data into a single block of the 3D world matrix. That would show a clear lack of understanding of the basic data structures. For those wanting details on why, go back to the wiki showing the block data structures for the details. That'd be like trying to put 2 differently colored Easter Eggs into the same space in an Egg carton. A block is a block is a block and takes up the memory space of 1 block, no matter if it is displayed as a full block, is a slab "seemingly" occupying "only" half the space of a block, or is thin and transparent like a snow layer or a glass pane or even a flower. You have block ID + 4 data bits to work with, and that's it. No more, no less.
Having a different block ID for each possible slab combination would be needlessly exponentially explosive and screwy. Possible once Mojang removes the 256-blocks-ID internal limitation (remember that 4096 limit is to accomodate modders, but the game actually uses only 256 IDs max for its own blocks).
Compacting the data would sure occupy less space. However, to actually make use of the data, you'd have to uncompact it each time you'd want to do something, -anything-, on any block that needs something to be done with it, including just being displayed. Why do you think all the polygons are stored in a vector array inside a graphic card, instead of as "compacted data"? Speed! So what little you'd gain in memory space, you'd more than waste in CPU cycles. Pretty sure nobody would want to play a game running at 2 FPS. The only time compacting makes any kind of performance-wise sense is when loading and unloading chunks to the disk. Otherwise it's pure insanity, sacrificing 50 times the speed just to save half the space.
The only proper workable solution is to allocate more data bits in the block structure itself. However, that too would currently impact performance way too much (less that the compacting the data nonsense, though). But it will occur soonish after most of the already-bought-and-still-in-use computers in the world meet these requirements:
- Quad-core (with Minecraft changed to use multiple CPUs). Note that 2 cores wouldn't cut it as MC would need to have tons of code almost everywhere just to avoid ressource collisions between the multiple CPUS and processes, which slows things down somewhat. So any "real" gain would start to show up mainly at 3 or 4 CPUs. Memory access would still remain a stiff bottleneck anyway as 4 CPUS don't access the memory bandwidth four more times faster, and Minecraft isn't the kind of code that uses "mostly the low level caches".
- 64 bits and at least 8GB (or even better 16GB) RAM, so we can swap momory faster in the main data channel and have much more RAM for the game's RAM-hungry data structures (mainly, all the tons of loaded chunks constantly being processed each game tick).
Then yeah, it will be time to upgrade the code and double the amount data bits in the array.
But for now I prefer having Extreme Sight range (which requires about 4x times the RAM and CPU to handle than Far Sight Range) than having a main data structure that would "easily" support dual-slabs, but at about the same total performance as Extreme Sight Range is now without it.
Another way is to have a special type of block that isn't a tile entity, but refers to a submatrix, nearly similar really, but halfway between full-on tile entity, and a simple part-of-the-normal-3D-matrix block. I've seen the microblocks mod. Super nice and it works even better than what you want. Only problem is that, the more of these special blocks you have, the bigger the impact on performance. A couple hundreds of them? Ok, so far so good! Tens of thousands? Kaboom!!! And for a basic building block such as slabs, the kaboom state could be reached pretty fast on many multiplayer servers.
Basically, no matter which way you cut it, it would require a major rework AND have a big performance impact anyway.
Given that Mojang seems intent on slowly making the java version become a "sideline" version, I wouldn't get my hopes up too much.
Theoretically, but as I've displayed in a few different tests, Tile Entities do practically nothing to performance (65K tile entities cause barely a blip, and I've got a potato for a computer). The only notable increase I've seen has been in memory, and Minecraft uses very little anyway ("Extreme Sight" is far above average and is therefor sacrifice-able for such a result). All that making slabs a tile entity would do is tell the game to use a different set of textures for the block model there. Remember that slabs are static blocks that do nothing, so it doesn't need to tick as often.
Seriously, I think people tend to underestimate the strength of computers. "You can't render a polygon with more than three vertices!" Blender does it without a hitch. "You can't make a picture of infinite resolution!" The SVG format handles it pretty well. You can always find a way to implement something by thinking outside the box to find a more efficient solution.
I'm very curious about your test. How many actual tile entities were involved ? What's the setup? Desktop PC java version?
Check out from 2:00 to 2:12 --> "Dropping from 700 FPS down to only 30 FPS". That's with only 512 tile entities. Imagine what tens of thousands would do!
For that Youtube test, I'd have preferred it being done in a normal world (instead of in a "void" world), and at various client side sight ranges and various server size chunk load ranges. To see if the impact is more on the rendering size of things, and compare with the normal load of a normal world.
The video seems to show that the main performance hit is when the Tile entities actually come into view. I'd have also liked to compare Tile Entities performance hit in "in-sight" vs "out of sight but in loaded chunks" vs "completely unloaded / loading / unloading". Still, for the end user, it's the total FPS that really counts.
I agree item frames are definitely the worst offenders among the tile entities group, though, but still, check out the entire video if you want. But the other tiles entities, which are usually only at most 3 times "more CPU friendly" than Item Frames are, are still tons of times slower than normal blocks to process (with one exception).
A server typically loads 10 chunks radius around each player (160 blocks radius on the server side, even if player is set to Normal Sight Range on the client side). Assuming only the underground + ground sections have non-Air blocks, that's still 21x21 x 5 x 16x16x16 = 9 millions blocks loaded around each player. Not all are actually rendered, though, but they all get data-manipulated in the loaded chunks. Servers that up the distance to the full 16 chunks (to allow full "Extreme Sight Range") will increase that amount of loaded-chunks blocks to a whopping 23 millions blocks per player (assuming no two players are at the same place of course), but at a corresponding performance drop (approx 60% drop, basically 2.5 times more data means about 2.5 slower too - Yeah it's pretty linear for that).
That still doesn't compare that to having a mere 10 000 Tile Entities (when compared to those millions and millions of normal blocks) around and suddenly seeing the FPS go down the drain like a space rocket going full thrust downwards a bottomless pit.
Thus, Tile Entities are ok for "special"' blocks, but not ok for building blocks. For example we can easily see everybody on a server building a ton of nice houses for their "Spawn City" and suddenly jumping on the fact that they can now use only 1 block of thickness between the floors of their builds, yay! Placing up tens of thousands of these dual-slabs blocks in the process. Placing tile entities instead of simple blocks. Massively. Ho-ho.
In the video, there is one exception, for some weird reason, Anvils require a lot more of them around to "successfully" drop the FPS seriously. Still, each Anvil counts a lot more than a normal block, as you get a severe performance drop with "only" 16536 Anvils. But even if dual-slabs were somehow made to be some special Anvil Variant (somehow), Anvils aren't placed around in the thousands and thousands while building block such as dual slabs would definitely be, so yeah, lag would show up. A lot. Not on Day 1 of the server. But once Spawn City is built, yeah sure. A lot.
I agree that some people tend to greatly underestimate the strengths of computers.
But some people also tend to greatly overestimate the strength of computers, too, and that happens just as much at the first group.
That's just simple human nature.
I personally stand more or less on the fence. Despite 20 years of programming, for some stuff I still overestimate, while for other stuff I still underestimate. But I generally am good at calculating how much an an impact a code change might imply, even before the actual performance testers do their job. I eventually left programming because of the constant stress, not because I wasn't good at it lol.
Also, keep in mind, "called-a-lot" code in any game/program is the 1st part of the code to get optimization efforts put on it, and there comes a point of diminishing returns. In other words: those parts of the code of the Minecraft game, which has existed for years, are pretty well oiled already (unless you think Mojang staff have been complete morons for years - I sure don't). Maybe its not 100% perfect code, but it still surely is already much closer to the "max theoretical performance" than "low performance code".
You can take Fat Albert (newly drafted semi-junk code) and train him (optimize and tighten and clean up the code) to drastically increase his sprinting running performance, shaping him up a lot in the process. You can also take Usain Bolt (central core code that's been around for years and that has already been optimized a lot), and try to give him a special training (at this point, there is room only to either tweak something in the code, else you need to start over with completely different assumptions for everything, such as minimum hardware, etc. - basically not trying to improve your Usain Bolt anymore), but you'll end up probably improving his performance only by a fraction of a percent, at best. You might even make things worse than before.
Well, program code works a lot like that. Maybe "it's always possible to improve", but that doesn't mean each new improvement will be big. Au contraire. The first round of optimization is like reaching for the multiple big juicy and sugary red apples that are straight in your face on the lowest branch of the tree. The last round of optimization is more like reaching for the lone last apple in the tree, still tiny and green, and on the topmost flimsy branch at the very top of the super tall tree. And that not sweet at all too bitter apple has a couple worms in it, too. So, unless doing something radical, most of the time it's the opposite, past the few initial optimization cycles, applying more efforts to the same code usually just ends up wasting resources.
I've done enough "optimization work" on enough programs in my life to know that, once you "already cleaned up and fixed and optimized the code of the first "must send to the client ASAP" draft, even once, then most of the potential performance gains have been already been obtained. Clients are always happy to get their program ASAP. They are also happy when version 2 comes much speedier than version 1. And version 3 speedier than version 2. But around version 4 or 5, if it runs well enough, then they want more features, not more performance. So you rush the initial delivery, then cleanup and optimization comes later, but you are in no hurry to do all of it in version 2. Get paid three times to and make the client smile three times, instead of doing it right the first time, but have angry clients that complain of long delays and no boost in performance. Argh! Glad to have left all that behind me lol.
Anyway, then the next guy behind you does the same kind of work, but suddenly doesn't magically find a new way to make the code run another 8 times faster, like you did for version 2. In fact, the company already knows about the 8 fold performance increase in version 2 increase and limited the boost to only 2 times, so tha it's be easy to get more two-fold increase in versions 3 and 4. But no such luck in versions 5 and 6, the 5th and 6th guy in line will probably end up just saying "Any additionnal change we make now, can allow us to increase that thing you want by say 3%, but at the cost of losing 15% on everything else. Nothing is wrong with the code now, it works very well already, so let's not try to fix something that's not broken."
Personally, the only real valid future solution I can see for Dual-Slabs is upgrading the Chunk format a little bit:
Add (basically extending available block IDs from 256 to 4096 possible values for mods/modders) [4 bits]
Data [4 bits] <-- Here is what is so limiting!
BlockLight [4 bits]
SkyLight [4 bits]
TOTAL = currently 24 bits per block cell.
I'd simply go to a 32 bits block cell size, making the Data field have 12 bits instead of 4.
A Dual-Slab would then have enough data bits to specify both the bottom and top half material types directly, as a simple straight up block, avoiding the Tile Entity issue entirely. In addition to making it very simple to add tons of other new types or variants of blocks quite efficiently.
Plus, perfectly lining up the data cell size to 32 bits instead of 24 would allow speedup RAM and cache access even more. A bit less bit fields manipulation.
However, going from 24 to 32 bits per XYZ block cell would increase the required RAM (and the CPU handling of that RAM by 33% (32 is 8 over 24, thus 33% more than 24). Yeah a 33% performance impact would be be VERY noticeable, and the added possibilities would go way beyond mere dual slabs., but still a lot of players would be very angry that their FPS suddenly drops by 33%. But after a while it would calm down. But going straight to 64 bits per data cell, however, the code and the hardware base just aren't ready for that yet. Multi-Core Minecraft with new top of the line 4.5GHz Octo-Core 16GB RAM and 1 TB PCIx4 M2 SDD PCs? Yes. Chaching! Single-core current version of Java MC with already in use PCs in homes? Unfortunately no reasonable hope there.
Saying "there is always a way to do it!" is a little bit too optimistic for my tastes. Showing how is much more realistic. One could say I'm a pessimist, but a real pessimist again says no it's impossible without showing why he says that, while I detailed at length. The more I analyze the way the code works, the more what I see is "Realistically speaking, there is a performance wall, right there, based on those data structures ad the way they are handled, and it's not a bad way, too. It's even brilliant, in some aspects. And that guy comes shooting nerf-balls at that wall. what I see is that the balls just won't go through, no matter the firing angles are."
There's also the issue of tile entities not being pushable with pistons in the Java version of Minecraft. Something that can be fixed and added, but should be mentioned now that it hasn't yet.
I thought Mojang was already planning on fixing that? The pocket edition already can do this, which means it will likely be a feature to find its way to Java edition, so I find mentioning this pointless.
>New record for longest technical post 90% of readers won't understand<
I won't address everything, because frankly I'm not the most technically experienced out there and I don't want to spend an hour writing this post.
In the first few minutes I can already tell some differences between his setup and mine. I received no difference in fps by looking up or down, and his fps goes in the hundreds while mine goes up to 60 at best (during normal play it's in the 15-30 range). My test was also performed in 1.9, with Java 8 and Optifine. However, I decided to test it out again without Optifine in the latest version, and with more blocks (before I just did dirt, furnaces, and hoppers in a void world). I found that 1.12 is really intensive, which is why my fps hovers around 20, and tends to drop to 1fps sporadically, so I just gave the values during the peaks of performance.
No mods or resource packs, void world, peaceful mode, daylight cycle disabled, 1GB RAM
/fill 10 90 10 -10 110 -10 (9,261 blocks)
normal:21 fps, ~110 (11%) MB RAM used (RAM is difficult to measure as it keeps cycling, this is the average)
Test 1:Stone: 21 fps, ~110 RAM
Test 2:Furnace: 21 fps, ~120 RAM
Test 3:Enchanting Tables: 20 fps, ~115 RAM
Test 4:Brewing Stand: 15 fps, ~140 RAM
Test 5:Command Block: (Normal): 22 fps, ~130 RAM
Test 6:Anvil: 21 fps, ~130 RAM
Test 7:Hopper: 19 fps, ~130 RAM
No mods or resource packs, regular world (seed 6788867940597453299), normal mode, 1GB RAM
Normal: 24 fps, ~200 (20%) RAM (I'm not sure why I'm getting better fps but higher RAM usage)
Test 1:Stone: 27 fps, ~200 RAM
Test 2:Furnace: 24 fps, ~200 RAM
Test 3:Enchanting Tables: 23 fps, ~200 RAM
Test 4: Brewing Stand: 20 fps, ~210 RAM
Test 5:Command Block: 25 fps, ~210 RAM
Test 6:Anvil:20 fps, ~200 RAM
Test 7:Hopper: 19 fps ~210 RAM
I don't play or own a server, so I'm unable to test the multiplayer impact.
I didn't think of that when I made this. lol I should add that. Anyways, thanks for the support.
support
To resolve the issues, perhaps the tile where two slabs are placed is 'split' into two separate slabs, thereby preventing more block IDs from being used. However, only the tile where two slabs are placed would be split to prevent too many separate hitboxes and textures, which cause lag.
Thanks for the support!
anyway, it seems like a lot of possibilities but a major reprogramming, so i don't support it
There are 13 different slabs
for every bottom slab, there needs to be 13 different ids for a different top slab.
that's a lot...
Support.
"And so I go fast. Not because I want to, because no one else will."
-Sanic Hegehog
I don't really know how much reprogramming it would take for Mojang to do. But coming from a modding point of view, I can think of anywhere from 200-400 lines of code. Just guessing though.
From what you're saying: 302875106592253 different ID's to be exact lol
It would be awesome! Thanks!
My idea is maybe this can be like item frames. Multiple item frames can be placed on a single block, so apply the same idea to a slab! I don't if this 100% works, but it sounds like a decent idea to me!
Item frames are entities, not blocks.
My avatar is a texture from a small block game I made in Python. It's not very good and it probably won't work if you install it.
I'm very alone in my Minecraft worlds as I don't have a very good internet connection to run a server. If you're like me, you might be interested in my Posse mod suggestion.
I'm for this, but can I also include unique looks for double slabs of wood and other slab blocks. 2 wood slabs stacked on top of each other looks just like a regular wood block right now. I feel that it's a waste in potential when a double slab looks the same as a full block.
This has been an idea that people have wanted probably since slabs were first implemented but, due to Notch not liking the idea, it didnt go through (because at the time Notch held more than half the company shares so he always had the final say). Now though, without Notch's somewhat closed-minded view, Mojang will hopefully consider it.
im not entirely sure how placing redstone or torches on bottom slabs would work (though it would be nice if it did work) because all i can think of is them floating above the block. But, as i like the concept of this ( though i dont know what any of that coding means) im going to say i support this idea : )
Tile entities would be too slow.
You just can't store 2 blocks worth of data into a single block of the 3D world matrix. That would show a clear lack of understanding of the basic data structures. For those wanting details on why, go back to the wiki showing the block data structures for the details. That'd be like trying to put 2 differently colored Easter Eggs into the same space in an Egg carton. A block is a block is a block and takes up the memory space of 1 block, no matter if it is displayed as a full block, is a slab "seemingly" occupying "only" half the space of a block, or is thin and transparent like a snow layer or a glass pane or even a flower. You have block ID + 4 data bits to work with, and that's it. No more, no less.
Having a different block ID for each possible slab combination would be needlessly exponentially explosive and screwy. Possible once Mojang removes the 256-blocks-ID internal limitation (remember that 4096 limit is to accomodate modders, but the game actually uses only 256 IDs max for its own blocks).
Compacting the data would sure occupy less space. However, to actually make use of the data, you'd have to uncompact it each time you'd want to do something, -anything-, on any block that needs something to be done with it, including just being displayed. Why do you think all the polygons are stored in a vector array inside a graphic card, instead of as "compacted data"? Speed! So what little you'd gain in memory space, you'd more than waste in CPU cycles. Pretty sure nobody would want to play a game running at 2 FPS. The only time compacting makes any kind of performance-wise sense is when loading and unloading chunks to the disk. Otherwise it's pure insanity, sacrificing 50 times the speed just to save half the space.
The only proper workable solution is to allocate more data bits in the block structure itself. However, that too would currently impact performance way too much (less that the compacting the data nonsense, though). But it will occur soonish after most of the already-bought-and-still-in-use computers in the world meet these requirements:
- Quad-core (with Minecraft changed to use multiple CPUs). Note that 2 cores wouldn't cut it as MC would need to have tons of code almost everywhere just to avoid ressource collisions between the multiple CPUS and processes, which slows things down somewhat. So any "real" gain would start to show up mainly at 3 or 4 CPUs. Memory access would still remain a stiff bottleneck anyway as 4 CPUS don't access the memory bandwidth four more times faster, and Minecraft isn't the kind of code that uses "mostly the low level caches".
- 64 bits and at least 8GB (or even better 16GB) RAM, so we can swap momory faster in the main data channel and have much more RAM for the game's RAM-hungry data structures (mainly, all the tons of loaded chunks constantly being processed each game tick).
Then yeah, it will be time to upgrade the code and double the amount data bits in the array.
But for now I prefer having Extreme Sight range (which requires about 4x times the RAM and CPU to handle than Far Sight Range) than having a main data structure that would "easily" support dual-slabs, but at about the same total performance as Extreme Sight Range is now without it.
Another way is to have a special type of block that isn't a tile entity, but refers to a submatrix, nearly similar really, but halfway between full-on tile entity, and a simple part-of-the-normal-3D-matrix block. I've seen the microblocks mod. Super nice and it works even better than what you want. Only problem is that, the more of these special blocks you have, the bigger the impact on performance. A couple hundreds of them? Ok, so far so good! Tens of thousands? Kaboom!!! And for a basic building block such as slabs, the kaboom state could be reached pretty fast on many multiplayer servers.
Basically, no matter which way you cut it, it would require a major rework AND have a big performance impact anyway.
Given that Mojang seems intent on slowly making the java version become a "sideline" version, I wouldn't get my hopes up too much.
People, please stay on-topic. This thread is for discussing the OPs idea, it is not for complaining about Mojang.
- sunperp
Theoretically, but as I've displayed in a few different tests, Tile Entities do practically nothing to performance (65K tile entities cause barely a blip, and I've got a potato for a computer). The only notable increase I've seen has been in memory, and Minecraft uses very little anyway ("Extreme Sight" is far above average and is therefor sacrifice-able for such a result). All that making slabs a tile entity would do is tell the game to use a different set of textures for the block model there. Remember that slabs are static blocks that do nothing, so it doesn't need to tick as often.
Seriously, I think people tend to underestimate the strength of computers. "You can't render a polygon with more than three vertices!" Blender does it without a hitch. "You can't make a picture of infinite resolution!" The SVG format handles it pretty well. You can always find a way to implement something by thinking outside the box to find a more efficient solution.
Want to see my suggestions? Here they are!
I am also known as GameWyrm or GameWyrm97. You can also find me at snapshotmc.com
I'm very curious about your test. How many actual tile entities were involved ? What's the setup? Desktop PC java version?
Check out from 2:00 to 2:12 --> "Dropping from 700 FPS down to only 30 FPS". That's with only 512 tile entities. Imagine what tens of thousands would do!
For that Youtube test, I'd have preferred it being done in a normal world (instead of in a "void" world), and at various client side sight ranges and various server size chunk load ranges. To see if the impact is more on the rendering size of things, and compare with the normal load of a normal world.
The video seems to show that the main performance hit is when the Tile entities actually come into view. I'd have also liked to compare Tile Entities performance hit in "in-sight" vs "out of sight but in loaded chunks" vs "completely unloaded / loading / unloading". Still, for the end user, it's the total FPS that really counts.
I agree item frames are definitely the worst offenders among the tile entities group, though, but still, check out the entire video if you want. But the other tiles entities, which are usually only at most 3 times "more CPU friendly" than Item Frames are, are still tons of times slower than normal blocks to process (with one exception).
A server typically loads 10 chunks radius around each player (160 blocks radius on the server side, even if player is set to Normal Sight Range on the client side). Assuming only the underground + ground sections have non-Air blocks, that's still 21x21 x 5 x 16x16x16 = 9 millions blocks loaded around each player. Not all are actually rendered, though, but they all get data-manipulated in the loaded chunks. Servers that up the distance to the full 16 chunks (to allow full "Extreme Sight Range") will increase that amount of loaded-chunks blocks to a whopping 23 millions blocks per player (assuming no two players are at the same place of course), but at a corresponding performance drop (approx 60% drop, basically 2.5 times more data means about 2.5 slower too - Yeah it's pretty linear for that).
That still doesn't compare that to having a mere 10 000 Tile Entities (when compared to those millions and millions of normal blocks) around and suddenly seeing the FPS go down the drain like a space rocket going full thrust downwards a bottomless pit.
Thus, Tile Entities are ok for "special"' blocks, but not ok for building blocks. For example we can easily see everybody on a server building a ton of nice houses for their "Spawn City" and suddenly jumping on the fact that they can now use only 1 block of thickness between the floors of their builds, yay! Placing up tens of thousands of these dual-slabs blocks in the process. Placing tile entities instead of simple blocks. Massively. Ho-ho.
In the video, there is one exception, for some weird reason, Anvils require a lot more of them around to "successfully" drop the FPS seriously. Still, each Anvil counts a lot more than a normal block, as you get a severe performance drop with "only" 16536 Anvils. But even if dual-slabs were somehow made to be some special Anvil Variant (somehow), Anvils aren't placed around in the thousands and thousands while building block such as dual slabs would definitely be, so yeah, lag would show up. A lot. Not on Day 1 of the server. But once Spawn City is built, yeah sure. A lot.
I agree that some people tend to greatly underestimate the strengths of computers.
But some people also tend to greatly overestimate the strength of computers, too, and that happens just as much at the first group.
That's just simple human nature.
I personally stand more or less on the fence. Despite 20 years of programming, for some stuff I still overestimate, while for other stuff I still underestimate. But I generally am good at calculating how much an an impact a code change might imply, even before the actual performance testers do their job. I eventually left programming because of the constant stress, not because I wasn't good at it lol.
Also, keep in mind, "called-a-lot" code in any game/program is the 1st part of the code to get optimization efforts put on it, and there comes a point of diminishing returns. In other words: those parts of the code of the Minecraft game, which has existed for years, are pretty well oiled already (unless you think Mojang staff have been complete morons for years - I sure don't). Maybe its not 100% perfect code, but it still surely is already much closer to the "max theoretical performance" than "low performance code".
You can take Fat Albert (newly drafted semi-junk code) and train him (optimize and tighten and clean up the code) to drastically increase his sprinting running performance, shaping him up a lot in the process. You can also take Usain Bolt (central core code that's been around for years and that has already been optimized a lot), and try to give him a special training (at this point, there is room only to either tweak something in the code, else you need to start over with completely different assumptions for everything, such as minimum hardware, etc. - basically not trying to improve your Usain Bolt anymore), but you'll end up probably improving his performance only by a fraction of a percent, at best. You might even make things worse than before.
Well, program code works a lot like that. Maybe "it's always possible to improve", but that doesn't mean each new improvement will be big. Au contraire. The first round of optimization is like reaching for the multiple big juicy and sugary red apples that are straight in your face on the lowest branch of the tree. The last round of optimization is more like reaching for the lone last apple in the tree, still tiny and green, and on the topmost flimsy branch at the very top of the super tall tree. And that not sweet at all too bitter apple has a couple worms in it, too. So, unless doing something radical, most of the time it's the opposite, past the few initial optimization cycles, applying more efforts to the same code usually just ends up wasting resources.
I've done enough "optimization work" on enough programs in my life to know that, once you "already cleaned up and fixed and optimized the code of the first "must send to the client ASAP" draft, even once, then most of the potential performance gains have been already been obtained. Clients are always happy to get their program ASAP. They are also happy when version 2 comes much speedier than version 1. And version 3 speedier than version 2. But around version 4 or 5, if it runs well enough, then they want more features, not more performance. So you rush the initial delivery, then cleanup and optimization comes later, but you are in no hurry to do all of it in version 2. Get paid three times to and make the client smile three times, instead of doing it right the first time, but have angry clients that complain of long delays and no boost in performance. Argh! Glad to have left all that behind me lol.
Anyway, then the next guy behind you does the same kind of work, but suddenly doesn't magically find a new way to make the code run another 8 times faster, like you did for version 2. In fact, the company already knows about the 8 fold performance increase in version 2 increase and limited the boost to only 2 times, so tha it's be easy to get more two-fold increase in versions 3 and 4. But no such luck in versions 5 and 6, the 5th and 6th guy in line will probably end up just saying "Any additionnal change we make now, can allow us to increase that thing you want by say 3%, but at the cost of losing 15% on everything else. Nothing is wrong with the code now, it works very well already, so let's not try to fix something that's not broken."
Personally, the only real valid future solution I can see for Dual-Slabs is upgrading the Chunk format a little bit:
http://minecraft.gamepedia.com/Chunk_format#NBT_structure
Per block:
ID [8 bits]
Add (basically extending available block IDs from 256 to 4096 possible values for mods/modders) [4 bits]
Data [4 bits] <-- Here is what is so limiting!
BlockLight [4 bits]
SkyLight [4 bits]
TOTAL = currently 24 bits per block cell.
I'd simply go to a 32 bits block cell size, making the Data field have 12 bits instead of 4.
A Dual-Slab would then have enough data bits to specify both the bottom and top half material types directly, as a simple straight up block, avoiding the Tile Entity issue entirely. In addition to making it very simple to add tons of other new types or variants of blocks quite efficiently.
Plus, perfectly lining up the data cell size to 32 bits instead of 24 would allow speedup RAM and cache access even more. A bit less bit fields manipulation.
However, going from 24 to 32 bits per XYZ block cell would increase the required RAM (and the CPU handling of that RAM by 33% (32 is 8 over 24, thus 33% more than 24). Yeah a 33% performance impact would be be VERY noticeable, and the added possibilities would go way beyond mere dual slabs., but still a lot of players would be very angry that their FPS suddenly drops by 33%. But after a while it would calm down. But going straight to 64 bits per data cell, however, the code and the hardware base just aren't ready for that yet. Multi-Core Minecraft with new top of the line 4.5GHz Octo-Core 16GB RAM and 1 TB PCIx4 M2 SDD PCs? Yes. Chaching! Single-core current version of Java MC with already in use PCs in homes? Unfortunately no reasonable hope there.
Saying "there is always a way to do it!" is a little bit too optimistic for my tastes. Showing how is much more realistic. One could say I'm a pessimist, but a real pessimist again says no it's impossible without showing why he says that, while I detailed at length. The more I analyze the way the code works, the more what I see is "Realistically speaking, there is a performance wall, right there, based on those data structures ad the way they are handled, and it's not a bad way, too. It's even brilliant, in some aspects. And that guy comes shooting nerf-balls at that wall. what I see is that the balls just won't go through, no matter the firing angles are."
So, yeah, I'm very curious to see your test!
I thought Mojang was already planning on fixing that? The pocket edition already can do this, which means it will likely be a feature to find its way to Java edition, so I find mentioning this pointless.
I won't address everything, because frankly I'm not the most technically experienced out there and I don't want to spend an hour writing this post.
In the first few minutes I can already tell some differences between his setup and mine. I received no difference in fps by looking up or down, and his fps goes in the hundreds while mine goes up to 60 at best (during normal play it's in the 15-30 range). My test was also performed in 1.9, with Java 8 and Optifine. However, I decided to test it out again without Optifine in the latest version, and with more blocks (before I just did dirt, furnaces, and hoppers in a void world). I found that 1.12 is really intensive, which is why my fps hovers around 20, and tends to drop to 1fps sporadically, so I just gave the values during the peaks of performance.
No mods or resource packs, void world, peaceful mode, daylight cycle disabled, 1GB RAM
/fill 10 90 10 -10 110 -10 (9,261 blocks)
normal:21 fps, ~110 (11%) MB RAM used (RAM is difficult to measure as it keeps cycling, this is the average)
Test 1:Stone: 21 fps, ~110 RAM
Test 2:Furnace: 21 fps, ~120 RAM
Test 3:Enchanting Tables: 20 fps, ~115 RAM
Test 4:Brewing Stand: 15 fps, ~140 RAM
Test 5:Command Block: (Normal): 22 fps, ~130 RAM
Test 6:Anvil: 21 fps, ~130 RAM
Test 7:Hopper: 19 fps, ~130 RAM
No mods or resource packs, regular world (seed 6788867940597453299), normal mode, 1GB RAM
Normal: 24 fps, ~200 (20%) RAM (I'm not sure why I'm getting better fps but higher RAM usage)
Test 1:Stone: 27 fps, ~200 RAM
Test 2:Furnace: 24 fps, ~200 RAM
Test 3:Enchanting Tables: 23 fps, ~200 RAM
Test 4: Brewing Stand: 20 fps, ~210 RAM
Test 5:Command Block: 25 fps, ~210 RAM
Test 6:Anvil:20 fps, ~200 RAM
Test 7:Hopper: 19 fps ~210 RAM
I don't play or own a server, so I'm unable to test the multiplayer impact.
Want to see my suggestions? Here they are!
I am also known as GameWyrm or GameWyrm97. You can also find me at snapshotmc.com