[RESOLVED] Alternative to TileEntity for chameleon Block?

[coolAlias]

EDIT: Due to coding for both 1.6.4 and 1.7.2, I simply switched back to a metadata-based block for the majority of my multi-texture blocks, and created a new but basically identical block that uses a tile entity for map-makers and creative users. This maintains high performance during world generation while still giving the option of a flexible tile entity for anyone who needs it, with the added benefit that it is extremely easy to code.

 

Of course, this just foists the burden upon map-makers not to use too many tile entity blocks in their designs...

 

Thanks TGG and diesieben07 for your suggestions. One of these days I'll have to delve into Trove so I can fix the problem for real

-------------------------------------------------------------------------------------------------------

 

Hey all,

 

I finally got around to making my dungeon blocks able to take on nearly any texture using a simple, non-updating TileEntity; however, as I'm sure most of you can guess, generating significant numbers of these blocks causes very noticeable lag when loading chunks, old or new.

 

Previously, my block used metadata to determine which texture to return, and one bit for whether it could be broken or not, giving me up to eight textures as well as having excellent run-time performance. Is there any alternative to a TileEntity for a block that can have a bunch of different textures?

 

I can think of two, but both are less than ideal:

 

1. Use getIcon(IBlockAccess, x, y, z, side) to use a neighboring texture, but this prevents me from choosing which texture I want and could get funky when each block is trying to get the texture from its neighbor, that in turn is trying to get its texture from the next neighbor and so on.

 

2. Have multiple metadata based blocks, each providing 8 textures, and a CreativeTab filled with my own versions of basically every regular vanilla block. Not very elegant.

 

Barring any better suggestions, I may have to resort to a single meta-based block for my dungeons, and a tile entity-based block for the CreativeTab / people who want to mess around with it.

 

Has anyone figured out a more performance-friendly way to accomplish this?

[TheGreyGhost]

Hi

 

Depending on the number of textures you need, I'd suggest the best idea is just taking up more blockIDs.  With (say) 8 metadata and 32 block IDs, you could have 256 different textures which is probably enough?  You could perhaps get around the creative tab problem by just having a single chameleon block on the tab, which changes its own blockID when it gets placed.

 

-TGG

[coolAlias]

Hi

 

Depending on the number of textures you need, I'd suggest the best idea is just taking up more blockIDs.  With (say) 8 metadata and 32 block IDs, you could have 256 different textures which is probably enough?  You could perhaps get around the creative tab problem by just having a single chameleon block on the tab, which changes its own blockID when it gets placed.

 

-TGG

Thanks for the reply.

 

The idea behind the block is that the player can right-click on pretty much any standard block and have the block assume that texture, but once placed the texture need never change. What I did for my metadata-based block is to have an array of texture names and use the metadata as the index, making it easy to return the correct icon from the Block methods. While I could theoretically do the same for 256+ blocks, that would be quite cumbersome.

 

For now, I plan on following through with my final idea of using metadata blocks for my structure generation, since I only need 8 textures for those blocks, and leave the tile-entity based block for map-makers with a warning not to use it excessively. The main problem is simply the sheer number of blocks I am generating - if you consider that even a hollowed out 5x5x5 cube requires nearly 100 blocks (98, to be exact), and I am generating roughly 4-6 of those rooms per chunk on my default settings, that's roughly 32,000 added tile entities in just an 8x8 chunk area (500 per chunk x 64 chunks). Best to avoid that

 

Anyway, thanks again. I will be switching back to metadata for the most part, though I am still open to other suggestions.

 

Cheers,

coolAlias

[coolAlias]

You can make your own data structure.

Assuming you are using 1.7 you have access to Trove, which allows primitive types to be used in maps without boxing.

Furthermore you can encode an entire x, y, z location into a single long. How? X and Z coordinates range from -300000 to +300000 which means they need at most 26 bits in binary. Y coordinate ranges from 0 to 255, which means it needs 8 bits. Combine that and you get 26 + 26 + 8 = 60 bits. A long has 64 bits so that works perfectly. Assuming you need an int to store the fake block you'd use a

TLongIntHashMap

, which maps long values to ints.

Now you still need a way of associating that Map with a World, but I'll leave that up to you.

That is probably as efficient as you can get

You are just too damn smart

 

I'm actually coding the same thing for both 1.6.4 and 1.7.2 (for some masochistic reason I've been keeping both versions of my mod updated...), but otherwise this sounds like an extremely viable and efficient solution. Thanks for this!