It's apparent dyes have caught on in a big way. I was skeptical at first, but soon found myself scouring the map for cactus and squid to make complex color schemes in my underwater base. Being underwater, the ceiling is glass, and I had the idea, what about stained glass?
Turns out I'm not the first. A lot of good ideas have been thrown out there, with colored sand being smelted, and having a 'lite-bright' approach rather than complicated color casting shadows through the glass. And there's a lot more out there than glass and sand: paintbrushes/buckets of paint, stone, dirt, mobs, armor, wood, beds, feathers, arrows, torches, flags, all dyeable.
These ideas all have the same flaws (aside from the glass's shadow complexity), namely that the poor terrain.png file can barely take one of these implementations, let alone all of them. But there's also lot of enthusiasm for these ideas. Instead of having a series of incompatible mods, what if there was a different way to address the problem?
What if the current dyed wool slots were instead pure fields of color, one corresponding to each dye, and there was an engine in place allowing minecraft to tint blocks (via whatever mechanism catches on, crafting or smelting or paintbrushes and whatnot), essentially rendering a version of the block's sprite that has been tinted with a field of color? With hex values instead of images of fields of color, no space in terrain.png need be devoted to the dye at all.
Pros:
Saves limited resources in terrain.png
Opens the door to all sorts of implementations of dyes elegantly
Cons:
An in-game image tinting engine could be super taxing
Would probably require adding another field to the basic block model to keep track of things
Ways around these cons:
VS. An in-game image tinting engine could be super taxing:
I haven't toyed with the lwjgl much so I don't know what kind of potential it has for a coloring engine, either as a plugin or a Mojang-developed capability, or even an already available capability. It could be easier than I fear, or impassable. I have faith in the Minecraft dev community to come up with some clever solutions but the end result may be too demanding. Research time anyone?
VS. Would probably require adding another field to the basic block model to keep track of things
To simplify the rendering of the block model's new field, if we avoid the concept of walking up to blocks and painting them, then the user *must* harvest the blocks from the map and craft/smelt them to obtained dyed blocks. That means any dyed block on the map is by necessity not included in the initial seed, but part of the 'diff' to use git terminology. Since (I think?) rendering is done first by the seed, and then overlaying the diffs the user has made to the map over the original seed, all blocks could have the 'dyed' field but only blocks that show up in the diff would ever have to access that field to test for whether or not and how to color the block, greatly lowering the amount of testing and processing necessary to implement such a fundamental addition to the block model.
Interesting... This would still prevent ops from giving themselves mass amounts of colored blocks, of course, forcing them to spawn the dyes, but that's nothing new. I imagine it wouldn't be too hard to add extra custom dyed item patterns, allowing extreme personalization of armor, stained glass, beds, and add a new dimension to what dying wool blocks would allow.
I do have to wonder, though, if this would be taxing in unexpected ways. Correct me if I am wrong, but currently every rendered portion of the map is saved in the terrain.png file, whose limited space is just the issue you want to circumvent. It seems to me a Color Engine would work one of three ways:
1. Access a Color Engine specific form of terrain.png which it would generate on startup, such that one can personalize its startup parameters, and then use the extra block value to access the new image to be rendered, or
2. Having the Color Engine actually generate tinted blocks in real time. This would require reading the diff block values, accessing the block's original image, going through the tinting process, then sending the image back. This would take over double the time of the above method.
3. Having the Color Engine actually somehow tint the images in game, rather than accessing their original images at any point. I am not familiar enough with java's capacities to work out how this would go.
Working a form of cost-benefit analysis on the different ways of doing it might be the determining factor on this one. And honestly, it's such a fundamental change to the game, the only point of making a mod to do it would be to see if it catches on enough to be actually implemented. Still, this is the best color customization idea I've seen yet.
I was going for what you call method number 2. Having a tinted copy of the terrain.png for each dye is an interesting idea, but still has the requirement that you have a copy of each block image for every color.
No, just the tintable ones. Granted, it would still be massive, but also accomplish the same thing more quickly. Plus you would be free to code in a method more accessible to adding new items than the original terrain.png file, which is the only real difficulty with adding tinted blocks in the first place.
Thinking about the third method... When mining a block, decals appear on the sides of the blocks to display the cracking. Perhaps sneaky abuse of a similar method, telling it the trigger condition is always active, thus displaying a colored decal, would be interesting. Under the surface, though, it would still drop the undyed block. This would allow a simple coloring mechanism for the block when on the map. Those blocks would still need to possess a new block value to flag them for decaling, I suppose, and to mark them out as different in the inventory.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Turns out I'm not the first. A lot of good ideas have been thrown out there, with colored sand being smelted, and having a 'lite-bright' approach rather than complicated color casting shadows through the glass. And there's a lot more out there than glass and sand: paintbrushes/buckets of paint, stone, dirt, mobs, armor, wood, beds, feathers, arrows, torches, flags, all dyeable.
These ideas all have the same flaws (aside from the glass's shadow complexity), namely that the poor terrain.png file can barely take one of these implementations, let alone all of them. But there's also lot of enthusiasm for these ideas. Instead of having a series of incompatible mods, what if there was a different way to address the problem?
What if the current dyed wool slots were instead pure fields of color, one corresponding to each dye, and there was an engine in place allowing minecraft to tint blocks (via whatever mechanism catches on, crafting or smelting or paintbrushes and whatnot), essentially rendering a version of the block's sprite that has been tinted with a field of color? With hex values instead of images of fields of color, no space in terrain.png need be devoted to the dye at all.
Pros:
Saves limited resources in terrain.png
Opens the door to all sorts of implementations of dyes elegantly
Cons:
An in-game image tinting engine could be super taxing
Would probably require adding another field to the basic block model to keep track of things
Ways around these cons:
VS. An in-game image tinting engine could be super taxing:
I haven't toyed with the lwjgl much so I don't know what kind of potential it has for a coloring engine, either as a plugin or a Mojang-developed capability, or even an already available capability. It could be easier than I fear, or impassable. I have faith in the Minecraft dev community to come up with some clever solutions but the end result may be too demanding. Research time anyone?
VS. Would probably require adding another field to the basic block model to keep track of things
To simplify the rendering of the block model's new field, if we avoid the concept of walking up to blocks and painting them, then the user *must* harvest the blocks from the map and craft/smelt them to obtained dyed blocks. That means any dyed block on the map is by necessity not included in the initial seed, but part of the 'diff' to use git terminology. Since (I think?) rendering is done first by the seed, and then overlaying the diffs the user has made to the map over the original seed, all blocks could have the 'dyed' field but only blocks that show up in the diff would ever have to access that field to test for whether or not and how to color the block, greatly lowering the amount of testing and processing necessary to implement such a fundamental addition to the block model.
Thoughts/comments/suggestions/concerns/repartees?
I do have to wonder, though, if this would be taxing in unexpected ways. Correct me if I am wrong, but currently every rendered portion of the map is saved in the terrain.png file, whose limited space is just the issue you want to circumvent. It seems to me a Color Engine would work one of three ways:
1. Access a Color Engine specific form of terrain.png which it would generate on startup, such that one can personalize its startup parameters, and then use the extra block value to access the new image to be rendered, or
2. Having the Color Engine actually generate tinted blocks in real time. This would require reading the diff block values, accessing the block's original image, going through the tinting process, then sending the image back. This would take over double the time of the above method.
3. Having the Color Engine actually somehow tint the images in game, rather than accessing their original images at any point. I am not familiar enough with java's capacities to work out how this would go.