It required pixel shaders. Therefore there was no way to "fall-back" to a software algo for systems that couldn't do the shaders.
I've seen many games that rely purely upon the GL 2.0 specification, to such an extent that just trying to use anything fixed-function OpenGL would crash the engine. i think it's interesting that you are now allowed to program the rendering pipeline but i've never really gotten the appeal of shaders...I think it's just partly the way my brain works, graphics doesn't turn me on as much as other people.
Look at our FPS shooters now. They have great graphics, but in very limited spaces. In other words the graphics are concentrated in 'levels'. Beating the level means loading a new world map and it's a world that you cannot leave. If you do, it's because they messed up somewhere. The only major free-form go anyhere, do anything game I've seen is FS2004 and it's purely a flight sim. The graphics could never be used for an FPS. A space sim wanting to do planetfall has to somehow merge two gaming genres successfully. The FPS and the flight sim.
Usually when this is done, one, or both sections of the game suffer.
Yeah, and this is why games such as everquest, guildwars, and others of the same genre have hackish looking terrain/trees/buildings (still professional quality, but obviously not superb) but with expansive universes...they're very popular.
Coincidentally, I was recently thinking of writing just a simple gravitation screen saver...I had seen a version on gamedev.net where a bunch of point masses are spawned, and they are attracted to each other...when they collide, they spawn into a larger point mass and eventually suck up the smaller particles. I really enjoyed watching that and wanted to write my own version.
So the easiest way to do this is to provide 'gates' to fly through to land on the planet. If you don't use a gate, you burn up. Collision can be found by using bounding spheres. Make the bounding sphere slightly larger than the planet. If the player is on the very fringes of the sphere, create some type of effect showing they are entering the atmosphere. Any farther and it's certain death. Many games have done this quite well - but Freelancer probably does it best.
Not a bad idea.
I very much feel like writing something that has to do with a planet/spaceships right now. If I get some pending work done I might do just that. Incidentally, about two years ago I started writing a demo where you fly around in a spaceship, but the spaceship is very large, subsequently you can choose two different modes: inside the spaceship, which is actually just an indoor BSP level, or outside the spaceship, which was just an octree (and where you'd pilot the spacecraft). It really wouldn't be too hard for me to whip something like that up, but I've got work pending. If I make anything I'll post it.
As an aside, this is the code I use for determining if two spheres collide. I was going to write a version in FPU (I've been on an assembly crunch lately, as you probably noticed by my thread in GD, so I've been going back and forth between my high languages and asm). It's just a swept-sphere collision test, the parameters denote the starting and ending positions of the vectors, and returns a float between 0 and 1 denoting the interpolation between each sphere's start and end positions.
Code:
double TimeOfSphereIntersection(double PosA1X,double PosA1Y,double PosA1Z,
double PosA2X,double PosA2Y,double PosA2Z,
double PosB1X,double PosB1Y,double PosB1Z,
double PosB2X,double PosB2Y,double PosB2Z,
double Radius1,double Radius2,double Epsilon)
{
Vector3D V1(PosA2X - PosA1X, PosA2Y - PosA1Y, PosA2Z - PosA1Z);
Vector3D V2(PosB2X - PosB1X, PosB2Y - PosB1Y, PosB2Z - PosB1Z);
//A is the difference in initial positions
Vector3D A(PosA1X - PosB1X, PosA1Y - PosB1Y, PosA1Z - PosB1Z);
//B is the difference in velocities
Vector3D B = V1 - V2;
double sep_dist = Radius1 + Radius2 + Epsilon;
double sep_dist_sq = sep_dist * sep_dist;
double AdotB = DotProduct(&A,&B);
double AdotB_sq = AdotB * AdotB;
double Bsq = B.BasicLength(); //length of b squared
double Asq = A.BasicLength();
#if 0
double iBsq = Bsq > .0000001 ? (1/Bsq) : 1; //Inverse of b squared
#else
double iBsq = 1 / Bsq;
#endif
double closest_sep_dist_sq = Asq - (AdotB_sq * iBsq);
if(closest_sep_dist_sq > sep_dist_sq) //spheres never collide
{
COLLISION_DEBUG( trace << "Closest_sep_dist_sq > sep_dist_sq, spheres never collide" << "\n"; )
return -1;
}
double under_root = AdotB_sq - (Bsq * (Asq - sep_dist_sq));
if(under_root < 0)
{
COLLISION_DEBUG( trace << "Collision debug, under_root negative" << "\n"; )
return -2;
}
double root = sqrt(under_root);
double time(0);
time = (-AdotB - root) * iBsq;
return time;
}
I've tested it and afaik it's 100% effective. The epsilon is added if you want a bit of extra space paddding between the two spheres (so they aren't quite exactly tangential when updated to their collision positions, avoid floating point weirdness)