Do not forget the bottleneck is CPU, not memory nowadays. You should waste some memory to in order to give CPU some break.

Your reasoning is actually exactly the opposite of reality. CPUs are *highly* sensitive to memory latency and cache misses. The CPU can't do any useful work at all if its waiting for the data it needs to operate on.

You're conclusion is, however, on the mark. The reason you'd "waste" memory by pre-caching information you're not actively using is to move the data closer to the CPU within the memory hierarchy (Typically: CPU -> CPU registers, L1$, L2$, L3$, RAM, HDD). The nearer you are to the CPU, the greater the bandwidth and less latency involved. Bandwidth across SATA is more than an order of magnitude slower than typical bandwidth to main memory. Mechanical storage like traditional HDDs or optical discs aren't usually able to saturate the available bandwidth and introduce seek latencies in addition.

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]basically you are asking me to do exactly the same thing but to increase the "reset" distance from 1 chunk to 1024 chunk.[/background]

[/font]

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]what will it changes?[/background][/font]

If the re-centering operation is perfect, it will change almost nothing. If not, this reduces the chance to hiccup at a fraction. It also involves slightly less transform matrix uploading - but I'd expect the benefit to be not measurable. In general, the camera should be allowed to somehow move as expected or at least, some system must keep track of the "real" position. But if you just want to do minecraft, I suppose there will be no problems anyway.

Minecraft isn't infinite *grrrr*

but how to move it back to where he was last time?

With one big-ass text-file. (jk, I got no idea)

It's true that by expanding the cache size from radius+1 to radius*radius would allow me to load chunks in a unique thread.

however are you sure that it changes anything for when a player is going back and forth?
look at this, if the player is going back and forth, the red lines keeps getting loaded/unloaded.

but not having to be in a hurry to load chunk is quite nice^^

I think he meant that you unload chunks if you go far away from them, but you only load them if they get in the original cache area. So that you dont unload already loaded chunks until you need to because you might come back soon.

[quote name='sliders_alpha' timestamp='1335820150' post='4936182']
It's true that by expanding the cache size from radius+1 to radius*radius would allow me to load chunks in a unique thread.

however are you sure that it changes anything for when a player is going back and forth?
look at this, if the player is going back and forth, the red lines keeps getting loaded/unloaded.

but not having to be in a hurry to load chunk is quite nice^^

I think he meant that you unload chunks if you go far away from them, but you only load them if they get in the original cache area. So that you dont unload already loaded chunks until you need to because you might come back soon.
[/quote]

Yeah, this would allow you to unload not needed chunks and not fall into this load/unload loop if player moves back and forth. If he does, closest chunks will always be in cache so you can just fetch the reference and do whatever you want (render etc.)

But I'd make decision about unloading chunks not distance based - I suggest making a limited "list" or "deque" that will hold references to chunk data and it will act as cache that can store for example 500 chunks. You set the limit or allow user to choose based on his available memory. Whenever you hit the limit, you remove oldest chunk from it when you're inserting new one. Whenever you reference chunk for rendering you push that chunk on top of that "deque", this gives you chunks ordered by last access time. This way you can freely remove chunk from the bottom of the list because those are the oldest chunks and are not used anymore.

There is of course problem of quickly accessing required chunk (based on its coordinates?) but you can keep two lists - one linked list or some kind of deque to keep information about chunks last access time (this will be used to unload unused chunks) and another storage for fast chunk access (hash or dictionary kind) so you can quickly ask for a chunk at (x, y, z) and if its in cache it will fetch the reference - I assume that asking for a chunk by rendering engine would always return cached chunk because we ensure that chunks in some distance around player will be prefetched even if they're not needed right now.

Edit: Added diagram so it explains better what I had in mind. As you can see it gives us some sort of 'inertia' where chunk loading doesn't take place immediately when player moves (forward or back and forth) but only when we have to load completly new chunks.

Where are we and when are we and who are we?
How many people in how many places at how many times?