nVidia Driver Tweaks for Fligthgear on *nix OS

[valery]

@jwocky:
Java is not for me a matter of taste, I like it. It's simply a question of efficiency: whatever you do, you will be in front of jni. Jogl sometimes compiles badly even on Linux (I don't know how it does currently, but you can look at the bug I fixed myself for FreeBSD:
https://jogamp.org/bugzilla/show_bug.cgi?id=1275
I opened the same king of ticket some years ago for linux too.
But you can bench Java/JoGL and see whether the same king of gl_* calls gives you the same score with C++ or not. If so, yes, between Java or C++, I would take the first. Last but not least, about efficiency, bytecodes cannot by nature have the same level of optimization than native code.
The second spot I would like to share with you is about existing code. You would like to fork something in C++11 to Java ? oÔ
I don't think that C++ is really compliant with Java ..(is Java really an OO language ... )
Anyway, I would be happy to share some concept here but I'm not sure to be the right guy for this.

The best thing I can do is to provide some materials that will improve existing FG code. But for this, the better is to study what kind of troubles the FGteam has encountered and how/why they have solve them like that.
So, going back if I have something to provide ... after my Bell of course )

CU

Val
[FIXED]

[KL-666]

I think that distinguishing between: This is an OO language, and that is not, is semantically incorrect. OO is language independent, it is a coding principle. Some languages implement OO principles more, and other less. C++ may implement OO principles quite much. Java also, but php almost not.

So my objection is to: OO equals language

Kind regards, Vincent

[valery]

Ok, post fixed !
Happy jOvO

Val.

[jwocky]

@Vincent: Then for the sake of the peace of your soul ... I spoke about OO language as a criteria for chosing a replacement for Nasal.

@Val: No, you can't just fork from C++11 into Java, it means rewriting the thing from the scratch because the current source code looks like ... well, I am lacking the words to describe that. Hard-coded website addies, memory allocation without destructors, the forgotten objects ... in short, all the sloppiness of an organic growth over many years. Now, they try to catch it via the garbage collector (because finally they have one) and this is all they actually use from C++11 as it looks.
Now rewriting a project the size of FG sounds madness at first, but since the current source code writes basically some concept failures in stone, I see no other way. We can't make FG multithreaded by just taking out some minor tasks and put them in other threads. We would need to do multithreading first on concept level, be clear about the communication maybe needed additionally between threads and so on. In other words, we have to break up the monolith. And once we do that, we are rewriting a lot of stuff anyway.
I mentioned the JMonkeyEngine because it is stable, fast, GPL and it is written in C++ for the use with Java.

However, due to time-limitations not much will happen soon. So consider thus more as a philosophy input.

[KL-666]

Hmm, with my little use of nasal, i actually never considered it as an OO implementing language. I thought of it more as a procedural language.

Kind regards, Vincent

[IAHM-COL]

do you mean Spaguetti soup, Vincent?

[KL-666]

Well, when abusing any language, OO or not, you can get spaghetti. In case of flightgear i am very worried about that. They can not even produce a simple scheme of their code.

Kind regards, Vincent

[IAHM-COL]

@Val: No, you can't just fork from C++11 into Java, it means rewriting the thing from the scratch because the current source code looks like ...etc

I must agree with this assesement, and it's worrysome

If we want to fork, and the first goal is to get Multithreading going properly that sounds as a major rewrite.
I wonder how much code reusability would we talking about here, but the more... the best.

So in reality we have 2 perspecitves

1, a patched-version of FG with some of our own flavors coded in (easy way to go), but hard to implement real x64 way. and We are kind of committed to someone else's preference of C++, or
2, a fork and major rewrite work to go full x64 and restructure the whole thing from the floor up. This is scary project and we are totally unoptimum on manpower to even think about it, but it certainly would be the best way to get a fresh start. Try to reuse as much as possible but giving us more liberties on doing things our way.

Now, method 1 above have the implicit advantage of allowing us to continually fetch work committed by the FG cores, if we were to wish to do so. Or at least it would facilitate us to evaluate their work as potential future patching.


as a final remarks; this project is frightening for the size and complexity, but on the other hand I've reached the conclusion that we are slowly but firmly getting to the point where a creation of a truly free and opensource, community driven development flight simulator is needed. And in spite of the existence of FlightGear and Xplane, we are made aware that the development of these simulators is not fully open, either not opensourced, or not free, or surrounded by a non-inclusive development groups. Therefore, the niche for such truly open Free-FlightSimulator exists. Question remains on whether community could self organize around such project and goal.

IHCOL

[KL-666]

All nice and great forking. But for now we have no one wanting to do the C coding. See:

http://www.thejabberwocky.net/viewtopic.php?f=27&t=846

So for now we must stay a addon group, i estimate.

Kind regards, Vincent

[IAHM-COL]

I agree, but If I read Valery correctly he would be interested in reconsider the idea of forking.
Such idea is one easy to tease with