Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: razorjack on September 24, 2007, 03:35:31 pm
-
Hello,
I've got the idea to extend the freespace SCP engine with a couple of new abilities of intrasystemal cruising and seamless planetary atmosphere flights. The technical side of this question is almost done and I've got a working demo:
Screenshots:
http://www.gamedev.net/community/forums/topic.asp?topic_id=442406
Executable:
http://www.razorjack.de/demo.zip
If you want to run the demo you require following preferences:
SSE2 capatibility
DirectX9 (december 2006 release or better)
latest VC2005 runtimes downloadable from microsoft
Please take note that my terrain engine is the main performance consumer. The work around the terrain is almost undone and the routines were all hacked together within a half week, but they do a good work -
To begin with the mod I need a programmer with experience of different terrain types (especially ROAM) to write better terrain routines. And I need also a programmer who is able to work with freespace source code.
-
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.
Oh, and...
:welcomeblue:
-
Play freelancer
-
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.
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.
-
Hmmm, he's actually offering his help to improve FS2 in a way a lot of people wanted it to improve it. At least for some mod projects.
And it's not just an idea, but he actually build a demo version... so what's up with the negative attitude here?
I quite like the idea. :)
Nuke is right though. D3D isn't really supported very well anymore and nobody seems to be fixing it. And even if we brought it back to the current OpenGL level, the planetary system just mustn't be API/platform dependant.
-
i w3ould really love to have this feature though. but you cant just slap engine a ontop of engine b and expect it to work. ive wretten a rather crappy graphics enngine, capable of drawing two 12-line models (i havent put polies in yet) simultaniously an an amazing rate of 45 frames a second! now if i tried to add that to freespace for like 3d hud gauges, id have to deal with a completely different aproach to basic classes. such as my vector class may not be compatable with freespace's struct. and i always have to convert back and fourth between class a and struct b. ineffitiency overwealming. reinventing the wheel in about a dozen places.
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.
-
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. :D
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.
-
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.
i wouldnt go as far as saying im totally wrong. the problem of the mission area has been discussed to death, in detail, before. this (http://www.hard-light.net/forums/index.php/topic,48993.0.html) thread has several pages of requests by modders and rebuttals by coders full of reasons why the feature should and should not be added, respectively. the reasoning behind it was different but the essence is the same, make the game area bigger. anyway it got controversial enought to get the thread locked.
now your solution might work in your demo but it would require low-level code changes throughout alot of the fs2 code base. and as far as that goes fs2 isnt one of the most user friendly codebases out there. i remember cries of disgust at all the gotos and the speggetification that was there. the code is alot more organized now. but it took several years to get the codebase to where it is.
Wrong, too. :D
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.
i was more or less trying to be informative about the needs of the fs2 codebase as far as perfered libraries and apis. i know from my expirience with using apis is that the can be shuffeled in and out at will sometimes with very little tweaking. least the ones i used made that easy. what youre doing seems to be creating a means to do procedural planetary system, save fr probibly some mapping features really has nothing to do with rendering but rather creating the data to be rendered.
anyway dont get me wrong i really do hope you make me eat my words. youre feature just seems to be a little too good to be true though. sorry if i sounded rude with my initial posts, havent sleped in a couple days. but if youre serious and you can get the other coders to support your idea , go for it. you might want to post in the scp forum to get their attention. youre talking to the modders not the programmers here :D
-
you might want to post in the scp forum to get their attention. youre talking to the modders not the programmers here :D
...which is right here (http://www.hard-light.net/forums/index.php/board,50.0.html). :D
-
This sounds like an opportunity. Come on, people, let's not be all prickly - can't we give this a shot? Worst it can do is fail.
Razorjack, I'd love to see this work.
-
Um... wow.
This looks really, really, cool; but it also has the potential to seriously conflict with a whole lot of other things in the SCP (such as stability and balance), so we need to tread carefully here.
Why does it require DX9? Did you do a complete graphical upgrade, or something? Keep in mind that the primary engine in the SCP now is OGL.
-
It's a great concept; not terribly groundbreaking as a concept but that doesn't mean it's worth exploring. But I don't believe it belongs in the SCP either, because of both the aforementioned compatibility and stability issues, but also because that's not what Freespace ever pretended to be. It would be a new feature, but I just have to ask at what point things stray so far from the way the engine is currently used that they become bloat. I know I've been rare enough around here that my opinion doesn't count for much (if it ever did), but those are my 2 cents.
-
Personally, I think your knowledge of procedural generation etc could be far more useful if you joined the team and worked alongside them, that way you could work alongside the graphical developments in FS2 to ensure you get the most from your engine.
The original Freespace 2 engine, from what I understand, doesn't much like generating objects in-game, because of the way the BSP Tree works, so this would, if used, have to overcome that somehow, and still deal with things like collisions, not to mention having an AI that is capable of dealing with it. ;)
As you say, procedural generation can be a resource hog, but that's becoming less and less of an issue as people upgrade their rigs, in many ways it's time to worry about forward compatability as much as backwards.
As has been said, it's an uphill task, generating the terrain itself is not the only aspect of the job, though it is a large percentage of it, texturing, placement of buildings/features etc etc would also have to be considered.
Personally, I'd love to see it, but it would also be one of the biggest, and probably most difficult changes to the Engine yet, but in this case, I think you could help the SCP guys more than they could help you ;)
-
It's a great concept; not terribly groundbreaking as a concept but that doesn't mean it's worth exploring. But I don't believe it belongs in the SCP either, because of both the aforementioned compatibility and stability issues, but also because that's not what Freespace ever pretended to be. It would be a new feature, but I just have to ask at what point things stray so far from the way the engine is currently used that they become bloat. I know I've been rare enough around here that my opinion doesn't count for much (if it ever did), but those are my 2 cents.
/me agrees.
-
It's a great concept; not terribly groundbreaking as a concept but that doesn't mean it's worth exploring. But I don't believe it belongs in the SCP either, because of both the aforementioned compatibility and stability issues, but also because that's not what Freespace ever pretended to be. It would be a new feature, but I just have to ask at what point things stray so far from the way the engine is currently used that they become bloat. I know I've been rare enough around here that my opinion doesn't count for much (if it ever did), but those are my 2 cents.
/me agrees.
/me agrees.
-
You do, I'll admit have to look at usefullness over work involved, it's really down to those who doing the coding itself though.
-
Could this be treated as a plugin to the engine? If you don't need it, then it won't get loaded (i.e. bloated)
-
I just realized that read wrong. Should have said "... it's not worth exploring."
If freespace could be made extensible enough to accept a plugin of that magnitude then that would be interesting. Sounds like a ton of work though.
-
Well this sucks it says i don't have any compatible Direct3D devices. so i can't play the demo.
edit:sounds like an interesting idea, but hard to get it to work without ruining backwards compatibility.
-
Mph. You know at least the SWC could use this... prolly some others, too... let's have a show of hands: Who would like to try to outrun the Shivvers in a daring escape from the surface of Vasuda Prime? ;)
-
I think that we can try to make everything downwards compatible and the engine doesn't require all too much changes.
The idea to have a plugin is also possible I think. We just need to perform all manipulations and queries to a scene object over an interface.
The planetary surface can be split up into objects, too.
As far as I can remember, "the babylon project" used an object as terrain. It wouldn't change all too much. The only thing is that some objects will be generated automatically (e.g. Planetary surface chunks and asteroids).
-
While everyone is complaining about procedural planets being something unFS2-like let me point out that I'd rather see this used for procedural asteroids and asteroid fields. That's definitely FS2-ish and would be a most welcome addition as it would give us many things people have asked for (multiple fields, fields with a less clear boundary, larger asteroid variety, etc).
-
Well. My initial reaction was "coool". So far, regardless of comments that some of the stuff isn't really what Freespace is about (comments which I agree with), that reaction stands. Even if it's not Freespace-ish, it's still cool, and I'm sure there are mods or TCs that would love to have it :)
-
Well... I had planned script that would keep erasing and regenerating (or moving) asteroids as player moves around to create an illusion of an immense asteroid field... But the hack would have been clearly visible (unless using very, very dark background). But getting such option in some distant future to the code would be great.
And as for adding additional stuff during the mission... Doable.. scripts already allow for placing additional ships/weapons/asteroids/debris to the mission. Only issue is that IIRC FRED hangs itself if you try to access those ships (non-existing according to FRED). But they work nicely via scripts.
And perhaps the larger universe thing wouldnt be very FreeSpaceish but then again IMHO there is a world of difference between FreeSpace (game universe) and the FreeSpace Open (game engine)
-
How hard would it be to do a "Xtaylor" (well, ok "Xrazorjack") build, just to see how it would work, and to find any compatibility errors?
EDIT: BTW, skipjack, if you wanted to take a shot at mixing it in with the FS2 engine yourself and make an experimental build, directions for getting the Source Code are here (http://www.hard-light.net/wiki/index.php/Getting_the_FreeSpace2:_SCP_Source_Code)... not sure if you can / want to / should, but you're a coder, and I'm not... so there you have it. Ask the SCP dudes about anything else. :D
-
well nukemod would certainly use theese features. i wanted to do some atmospheric stuff. btrl would definately use it as they have alot of saurface level stuff in battlestar. and the lack of scenery is one of those things which freespace tends to lack in contrast with newer games. this could be one of the things to push the engine forward from what would be considered old skool. keeping the engine semi-modern.
-
Well, there's no doubt that RazorJacks' procedural knowledge will be useful one way or another ;)
I really hope something can be done about this, but this is something that just screams 'plan of attack'.
-
:) A "plan of attack" would be:
The thing is that every object in FS2 is instanced with the structure called "object" (in object.h). Our problem is now that their coordinates are lying in the global coordinate system. What we need is to place every object into the local coordinate system of a parental segment later.
Currently, FS2 performs calculations with the object's coordinates by accessing position variables directly.
So the next step would be to forbid any direct access to these variables and use an interface instead.
The interface could contain functions like these:
- Delta vector between object1 and object2
- Distance between object1 and object2
- get local position
- set local position
aso.
After that we can implement the back-end behind this interface in different manner. And it allows us to switch between the current FS2 engine and the extensions.
I would like to get some help because there are over 2000 accesses all over the source. If we get it working then we have done near the half way to the finish.
By the way, I renamed the structures "object" to "object_t" today because it's a problem to distinguish between the datatype and the word "object" in the code. (You can get my updates from: www.razorjack.de/code.zip)
-
on the issue of backwards compatibility:
How about a stand alone mod like TBP or BtRL?
hp63 :p
-
i finally managed to get your demo to work, had to go do a dll hunt though. anyway i was rather impressed at the speed of the engine and at the reasonably smooth transitions. i had to try really hard to get the thing to eat up 40% of my cpu resources. my computer is pretty much top of the line with only extream gamer machines ahead of it. but i figure with the time it would take to get this feature in that should be about the norm.
you could probibly take advantage of dual-cores to generate terrain and bsp data on the fly in another thread. while youre in one level of terrain you could incrementally do calculations for adjacent detail levels so that when its time to make a transition that data is waiting around in memory. freespace itself would operate entirely in thread 1, while thread 2 has all the procedural stuff. you could probibly also adapt this to do procedural greebeling on largr spacecraft like imperial star destroyers, that is if theres any surplus cpu time for that thread :D
i take it your system uses regular float vectors for local stuff and a long integer vector as somewhat of a multiple and essentially is used as a frame-of-referance. so like if an object's local y axis passes 10000 then the y axis for its sector increases by 1 and 10000 is subtracted from local y. for small objects like ships and asteroids and some small moons or ice dwarves, youd only really need to worry about transforms and renders of those objects if theyre within your current sector as well as adjacent sectors. that gives me some ideas for my own engine.
large objects may need to be bigger. like a star would fill up multiple sectorsi wouldnt know how to tacke that problem. youd probibly have to break your object up along the sector bounds, then you could render 1 per sector. it sounds rather complicated.
-
on the issue of backwards compatibility:
How about a stand alone mod like TBP or BtRL?
hp63 :p
more features for em :D
the problem with making a mod or a tc in this engine is that its continually evolving. and a modder must, like the coders, commit to fixing their bugs for the long term. this is why nukemod is continuously evolving.
-
interesting.
-
i finally managed to get your demo to work, had to go do a dll hunt though. anyway i was rather impressed at the speed of the engine and at the reasonably smooth transitions. i had to try really hard to get the thing to eat up 40% of my cpu resources. my computer is pretty much top of the line with only extream gamer machines ahead of it. but i figure with the time it would take to get this feature in that should be about the norm.
The terrain engine is taken nearly line for line form www.frustum.org. But it's not suitable I found it out.
But I won't continue to develop my engine if I manage to make the FS2 engine mod to work.
you could probibly take advantage of dual-cores to generate terrain and bsp data on the fly in another thread. while youre in one level of terrain you could incrementally do calculations for adjacent detail levels so that when its time to make a transition that data is waiting around in memory. freespace itself would operate entirely in thread 1, while thread 2 has all the procedural stuff. you could probibly also adapt this to do procedural greebeling on largr spacecraft like imperial star destroyers, that is if theres any surplus cpu time for that thread :D
You're right. Normally this should be done in threads. By the way, the idea with generating models is interesting. I would like to use different routines for different object types. a voxel engine for asteroids from the guy (http://www.home.zonnet.nl/petervenis/index.htm). For big capital ships we can better take mount static chunks instead of compiling a BSP model. But there are other problems now :)
i take it your system uses regular float vectors for local stuff and a long integer vector as somewhat of a multiple and essentially is used as a frame-of-referance. so like if an object's local y axis passes 10000 then the y axis for its sector increases by 1 and 10000 is subtracted from local y. for small objects like ships and asteroids and some small moons or ice dwarves, youd only really need to worry about transforms and renders of those objects if theyre within your current sector as well as adjacent sectors. that gives me some ideas for my own engine.
large objects may need to be bigger. like a star would fill up multiple sectorsi wouldnt know how to tacke that problem. youd probibly have to break your object up along the sector bounds, then you could render 1 per sector. it sounds rather complicated.
I don't make it all too complicated. But You're right with the integers.
To give you some more ideas, I operate on a divide and conquer principle:
At the beginning you have a single sector box containing the solar system or anything you want. Then you can subdivide it into smaller boxes and select one of them. After that you have to scale up this selected child to the size of his parent. The same subdivision+scaling process can be repeated with him and his grand children. Per iteration you can push the indicies of the children into a stack to use it as a "house number" for a given subsector (It is this integer thing you meant).
All you have is a tree structure then. Bigger objects like planets can be stored at higher level of this tree. The smallest of them like all the ships in FS2 are resisting in the leafs.
If the player ship wants to go into a high speed he can alternatively climb up the tree to get faster (The same effect when you change layers in my demo). It works like the LDS drive in I-War 2 or the SPEC drive in vegastrike.
This tree can be also rendered in multiple passes by clearing the Z-Buffer between them really easily.
-
Anyway I wouldn't deny any help from programmers by implementing this tree algorithm into FS2.
-
Why would a planetary environment be considered non FS2-ish? Series like Colony Wars didn't have planetary missions at the beginning.
It would give a boost to user made campaigns. There are so many things we can do in planets, like colonizations, battles, rescue operations and other original stuff :)
-
on the issue of backwards compatibility:
How about a stand alone mod like TBP or BtRL?
I doubt either mod has team members stupid enough to want to break backwards compatibility with FS2 retail. Hell I wouldn't even want to release with a non-official fs2_Open build again if I can avoid it. Let alone one forked from the the main tree.
-
for reverse compatability you just have to enforce the mission radius. all youre really doing is revamping the coordanate system. and if youre thorough to make sure that everything that touches that system knows how to use it.
-
I don't know why everyone is screaming backwards compatibility. There's not a lot of things you could add to the engine that would _have_ to break compatibility. I'm sure there are numerous ways to implement it, as he said, which don't interfere at all with the current behavior. And what's with the nay-saying in general? Give the guy a break, if you have something that negative to say, try to think of a possible solution at least. Especially since he's not been around here for very long, and the first thing people do is start telling him "it won't work"? Come on, you guys know better than this. And come on, assuming that DX was needed for the engine itself and not just chosen as the means of interfacing with your graphics cards? Shame on you. :)
-
as much as i dont like the reverse compatability policy it has been one of the unifiying forces behind the scp. just look at all the quake source projects and how fragmented they are. i can think of many versions of quake 1 and 2 and some have feature a and some have feature b and few have any major tcs attached to them. so its not entirely a bad thing to maintain reverse compatability, and it has made moding fairly consistant with retail.
most of the requested features can be implemented without breaking recerse compatability assuming the programmer is skilled enough and proper testing and bug reporting is done. though doing so is sometimes a monumental task. multiple docking is a good example of something noone thought possible without breaking the engine, but it turns out they made it work.
-
I meant in this instance, I'm all for maintaining compatibility too, I just don't see this having to break it. If nothing else, most things could be enabled/disabled via tables or something, and off by default, so the retail would never know they exist.
-
The terrain engine is taken nearly line for line form www.frustum.org. But it's not suitable I found it out.
But I won't continue to develop my engine if I manage to make the FS2 engine mod to work.
...
You're right. Normally this should be done in threads. By the way, the idea with generating models is interesting. I would like to use different routines for different object types. a voxel engine for asteroids from the guy (http://www.home.zonnet.nl/petervenis/index.htm). For big capital ships we can better take mount static chunks instead of compiling a BSP model. But there are other problems now :)
I have one question: How are you handling the license issues? FS2 isn't GPL, so even if the code you're using is GPL, you've still got a problem. Not to throw a spanner in the works, but someone might want to have a good long look at the licensing stuff...
-
The terrain engine is taken nearly line for line form www.frustum.org. But it's not suitable I found it out.
But I won't continue to develop my engine if I manage to make the FS2 engine mod to work.
...
You're right. Normally this should be done in threads. By the way, the idea with generating models is interesting. I would like to use different routines for different object types. a voxel engine for asteroids from the guy (http://www.home.zonnet.nl/petervenis/index.htm). For big capital ships we can better take mount static chunks instead of compiling a BSP model. But there are other problems now :)
I have one question: How are you handling the license issues? FS2 isn't GPL, so even if the code you're using is GPL, you've still got a problem. Not to throw a spanner in the works, but someone might want to have a good long look at the licensing stuff...
Good thinking.
EDIT: Looks like it's GPL, everything else on the site is. Bummer.
-
If it's LGPL we should still be ok using it I thought. Not sure which it is though.
-
If it's LGPL we should still be ok using it I thought. Not sure which it is though.
Yes, LGPL is ok. No, it's not likely to be LGPL. Most people pick one License and stick with it, and at least one of the projects on that site says "GPL" not "LGPL".
-
How large is this program? If its small enough, you could use the clean room approach that everyone and their brother used on PHOENIX to get their BIOS. ;)
-
I've not said a word to import their terrain engine into FS2, so it's a "no" :)
There is no problem to write new routines for us. The current terrain engine is less than 800 lines. The frustum.org engine is good but not suitable.
All the other sources are 100% my own.
-
Cool. I like this idea, it could offer new opportunities and not necessarily make the game un-FreeSpacey. If I knew how to program I'd have a go at trying to implement something like this.
-
make a freespace2 fork? or a new space game using scp fs2 engine plus new improvments
-
It depends from the SCP team. It would be good to join and integrate my proposed feature into FS2SCP.
Otherwise I will have to fork.
By the way I need regular tests (look at http://www.hard-light.net/forums/index.php/topic,49809.0.html)
I began to modularize the engine and merge it with my sources at some places and there are possibly bugs inside.
Any help would be welcome.
-
There's no need to fork. Forks are bad. Forks are evil.
-
just grab an up to date head build, add stuff to it, and then if it looks like its stable and doesnt break reverse compatibility, they might let you commit it. seems to be the usual procedure for adding features.
-
The problem is that I can't grab the actual build because I've changed almost every file.