i think the problem with sticking something like this into this engion would be more or less a lack of space. freespace has a fixed mission radius, so youd either end up with the freelancer effect where everythings scaled down rediculously, or you have scenes with room only for a single planet or part of a planet. not that i dont want a full and realistically modeled solar system with full on newtonian, and realistic atmoshpere with lift and drag and gravity built in.. but i dont think this engine is ready yet.
Wrong...
Well, I know that there is a big problem with float numbers. The thing is that the precision gets lost for greater numbers. People are using double precision vectors to aid this situation a little more. I've solved this problem already and I'm still using single precision vectors.
The trick is really simple. I don't use global coordinates. Instead I'm putting on object into it's segment with a local coordinate system. And I allow an object to switch between segments.
In other words, I can have as much "space" as I want without any freelancer effects.
If there are still questions about it, then launch my demo and press F10. You will see that the camera position vector doesn't exceed number greater than -5000 to 5000 (roughly).
By the way, note that the Y axis is always showing upwards from the planet's surface. And you can also test the Day&Night cycle feature and note that the camera position isn't changing.
you also have the problem that youre pretty much using all microsoft apis, rather than cross platform stuff. i dont think coders like taylor and goob want to add any features that wont be available for all platforms.
Wrong, too.
The API doesn't matter. As far as you might notice, Freespace 2 originally could switch between DirectX and Glide.
In the same way I'm not dependant from APIs as much. The backbone of my small engine is the scenegraph. And I don't make any calls to DirectX or OpenGL from there.
It looks good, but my question is what would happen if we put this code into our engine? Will it break backwards compatibility (with FreeSpace 2 Vanilla, an important feature for many people)? Will it really be put into the code? There are several hard-coded maximums in this game--one of them being a maximum distance from the origin (600K km, IIRC) that the player can go. Also, how we utilize an upgrade of this magnitude? If it's not compatible with an existing or new 3rd party out-of-game creator, how will we be able to use this feature?
There's a number of other things to consider--I'm saying this looks like a huge expansion on our engine, but will it really work and is it really worth it? I'm no programmer, but this seems very hard to implement without completely rewriting our code.
It's a very complicated question ... As far as I know the original sexp instructions I don't expect that the script would suffer from this extension. If you want to convert existing missions you will only have to assign the absolute origin to a position in the solar system(or better to a segment in the solar system).
The downwards compatibility is more a problem for existing source code modifications of FS2. You must know that the original FS2 didn't have a scenegraph (Maybe a small one, which assign turret positions to a ship). Generally, by using a scenegraph(like the one from me) you are forced to treat every coordinates as local coordinates of different scenenodes (= segments in some of my cases).
E.g. because we can't guarantee that an object is in the same node with an other object we can't ask for their relative location directly. Instead we must check their parent nodes and translate the coordinates of one of them by need. I expect, that the performance of AI routines will suffer a little bit (I hope not too much).
Another fact is that the distances can be too great and some calulations would lose precisions. And it is also possible that a location can't be determined exactly anymore (e.g. when objects are in opposite corners of the world). Maybe we will need some more instructions for sexp to handle this problem. The same counts for the AI routines. But this is never the case for missions of the current FS2 version.
The third fact is that I'm using a out-of-core paging mechanism and the application doesn't know the existance of outpaged object untill their segments are paged in. The application will have to explore all the segments within a radius from a given position. So one of important sexp extensions could be this exploration request.
you can implement it but that means you must also commit to fixing any bugs you may introduce by addint it. lest get your feature rolled back from stable, or worse yet rolled back from head. the scp requires long term developers who are willing to maintain their features. last thing i want is to start augmenting my mod to use another feature and then have that feature rolled back just as im ready to put something cool out. then i got to wait 6+ months for those features to be stable enough to make head, and then take a couple more years before the feature is in an offitial stable build.
That's a problem ... But there is nothing unnatural.