(Check out my ItemSprite API! This will remove the problems with large numbers of items with a very simple method! Here's the link: http://goo.gl/EugJ1 )
Important!
I suggest only using this method on blocks that are NOT found in the world as often as something like dirt, stone, grass, or anything else that has many blocks that are rendered in abundance, as this may cause minor to severe lag depending on the quantity. About 3 times a second, in PremiumWood, the premwood.png (texture sheet) is binded, and then the normal terrain.png is rebinded. A test in NetherCraft revealed this issue, as having simply the Netherdirt render using this method caused my fps to drop by about 30. You have been warned!
Lastly, this method has not been tested when using 3 or more mods that all use this method. If anyone would like to try this out, you may install PremiumWood, BuildCraft, and Connected Textures Mod, then place a large amount of a block from each mod and see how you're fps is doing. Please PM me if you find anything important or significant about this combination. Thank you!
It is a very simple task to create a block without using ModLoader's AddOverride method. You can override two methods found in BaseMod: RenderInvBlock, and RenderWorldBlock. You can use these methods to 'bind' a new texture that is similar to the existing terrain.png file. Some large mods have used this same method: PremiumWood (made by me), Connected Textures Mod (CTM for short, made by Morpheus(?)) and BuildCraft (by SpaceToad). This tutorial will show you how.
Prerequisites
1. Understand Java
2. Understand how to create mods for Minecraft
3. Use MCP (I will make a tutorial for non-MCP users if requested enough)
Getting Started
First, simply open up your 'mod_YourMod' file that you've been working on.
You'll want to insert this code somewhere in this file:
Above, you need to ensure that you change all strings of "/yourDir/terrain-type-file.png" to your image file (image must be 256x256 for standard graphics). Also, this method of rendering will not work for custom block models unless you change all instances of 'RenderBlocks.renderStandardBlock' to your rendering method (or replace these lines with your rendering code). You can also set up additional variables that will call a different method from RenderBlocks. For example, in PremiumWood, doors are rendered using this method. A second renderID variable is created, then in RenderWorldBlock, an 'if' statement is used to check the renderID of a block and RenderBlocks.renderBlockDoor is called instead. This can be done with any blocks, but certain things may need changing if this is done. Hopefully you can figure it out yourself.
You will also need to declare the variable 'renderID' somewhere.
The above code will return an integer that will be used in the 'getRenderType()' method of your block file.
And, of course, don't forget to initialize your integer first:
public static int renderID;
Next, you need to be sure your block file will use this rendering integer. Inside your block class file, you'll want 'getRenderType()' to return your custom render ID, which will be 'mod_YourMod.renderID'.
Last, but not least, you need to import net.minecraft.client.Minecraft and org.lwjgl.opengl.GL11 to your mod_YourMod class file.
That's everything! Hope this helps!
If you feel I've left out some important information, be sure to post a reply or PM me. Thanks!
So we could add 256 custom block textures without using a single terrain sprite? Do we set the texture ID as if we used the normal terrain.png? (i.e. 0 would be upper-left of our custom terrain image.) Is there anything to be aware of when using HD textures, or will it just use the low-res if a higher res is not found? Can a hi-res version be included in a texture pack? Can this work for gui/items.png?
So we could add 256 custom block textures without using a single terrain sprite? Do we set the texture ID as if we used the normal terrain.png? (i.e. 0 would be upper-left of our custom terrain image.) Is there anything to be aware of when using HD textures, or will it just use the low-res if a higher res is not found? Can a hi-res version be included in a texture pack? Can this work for gui/items.png?
Thanks a bunch!
Lots of questions, lol. 1st questions, yes. 2, correct again. 3, I'm not sure, nor have I tested it. I don't normally do anything with HD textures. It probably will just use low res if high res isn't found, and it probably can use high res. 4, Nope. For items, I suggest taking a look at my 'ItemSprite API'. It has a very simple, and rather quick method to convert items to use an items.png-type file. I will post a link to it on the main post.
And you're welcome! =D
I've already been using custom renderers like crazy, so I'm surprised the above hadn't already occurred to me (I just had to skim it over and immediately got what you were saying), but your post just clued me into how to solve a whack of incompatibility problems with my mod (Better Than Wolves).
The funny part is that I was just thinking the other day that I could remap to items.png during block rendering to save on some terrain indices, but I totally brain-farted in not realizing I could just remap to an entirely separate file :smile.gif:
It seems to get the texture from terrain.png for the particles when breaking blocks. This means that if my block's texture is in the second spot in my custom terrain.png, the particles will use the stone texture.
It seems to get the texture from terrain.png for the particles when breaking blocks. This means that if my block's texture is in the second spot in my custom terrain.png, the particles will use the stone texture.
That's not a bad trade off actually. You can assign a normal terrain.png index in blockIndexInTexture for the particles (since they are too small to be really noticeable as to what's the precise texture anyways), then override to each of your own textures for the actual block with:
getBlockTexture()
and
getBlockTextureFromSide()
You really don't need to use blockIndexInTexture for anything other than assigning what texture you want on the particles.
That's not a bad trade off actually. You can assign a normal terrain.png index in blockIndexInTexture for the particles (since they are too small to be really noticeable as to what's the precise texture anyways), then override to each of your own textures for the actual block with:
getBlockTexture()
and
getBlockTextureFromSide()
You really don't need to use blockIndexInTexture for anything other than assigning what texture you want on the particles.
I thought about that at first, but EntityDiggingFX doesn't get the blockIndexInTexture, it calls getBlockTextureFromSideAndMetadata(). You're not wrong in saying that it's not a bad trade off though.
I thought about that at first, but EntityDiggingFX doesn't get the blockIndexInTexture, it calls getBlockTextureFromSideAndMetadata(). You're not wrong in saying that it's not a bad trade off though.
Huh. Well, you can definitely get around that by manually assigning texture indices in your rendering routines.
It is getting rather convoluted if you have to do so however :\
I understand nothing in the main post but "mods no more use terrain sprites" no more of that annoying message, and no more people having to right custom renders, which the redpowder mod runs on (288 textures total) from eloram, thats amazing that you can have all those textures and not use a single sprite....
WHY DID SOMEONE NOT DO THIS SOONER?... so many huge mods such as industrailcraft, and better than wolves (which i don't like becuase it modifies so many base clases, i usually just delete the ones i don't deem neccesary.. but fd.class is needed for the crank, and everything edits it..
Wow man. Your post is so full of inaccuracies about my mod I wouldn't even know where to begin in responding to that. I don't think you made a single true statement within it.
------------
Anyways, I'd love to hear what the OP has to say about the problems associated with the particles. I'm *hoping* that there may be something we overlooked in our discussions yesterday that might make this a little easier to handle since he has already used this idea extensively in his own mod.
Wow man. Your post is so full of inaccuracies about my mod I wouldn't even know where to begin in responding to that. I don't think you made a single true statement within it.
------------
Anyways, I'd love to hear what the OP has to say about the problems associated with the particles. I'm *hoping* that there may be something we overlooked in our discussions yesterday that might make this a little easier to handle since he has already used this idea extensively in his own mod.
The only workarounds I've found is to modify either EntityDiggingFX, or EffectRenderer. Neither of these options is a practical long term solution.
The only workarounds I've found is to modify either EntityDiggingFX, or EffectRenderer. Neither of these options is a practical long term solution.
The solution I'm about to attempt is to create my own versions of getBlockTexture(), and related functions which I will use in my custom rendering routines.
I already have a dedicated interface for all my mod blocks, so I'll just insert said routines (say something like FCGetBlockTexture() ) into said interface, and call it from my custom block-rendering code.
That way, any other portions of the code that calls the regular getBlockTexture() series of functions will just get blockIndexInTexture returned to them. As per our discussion yesterday, I'll just assign whatever vanilla-texture index I want for the particles to blockIndexInTexture.
I'll let you know how it goes in a couple of hours and post sample code if I get it working right.
The solution I'm about to attempt is to create my own versions of getBlockTexture(), and related functions which I will use in my custom rendering routines.
I already have a dedicated interface for all my mod blocks, so I'll just insert said routines (say something like FCGetBlockTexture() ) into said interface, and call it from my custom block-rendering code.
That way, any other portions of the code that calls the regular getBlockTexture() series of functions will just get blockIndexInTexture returned to them. As per our discussion yesterday, I'll just assign whatever vanilla-texture index I want for the particles to blockIndexInTexture.
I'll let you know how it goes in a couple of hours and post sample code if I get it working right.
Hmmm, first test of this appears to work. I'll need to test it further to see if it introduces any new problems.
In my block code, I override getBlockTexture()...
public int getBlockTexture(IBlockAccess iblockaccess, int i, int j, int k, int l)
{
return getBlockTextureFromSideAndMetadata2/*Note the 2*/(l, iblockaccess.getBlockMetadata(i, j, k));
}
I've renamed my getBlockTextureFromSideAndMetadata() method and call that instead. After, I placed a replacement getBlockTextureFromSideAndMetadata() method into my code and return the texture of my choice from the default terrain.png
public int getBlockTextureFromSideAndMetadata(int i, int j)
{
return 180;
}
Hmmm, first test of this appears to work. I'll need to test it further to see if it introduces any new problems.
In my block code, I override getBlockTexture()...
public int getBlockTexture(IBlockAccess iblockaccess, int i, int j, int k, int l)
{
return getBlockTextureFromSideAndMetadata2/*Note the 2*/(l, iblockaccess.getBlockMetadata(i, j, k));
}
I've renamed my getBlockTextureFromSideAndMetadata() method and call that instead. After, I placed a replacement getBlockTextureFromSideAndMetadata() method into my code and return the texture of my choice from the default terrain.png
public int getBlockTextureFromSideAndMetadata(int i, int j)
{
return 180;
}
Ah, I see. So you just bypass the normal call hierarchy. Make total sense and is much simpler than the method I was thinking of.
Nice thinking man! Glad I hadn't started in on this yet :smile.gif:
It was you who gave me the idea, it was so simple yet it blew my mind.
Hopefully this information makes it's way to the OP sometime soon.
Hehe...perhaps, but your method of going about it was MUCH simpler than what I was planning. It involved writing up an entirely new custom renderer for the world block so that I could manually insert the textures on each face.
Anyways, glad we seem to be sorting through the details collaboratively
The RenderInvBlock() method in your mod_ class will also need to be changed to point to your new getBlockTextureFromSideAndMetadata() method when rendering each side of your block. I'm sure you would have figured that out but I thought you might like to know beforehand.
(Check out my ItemSprite API! This will remove the problems with large numbers of items with a very simple method! Here's the link: http://goo.gl/EugJ1 )
Important!
I suggest only using this method on blocks that are NOT found in the world as often as something like dirt, stone, grass, or anything else that has many blocks that are rendered in abundance, as this may cause minor to severe lag depending on the quantity. About 3 times a second, in PremiumWood, the premwood.png (texture sheet) is binded, and then the normal terrain.png is rebinded. A test in NetherCraft revealed this issue, as having simply the Netherdirt render using this method caused my fps to drop by about 30. You have been warned!
Lastly, this method has not been tested when using 3 or more mods that all use this method. If anyone would like to try this out, you may install PremiumWood, BuildCraft, and Connected Textures Mod, then place a large amount of a block from each mod and see how you're fps is doing. Please PM me if you find anything important or significant about this combination. Thank you!
It is a very simple task to create a block without using ModLoader's AddOverride method. You can override two methods found in BaseMod: RenderInvBlock, and RenderWorldBlock. You can use these methods to 'bind' a new texture that is similar to the existing terrain.png file. Some large mods have used this same method: PremiumWood (made by me), Connected Textures Mod (CTM for short, made by Morpheus(?)) and BuildCraft (by SpaceToad). This tutorial will show you how.
Prerequisites
1. Understand Java
2. Understand how to create mods for Minecraft
3. Use MCP (I will make a tutorial for non-MCP users if requested enough)
Getting Started
First, simply open up your 'mod_YourMod' file that you've been working on.
You'll want to insert this code somewhere in this file:
Above, you need to ensure that you change all strings of "/yourDir/terrain-type-file.png" to your image file (image must be 256x256 for standard graphics). Also, this method of rendering will not work for custom block models unless you change all instances of 'RenderBlocks.renderStandardBlock' to your rendering method (or replace these lines with your rendering code). You can also set up additional variables that will call a different method from RenderBlocks. For example, in PremiumWood, doors are rendered using this method. A second renderID variable is created, then in RenderWorldBlock, an 'if' statement is used to check the renderID of a block and RenderBlocks.renderBlockDoor is called instead. This can be done with any blocks, but certain things may need changing if this is done. Hopefully you can figure it out yourself.
You will also need to declare the variable 'renderID' somewhere.
The above code will return an integer that will be used in the 'getRenderType()' method of your block file.
And, of course, don't forget to initialize your integer first:
Next, you need to be sure your block file will use this rendering integer. Inside your block class file, you'll want 'getRenderType()' to return your custom render ID, which will be 'mod_YourMod.renderID'.
Last, but not least, you need to import net.minecraft.client.Minecraft and org.lwjgl.opengl.GL11 to your mod_YourMod class file.
That's everything! Hope this helps!
If you feel I've left out some important information, be sure to post a reply or PM me. Thanks!
Thanks a bunch!
Lots of questions, lol. 1st questions, yes. 2, correct again. 3, I'm not sure, nor have I tested it. I don't normally do anything with HD textures. It probably will just use low res if high res isn't found, and it probably can use high res. 4, Nope. For items, I suggest taking a look at my 'ItemSprite API'. It has a very simple, and rather quick method to convert items to use an items.png-type file. I will post a link to it on the main post.
And you're welcome! =D
I've already been using custom renderers like crazy, so I'm surprised the above hadn't already occurred to me (I just had to skim it over and immediately got what you were saying), but your post just clued me into how to solve a whack of incompatibility problems with my mod (Better Than Wolves).
The funny part is that I was just thinking the other day that I could remap to items.png during block rendering to save on some terrain indices, but I totally brain-farted in not realizing I could just remap to an entirely separate file :smile.gif:
So thanks a bunch man. Very cool post.
Thanks man, awesome post. I'm surprised it hasn't been voted up yet. *clicks*
Good point. I always forget to vote up
*votes up*
=)
That's not a bad trade off actually. You can assign a normal terrain.png index in blockIndexInTexture for the particles (since they are too small to be really noticeable as to what's the precise texture anyways), then override to each of your own textures for the actual block with:
getBlockTexture()
and
getBlockTextureFromSide()
You really don't need to use blockIndexInTexture for anything other than assigning what texture you want on the particles.
I thought about that at first, but EntityDiggingFX doesn't get the blockIndexInTexture, it calls getBlockTextureFromSideAndMetadata(). You're not wrong in saying that it's not a bad trade off though.
Huh. Well, you can definitely get around that by manually assigning texture indices in your rendering routines.
It is getting rather convoluted if you have to do so however :\
Wow man. Your post is so full of inaccuracies about my mod I wouldn't even know where to begin in responding to that. I don't think you made a single true statement within it.
------------
Anyways, I'd love to hear what the OP has to say about the problems associated with the particles. I'm *hoping* that there may be something we overlooked in our discussions yesterday that might make this a little easier to handle since he has already used this idea extensively in his own mod.
The only workarounds I've found is to modify either EntityDiggingFX, or EffectRenderer. Neither of these options is a practical long term solution.
The solution I'm about to attempt is to create my own versions of getBlockTexture(), and related functions which I will use in my custom rendering routines.
I already have a dedicated interface for all my mod blocks, so I'll just insert said routines (say something like FCGetBlockTexture() ) into said interface, and call it from my custom block-rendering code.
That way, any other portions of the code that calls the regular getBlockTexture() series of functions will just get blockIndexInTexture returned to them. As per our discussion yesterday, I'll just assign whatever vanilla-texture index I want for the particles to blockIndexInTexture.
I'll let you know how it goes in a couple of hours and post sample code if I get it working right.
Hmmm, first test of this appears to work. I'll need to test it further to see if it introduces any new problems.
In my block code, I override getBlockTexture()...
I've renamed my getBlockTextureFromSideAndMetadata() method and call that instead. After, I placed a replacement getBlockTextureFromSideAndMetadata() method into my code and return the texture of my choice from the default terrain.png
Ah, I see. So you just bypass the normal call hierarchy. Make total sense and is much simpler than the method I was thinking of.
Nice thinking man! Glad I hadn't started in on this yet :smile.gif:
It was you who gave me the idea, it was so simple yet it blew my mind.
Hopefully this information makes its way to the OP sometime soon.
Hehe...perhaps, but your method of going about it was MUCH simpler than what I was planning. It involved writing up an entirely new custom renderer for the world block so that I could manually insert the textures on each face.
Anyways, glad we seem to be sorting through the details collaboratively
The RenderInvBlock() method in your mod_ class will also need to be changed to point to your new getBlockTextureFromSideAndMetadata() method when rendering each side of your block. I'm sure you would have figured that out but I thought you might like to know beforehand.