+3Vinyl wrote:Keon wrote:+2Prototype wrote: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.
Official Texture Pack for FC
-
- Recruit
- Posts:4
- Joined:Sun Jan 20, 2013 12:26 pm
- Affiliation:RTA
- IGN:stufuzzycat
-
- Lieutenant
- Posts:478
- Joined:Thu Dec 06, 2012 8:04 pm
- Affiliation:Voxel Co.
- IGN:Blockman42
- Location:Holocene
Re: Official Texture Pack for FC
+4stufuzzycat wrote:+3Vinyl wrote:Keon wrote:
+2
Re: Official Texture Pack for FC
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.
They're watching ...
"I am forbidden tag" -CvN
"I am forbidden tag" -CvN
-
- Developer
- Posts:2968
- Joined:Fri Dec 07, 2012 1:25 am
- Affiliation:NSCD
- IGN:Currently:Small_Bear
- Location:Yes
Re: Official Texture Pack for FC
Claustrophobia from a texture pack? Is such a thing possible?.Iv121 wrote: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.
Perhaps we should make the 16x16 texture first
Spoiler:
Mistake Not... wrote: This isn't rocket science, *!
Spoiler:
Re: Official Texture Pack for FC
64x gives too much space that you don't necessarily need. 16x is a bit limiting in what you can do.
They're watching ...
"I am forbidden tag" -CvN
"I am forbidden tag" -CvN
- fr0stbyte124
- Developer
- Posts:727
- Joined:Fri Dec 07, 2012 3:39 am
- Affiliation:Aye-Aye
Re: Official Texture Pack for FC
32x32 is nothing. Even higher shouldn't be too bad if we're careful.
Re: Official Texture Pack for FC
128 x 128 ?
64 x 64 would also do. Them compressed textures.
64 x 64 would also do. Them compressed textures.
Spoiler:
Re: Official Texture Pack for FC
I don't actually care about it programming wise but about filling 128x128 pixels by hand ...
They're watching ...
"I am forbidden tag" -CvN
"I am forbidden tag" -CvN
- fr0stbyte124
- Developer
- Posts:727
- Joined:Fri Dec 07, 2012 3:39 am
- Affiliation:Aye-Aye
Re: Official Texture Pack for FC
DXTC is really meant for color gradients rather than discrete low res tiles. But it might be interesting to try out.hyperlite wrote:128 x 128 ?
64 x 64 would also do. Them compressed textures.
At that resolution, nobody is going to be doing them one pixel at a time.Iv121 wrote:I don't actually care about it programming wise but about filling 128x128 pixels by hand ...
Also for the record I think 32x32 is plenty. More than that and it starts to look really weird on giant cubes.
-
- Recruit
- Posts:4
- Joined:Sun Jan 20, 2013 12:26 pm
- Affiliation:RTA
- IGN:stufuzzycat
Re: Official Texture Pack for FC
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.
Re: Official Texture Pack for FC
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.
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.
Spoiler:
-
- Designer
- Posts:397
- Joined:Fri Dec 07, 2012 11:59 pm
- Affiliation:Alteran
- Location:In the Holy Citadel of Altera
Re: Official Texture Pack for FC
The texturepack was always planned to be 32x32. Fr0st, is there any particular reason why Minecraft is so inefficient?
This is a signature.
- fr0stbyte124
- Developer
- Posts:727
- Joined:Fri Dec 07, 2012 3:39 am
- Affiliation:Aye-Aye
Re: Official Texture Pack for FC
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.hyperlite wrote: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.
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 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).Dr. Mackeroth wrote:The texturepack was always planned to be 32x32. Fr0st, is there any particular reason why Minecraft is so inefficient?
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.)