Official Texture Pack for FC

[stufuzzycat]

16x16 is traditional minecraft, and would work with even low spec systems, although we could have a 16x16 standard, and then ,Anne later produce a HD texture pack.

+2

+3

[blockman42]

+2

+3

+4

[Iv121]

Ok ok I got it no need to spam, but you will really need to find someone else to work on your texture pack them that 16x causes me claustrophobia.

[Prototype]

Ok ok I got it no need to spam, but you will really need to find someone else to work on your texture pack them that 16x causes me claustrophobia.

Claustrophobia from a texture pack? Is such a thing possible?.

Perhaps we should make the 16x16 texture first Anne and then make a 32x texture, but I don't see any point in anything like 64x64 or 128x128

[Iv121]

64x gives too much space that you don't necessarily need. 16x is a bit limiting in what you can do.

[fr0stbyte124]

32x32 is nothing. Even higher shouldn't be too bad if we're careful.

[hyperlite]

128 x 128 ?

64 x 64 would also do. Them compressed textures.

[Iv121]

I don't actually care about it programming wise but about filling 128x128 pixels by hand ...

[fr0stbyte124]

128 x 128 ?

64 x 64 would also do. Them compressed textures.

DXTC is really meant for color gradients rather than discrete low res tiles. But it might be interesting to try out.

I don't actually care about it programming wise but about filling 128x128 pixels by hand ...

At that resolution, nobody is going to be doing them one pixel at a time.

Also for the record I think 32x32 is plenty. More than that and it starts to look really weird on giant cubes.

[stufuzzycat]

I would say either 16x or 32x is good, but much higher than that people with lower-powered computers are going to have a hard time running 64x or higher.

[hyperlite]

We should all know by now that my laptop is crap. I had a 64 x 64 texture pack once.

No reduction from my normal framerate with default minecraft.

Back on 1.1 I used fast culling by fr0st.

I used to have to use short render, and cycle it around once in a while, I could put it on far with that and had higher FPS.

When is there gonna be another fast culling thing? That worked out really well for me.

[Dr. Mackeroth]

The texturepack was always planned to be 32x32. Fr0st, is there any particular reason why Minecraft is so inefficient?

[Iv121]

You want them all ?

[fr0stbyte124]

We should all know by now that my laptop is crap. I had a 64 x 64 texture pack once.

No reduction from my normal framerate with default minecraft.

Back on 1.1 I used fast culling by fr0st.

I used to have to use short render, and cycle it around once in a while, I could put it on far with that and had higher FPS.

When is there gonna be another fast culling thing? That worked out really well for me.

I don't know. I haven't worked out exactly how to deal with lighting when the thin-client update came, though I haven't put much time into it, either.
The main thing, though is that it doesn't make sense to do this type of culling in the Copernicus engine, because we have even smarter ways of doing it. Fast culling is just a quick and dirty estimation which stores a few visibility flags at the chunk level to work out which chunks are guaranteed impossible to see behind other chunks from the camera perspective. The original game isn't designed with well-defined meshes in mind, so quick and dirty is the best we can do. The new engine has a much more elaborate understanding of the surface meshes and where the holes are, and so it can do more traditional occlusion culling (based on simplified mappings) much more efficiently and more accurately than either of the previous methods.

I was considering reviving the old fast culling method as an anti x-ray server mod, but that's been a low priority so far.

The texturepack was always planned to be 32x32. Fr0st, is there any particular reason why Minecraft is so inefficient?

The way texture lookup works is that the GPU's multiprocessors sample a 2x2 set of texels in video memory, which is slow as hell compared to most other things the GPU handles. To hide the latency it switches to other parts of the polygon while it is looking up those first textures, and the switches back when they are loaded (doesn't really help when all the program does is texture loading, but it does get the ball rolling faster). Once a texture is loaded, it is put into a fast-access texture cache, which will range from 4KB all the way up to I think 16KB on the newest models. Now, in terms of size, that is seriously small. With a 32 bit color (rgb8 + alpha), that is only a 32x32 texture on the smallest texture cache. Anything more than that and you get thrashing, that is, the process of loading new textels into the cache (which is the only place the multiprocessor can actually do logic on the texture from).

The smart way to deal with this is to do what Eihort does, and render large sweeps of polygons with all the same texture, thereby having everything in cache the entire fill. It is also why most games sort rendering by material. Currently, we're not doing this, because we need virtual texturing for lighting at a minimum so it makes sense to do it all at once, but we can switch to the Eihort style if that proves to be the better method.

If we just need color and no alpha, or if it is a binary alpha (so 1 bit for transparency), we could use DXT1 texture compression, which compared to a 32-bit uncompressed type will net us a gain of 8x the texture area able to stay stored in cache. Natural terrain, at least should still look decent, and this would make a huge difference. Additionally, by using mipmaps, which are lower resolutions of the same textures, we can cache distant textures using less space in the texture cache (though 1/3 more space overall, which is pennies compared to the savings we already get storing vertices more efficiently.)

[hyperlite]

Anti-xray? How the hell am I supposed to cheat now?