no
> Thats cool, but do you think reading terrain data from the HD is practical in a realtime app?
Well if you know the platform on which you're running this application (or can specify it), and you can afford the memory then go for the big arrays. But be aware that if you have a desktop OS (which OS is it?), much of the array could be in the swap file anyway.
As for HD access, you have to factor in a couple more variables
- how quickly can you traverse a single terrain cell?
- how slow is the worst-case disk access
You would be looking to create a buffer zone of cells around the perimeter which you could wander into whilst the disk caught up with you.
Basically, you need to buffer as many cells as necessary to allow for the fastest taversal of the terrain, to allow for the slowest disk access.
Wow, that's a really great point I wouldn't have even thought of! (Just something I take for granted, suppose...) Just how much you buffer should take into account that a simple change in direction might cause a large buffer to be discarded, keep in mind.You would be looking to create a buffer zone of cells around the perimeter which you could wander into whilst the disk caught up with you.
As far as fractals are concerned, yes, they "morph" quite well. The beauty is, a complex fractal can be quite simple an equation, in fact no more complex than your typical terrain generators, and you only need to generate/use as much of it as necessary at the moment, optimizing the cpu even further.
Anyway, good luck on the game...oh, what API are you using, by the way?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
for rendering im using OpenGL.
And Windows is the target OS.
I didnt consider the page file deal, so useing arrays may be optimal still.
Last edited by Eber Kain; 09-28-2002 at 06:08 PM.
