I'm building a mod, and a block of mine will be changing textures when onBlockActivated() using dye to alter its color... and i have read the crap out of the infinite terrain texture on the wiki, as well as a bunch of forum posts about it, but nowhere does it tell you how exactly to call the index of it...
and just for the record i will not be using a TileEntity... they are Blocks and will stay that way unless i am forced to use a TE... as i do not want the increased lag caused by TE's....
2) Do you realize that the tutorial is about an ancient version? Half of the terminology I don't event understand. Is it talking about the sprite sheets (referred to as the "block atlas" or "item atlas" in recent versions)?
from what i have come to understand mapped textures only apply to GUI's and TE's.... but yes its the same principle only for basic blocks and items
Fair enough. Infinite Texture is a bit of a silly term, the generic gaming term is called a "sprite sheet" - one physical texture, but can be split up and different areas are "mapped" to be drawn at/by different areas/things.
I see what you mean though, about Blocks and Items. In basic texture use here we're restricted to "registerBlockIcons", and have to deal with IIcon type - and the IIcon datatype already has the uv map embedded within, as returned by the item/block atlas automatically when we use getIcon, getMinU, etc.
Anyway, I'd be interested to know this too. I've googled a bit just now and I can't find anything useful. Maybe if you change your title to something like - How to use "Infinite terrain" (sprite sheets) for standard block rendering - it might attract some of the smarter guys? I already know how to do it for custom block and item renderers, but you want to know how to do it without that. Which would be nice, I'd like to have all my simple blocks and items in one texture.
Hrm, sorry, I'm talking nonsense - I don't know how in a block renderer, I ended up using a TESR in that case for this very reason! You can't bindTexture in a block renderer, so I have no idea how this could be done....
Minecraft stopped using sprite sheets for blocks and items a very long time ago. (some point between 1.4 and 1.5) Initially the game was limited to just one sprite sheet for all items and all blocks, this meant that every single textures for a block and item had to fit on a single sheet. This only allowed for 256 texture slots for blocks, and 256 for items. Naturally mojang hit this limit themselves and had to use the new system which was one file per texture, or if your in 1.8 1 file plus 2-3 json files. The tutorial you linked is for 1.4.7 which is just short of being two years out of date. You should probably move to some more modern sources. The whole idea being the "infinite terrarin" thing, is that with the help of forge, you could just use your own sprite sheet for your mod and it would be loaded instead of the vanilla one. Perhaps something like this will be better for you, you also may want to look up how to add meta data blocks as they require an ItemBlock and a few other things that are not very apparent.
i need 37 total blocks, last i checked meta blocks only went to 16...
i have the blocks all made and registered, i just need them to be able to change between 36 different textures a peice for 37 blocks... needless to say making that many texture files is probably a very bad idea... so how would i go about it easier?
NB: Every time I say "sprite sheet" will likely have double quotes around them, I know. Technically they're not sprites (sprites are animation frames); you could also call them megatextures, atlas sheets, texture maps, or something else - but I mean the same thing every time: "one physical texture file that is actually holding many textures".
"Sprite sheets" are not fully phased out, they're called the item atlas and block atlas. They're not limited by 256x256 and are built dynamically when Minecraft loads, you can still see references to this in the Minecraft startup log. All the blocks are still on one texture, that's why we have to use getIcon along with the getMinU (and so on) - the IIcon datatype is just a "helper" to work with a subset of the whole texture (the atlas).
I guess the question is - how can we add/register block icons beyond the limited "registerIcon" in IIconRegister, which requires that each IIcon be a separate texture file? This old "Infinite sprite sheet" thing seems to be functionally equivalent to an intermediary... thing, sitting between the block class and the Icon registry, that allows one to handle the uv-mapping on their own, in the scope that was first defined when assigned to the block.
I wasn't modding before 1.6.x, but it seems to me that this new IIcon + Texture Atlas system completely did away with the possibility of handling our own "sprite sheet" additions to the atlas.
The only way to do it right now is to just have a large array and a crapton of registerIcon calls, that's painful enough - but then each texture also has to be a separate PNG too? There must be a way to define just the one "sprite sheet", and the bounds of each texture and/or how many textures per row there are, and refer to them in a similar way. It'd be functionally identical to how Minecraft uses the font "sprite sheet".
Note that you pretty much end any chance of texture pack support with this behavior.
Artists really like being able to make textures one at a time, and submit "incomplete" resource pack to get feedback.
I see that TextureAtlasSprite is a Minecraft class, but I've never even seen it before. Have any example code to share? Also, what *can't* 801-core do You must have been working on this for a while. At this rate I'll be using it as a full library rather than snipping parts out. Do you plan to involve helpers for GUI's? Take a look at my scrolling GUI helper if that interests you. Only very basic for the moment, I'm sure you could do much better!
I see sprites as something you draw on the screen, be it animated or not. "Texture" encompasses the entire image, while a sprite can be a subsection of it.
True. A sprite is "a two-dimensionalimageoranimation (2D computer graphics) that is integrated into a larger scene". Most in game programming would associate a sprite with character animation sets, but technically it's what you describe.
Note that you pretty much end any chance of texture pack support with this behavior.
Artists really like being able to make textures one at a time, and submit "incomplete" resource pack to get feedback.
They could always do a 2x/3x/etc pixel resize on the original texture, and just replace the sprites that they've remade - leaving the others untouched. Now that I think about it though, contrary to what I said it'd be more logical to use one sprite sheet for one multi-textured block, or for similar types of blocks/items, rather than every single block/item in your mod.
Semi-offtopic: This may be the source of the high memory usage from textures. It seems to store the "spritesheets" in BufferedImage which is all on the ram. You can probably do more investigating on your own since I don't have Minecraft source at hand!
Interesting. Although I don't know enough about that-side-of-Java to understand the implications of this... but if there is a better way, changing it wouldn't be easy
Enochsend: Yes you may use that, however only if you accept my license.
Tundmatu: You make a good point, and I honestly don't know why I do that. I'll probably remove that whenever I have time.
GotoLink: Yes, I know my method cuts texture pack support off. Which is why I plan to "redirect" the images to the packs if such is enabled.
CosmicDan: I actually don't have much implemented into 801-Core. XD I won't bother copying or looking at your code since I want to learn the tessellator myself, however I'll bug one of my friends if I have any troubles or questions with the tessellator [for the gui].
Tundmatu: If I remember correctly (and I might just be lying out of my teeth on this one because I don't understand most of this myself), the only way to call a texture from a archive is through a "Buffered" stream. Which is why I use "BufferedImage", because it's "Buffered", and I can actually get the image through a archive.
Here's a screen-shot showing off the individual sprites in-game. (Although I don't think you'll believe me if you don't see it for yourself.)
I even have a class that lets me bind a texture from a custom location.
Using a BufferedImage to store the results of reading from a file is fine, but keeping it around after you've uploaded it to the GPU is just a waste of memory unless you're modifying pixels and then re-uploading them.
Ah, yes. I see your point, however there's no way to discard the image since it's being read from the sprite directly (the sprite needs the image to be there for the rgb array to be read and displayed).
That seems pretty backwards, a spritesheet is supposed to keep everything in one texture, not split it up at runtime. Does Minecraft require a RGB array/BufferedImage to create a sprite? If not you could just keep the original big texture and give each sprite the uv mappings of each individual sprite. This image describes how it works pretty good:
Yeah, now that you mention it, it does. XD
Minecraft actually does require an rgb array (that's how sprites are made) and a buffered image to be made. At least that's how it looks in the TextureMap class.
CosmicDan: I actually don't have much implemented into 801-Core. XD I won't bother copying or looking at your code since I want to learn the tessellator myself, however I'll bug one of my friends if I have any troubles or questions with the tessellator [for the gui].
Fair enough, it's actually not complicated at all - just glScissor'ing (thanks to SynthTones for the tip on that one) but with a few nuances here and there related to Minecraft rendering is the main thing yeah.
@ Custom location texture, as soon as I saw the "Monitor Settings" I instantly thought of a Security Camera.
I've actually thought about making a pretty generic GUI toolkit of sorts which you could plug in whatever renderer you want in it (Immediate mode, VBOs etc.) for some projects of mine. Maybe it could be applied to Minecraft as well if done right since it has pretty terrible support for making good UIs (no resizable windows, layout engine etc.)
I've actually started that very thing myself, although I only work on Minecraft and Android - and the sheer differences of these.... "platforms" is too crazy for me to bother working on anytime soon
http://www.minecraftforge.net/wiki/How_to_use_infinite_terrain_and_sprite_indexes - the tutorial im referring to...
they link to a grid of the index's http://www.mediafire.com/view/?scfy4fk54vzk4fq - but only call the whole file, so how does it know which of the 256 textures to use?
and just for the record i will not be using a TileEntity... they are Blocks and will stay that way unless i am forced to use a TE... as i do not want the increased lag caused by TE's....
1) What, exactly, is "infinite terrain"?
2) Do you realize that the tutorial is about an ancient version? Half of the terminology I don't event understand. Is it talking about the sprite sheets (referred to as the "block atlas" or "item atlas" in recent versions)?
3) What is this grid stuff about?
This, to me, just sounds like very obsolete information about using uv-mapped textures, like I've done with one of my GUI's for example.
2: that one perhaps, but ive seen the same info for 1.6.4 and 1.7.x
3: the grid is a literal copy of the grid vanilla uses for dyed leather, suited for anything else http://minecraft.gamepedia.com/File:Dyegraph.png
from what i have come to understand mapped textures only apply to GUI's and TE's.... but yes its the same principle only for basic blocks and items
Fair enough. Infinite Texture is a bit of a silly term, the generic gaming term is called a "sprite sheet" - one physical texture, but can be split up and different areas are "mapped" to be drawn at/by different areas/things.
I see what you mean though, about Blocks and Items. In basic texture use here we're restricted to "registerBlockIcons", and have to deal with IIcon type - and the IIcon datatype already has the uv map embedded within, as returned by the item/block atlas automatically when we use getIcon, getMinU, etc.
Anyway, I'd be interested to know this too. I've googled a bit just now and I can't find anything useful. Maybe if you change your title to something like - How to use "Infinite terrain" (sprite sheets) for standard block rendering - it might attract some of the smarter guys? I already know how to do it for custom block and item renderers, but you want to know how to do it without that. Which would be nice, I'd like to have all my simple blocks and items in one texture.
Farewell everyone o/
i have the blocks all made and registered, i just need them to be able to change between 36 different textures a peice for 37 blocks... needless to say making that many texture files is probably a very bad idea... so how would i go about it easier?
EDIT: Didn't see that he didn't want to use them
Art by me: MrPancakeWolfie@DeviantArt
"Sprite sheets" are not fully phased out, they're called the item atlas and block atlas. They're not limited by 256x256 and are built dynamically when Minecraft loads, you can still see references to this in the Minecraft startup log. All the blocks are still on one texture, that's why we have to use getIcon along with the getMinU (and so on) - the IIcon datatype is just a "helper" to work with a subset of the whole texture (the atlas).
I guess the question is - how can we add/register block icons beyond the limited "registerIcon" in IIconRegister, which requires that each IIcon be a separate texture file? This old "Infinite sprite sheet" thing seems to be functionally equivalent to an intermediary... thing, sitting between the block class and the Icon registry, that allows one to handle the uv-mapping on their own, in the scope that was first defined when assigned to the block.
I wasn't modding before 1.6.x, but it seems to me that this new IIcon + Texture Atlas system completely did away with the possibility of handling our own "sprite sheet" additions to the atlas.
The only way to do it right now is to just have a large array and a crapton of registerIcon calls, that's painful enough - but then each texture also has to be a separate PNG too? There must be a way to define just the one "sprite sheet", and the bounds of each texture and/or how many textures per row there are, and refer to them in a similar way. It'd be functionally identical to how Minecraft uses the font "sprite sheet".
Come again?
https://bitbucket.org/master801/801-core/src/cff462025954c2b56f8605f7828ed80463ef6d2b/src/main/java/core/helpers/SpriteHelper.java?at=1.7.10#cl-37
Artists really like being able to make textures one at a time, and submit "incomplete" resource pack to get feedback.
801-core saves the day again
I see that TextureAtlasSprite is a Minecraft class, but I've never even seen it before. Have any example code to share? Also, what *can't* 801-core do You must have been working on this for a while. At this rate I'll be using it as a full library rather than snipping parts out. Do you plan to involve helpers for GUI's? Take a look at my scrolling GUI helper if that interests you. Only very basic for the moment, I'm sure you could do much better!
True. A sprite is "a two-dimensional image or animation (2D computer graphics) that is integrated into a larger scene". Most in game programming would associate a sprite with character animation sets, but technically it's what you describe.
They could always do a 2x/3x/etc pixel resize on the original texture, and just replace the sprites that they've remade - leaving the others untouched. Now that I think about it though, contrary to what I said it'd be more logical to use one sprite sheet for one multi-textured block, or for similar types of blocks/items, rather than every single block/item in your mod.
Interesting. Although I don't know enough about that-side-of-Java to understand the implications of this... but if there is a better way, changing it wouldn't be easy
@Tundmatu thats pretty neat... i never could really differentiate, is that C++ or C#?
Tundmatu: You make a good point, and I honestly don't know why I do that. I'll probably remove that whenever I have time.
GotoLink: Yes, I know my method cuts texture pack support off. Which is why I plan to "redirect" the images to the packs if such is enabled.
CosmicDan: I actually don't have much implemented into 801-Core. XD I won't bother copying or looking at your code since I want to learn the tessellator myself, however I'll bug one of my friends if I have any troubles or questions with the tessellator [for the gui].
Tundmatu: If I remember correctly (and I might just be lying out of my teeth on this one because I don't understand most of this myself), the only way to call a texture from a archive is through a "Buffered" stream. Which is why I use "BufferedImage", because it's "Buffered", and I can actually get the image through a archive.
Here's a screen-shot showing off the individual sprites in-game. (Although I don't think you'll believe me if you don't see it for yourself.)
I even have a class that lets me bind a texture from a custom location.
https://bitbucket.org/master801/801-core/src/c7a78ee29f37302a4904f3c792a0b7a0e2ca905c/src/main/java/core/helpers/TextureHelper.java?at=1.7.10#cl-66
(Another screen-shot showing it in action.)
And yes, I know this method does not let textures be loaded from texture packs. :\
Ah, yes. I see your point, however there's no way to discard the image since it's being read from the sprite directly (the sprite needs the image to be there for the rgb array to be read and displayed).
Yeah, now that you mention it, it does. XD
Minecraft actually does require an rgb array (that's how sprites are made) and a buffered image to be made. At least that's how it looks in the TextureMap class.
Fair enough, it's actually not complicated at all - just glScissor'ing (thanks to SynthTones for the tip on that one) but with a few nuances here and there related to Minecraft rendering is the main thing yeah.
@ Custom location texture, as soon as I saw the "Monitor Settings" I instantly thought of a Security Camera.
I've actually started that very thing myself, although I only work on Minecraft and Android - and the sheer differences of these.... "platforms" is too crazy for me to bother working on anytime soon