Detecting change of texture pack

[jakj]

So far, the only way I can find to detect the change of texture pack in-game is to register a dummy of Forge's special FX class. Anyone see a better way?

[gotyaoi]

With the methods provided to us? Not sure. But perhaps changing the pack affects the texture pack files in some way? You could put a watcher on the directory... I think nio, in java 7, has a method for getting last access time.

[jakj]

Hrm, could be.

I've discovered that OpenGL has a rather curious omission: You are not able to bind a portion of a texture file as a texture. This is an issue when trying to apply (for example) textures out of terrain.png onto arbitrary surfaces, because tiling becomes a major issue while trying to keep the texture orientation and resolution consistent. The built-in tiling mechanism in OpenGL (where you simply specify texture coordinates beyond the actual texture and it wraps around) works brilliantly...but only on full textures, not subtextures. The two real ways to handle this end up both having rather glaring flaws to consider.

One way is to split the geometry at tile boundaries, which at first seems a reasonable way, but since Minecraft already is an inefficiently-written program, increasing the scene's complexity unnecessarily really isn't a very good idea. Additionally, sometimes there would be generated very long, thin triangles, and these can cause severe visual oddities and glitches.

The other way is to copy the image data of a subtexture at runtime and bind it as a new texture. Minecraft already has the mechanisms to do this easily: You can (using RenderEngine) get the OpenGL index of the already-loaded texture, use that to access Minecraft's BufferedImage version of it, use getSubimage to get a new BufferedImage of the subtexture, and pass that right back to allocateAndSetupTexture. There are three major flaws with this, though: It uses more texture memory (which is often the weakest part of mid- and low-end graphics cards), the data go stale if the texture pack changes, and the animation of lava/water/fire textures are lost.

There is the option of, for every submodel of every block of every render frame, to rebind and then dispose of the texture to keep everything fresh, but I wouldn't be surprised if the massive overhead of all that would end up bringing Minecraft to its knees.

The only other option I can think of is to go with the copy option, somehow account for animated textures, and upon texture-pack change, require the user to either restart the program or use an in-game item or menu option to trigger a flush of copied textures. Maybe the mod could cache some identifying information about the current texture pack and validate it once per second or so, and auto-flush upon a change...

[okamikk]

you could check the way MCpatcher does animated textures

[jakj]

MCpatcher isn't relevant to Technic.

[okamikk]

i meant the method, not the actual piece of code :hasnoideaofhowjava,oranyotherprogramminglaunguage,works: