Board index FlightGear Development Spaceflight

Earthview - an orbital terrain rendering engine [v2.0]

Discussion about development and usage of spacecraft

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Hooray » Sun Mar 25, 2012 7:15 pm

vitos wrote:I would really want to look on guy who could start to make highly precise celestial dynamics on base of unmantained second level interpreter language in situation of free choice. It's not personal, it's professional interest.


Don't worry: I don't feel offended at all, after all I didn't write the Nasal engine (and I also don't appreciate the fact that it's basically unmaintained at the moment) - and Thorsten also commented on Nasal not being suitable for this task, so I do share your concerns.

But obviously, Nasal is "Turing complete" and supports most modern programming paradigms. So there's nothing per se that you can't do in it.

Most issues making it really not suitable for this use case are related to the FlightGear architecture and its way of running its subsystems.

Also, I am not sure if you are aware of it, but there's a distinction between precision and accuracy actually.
Nasal numbers are all floating point with double precision, based on IEEE754.

I am not sure how you come up with the idea that Nasal is a "second level interpreter language"?

A conventional FG FDM will face the same frame rate-related issues because it is being run as part of the FG main loop (just at a higher rate due to not being interpreted), even if you were to fully implement it as a "standard" C++ SGSubsystem.

Even in C++, you would need to run the FDM in a separate process or thread to work around this and then synchronize output variables at frame rate.

Once you are using a Nasal worker thread to work around this, the only remaining issue affecting determinsm is probably the garbage collector - with the added advantage that you don't need to know a new programming language, and that you don't need to build any code from source. However, with Python (GIL) or Ruby you'd be off much worse actually.

There seems to be an increasing trend among non-programmers suggesting that Nasal is inferior and that "core C++ code" is superior, basically delegating the implementation of certain features to people who know C++ (i.e. core developers) - which is super-easy to do. But Thorsten has repatedly proven that there are many things possible in scripting space and if the frame rate is the bottleneck, then just look into doing your calculations in a worker thread instead.

Let me clarify, I have also seen Nasal worker threads being affected by (and also affecting) main loop performance (due to the GC) - but still, you can realistically achieve higher update rates by running some loops asynchronously.

In FlightGear, this is much easier to do using Nasal than with any other programming language.

Yes, obviously you can now simply wait for some C++ developer to step up and implement your fancy SFDM for you (I suggest not to hold your breath) - but in the meantime we could just as well look into using Nasal to come up with a workaround and explore its restrictions and try to make some progress in scripting space without depending on C++ work.

You would have NO EarthView addon if Thorsten hadn't implemented his own ideas in scripting space and waited instead for someone else to make require C++ changes. We would have NO advanced weather system if we had waited for some C++ developer to implement all of this in C++ code.

Yes, we have the freedom of choice. And yes, there are certainly better suited-languages available for "number-crunching".
Yes, you are free to use whatever language you want to implement a new special purpose FDM. But the decision will be up to the person looking into it. And hopefully their decision will be based on solid experience and not on some ill-informed rumours and comments found on the forum.

Using an arbitrary language to implement a SFDM as a separate process will require some form of IPC with the core FG process to exchange info (such as networking, shared memory).

By using Nasal, you don't need to worry about anything like that. The problems involved in using Nasal are well known (i.e. frame rate-limited and affected by the GC), but you'll get tons of advantages because Nasal IS THE programming language natively supported BY FlightGear.

Really, I am not trying to keep anybody from looking into C++ for this - if you can find/convince someone to do this in C++, GREAT! But, I am convinced that there's a fair bit of stuff that can be accomplished in the meantime, without having to wait for progress in the C++ department.

I am not saying this because I think Nasal can/should be used for everything (I don't!). But more often than not, I have seen people asking for some feature to be implemented in C++ space, that could just as well be implemented in scripting space easily - even by themselves, just by doing some reading. Basically offloading responsibility onto core developers.

However, the "most successful C++ feature requests" (because they got implemented QUICKLY!) I have seen, where based on solid facts and they were addressing shortcomings that couldn't be addressed otherwise.

Hat off to you (or anybody else for that matter) if you can come up with a SFDM in some other language. I just hope that it won't be coded in Visual Basic or .NET :lol:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12186
Joined: Tue Mar 25, 2008 8:40 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 7:39 pm

Hooray wrote in Sun Mar 25, 2012 7:15 pm:Don't worry: I don't feel offended at all


I had not in mind to offend You or someone else. I had in mind, aside of jokes, to look on Your reasons. And I had made it, thank You for explaining. Since You do not start to make that Nasal based celestial engine by Yourself You personally are not person of my interest. I am professionaly interested in Leonides themselves, not in Odysseuses.

Hooray wrote in Sun Mar 25, 2012 7:15 pm:Hat off to you (or anybody else for that matter) if you can come up with a SFDM in some other language. I just hope that it won't be coded in Visual Basic or .NET :lol:


There is already existed Open Source celestial engines based on C code. But I would't be surprised if someone will make another one on Nasal, as something that couldt be used anywhere else. Though it's impossible by using Nasal commands only, but I woldnt be suprised if that brave guy will use imported C++ functions then, or oven separate JSBSim thread to account some things.

You know, in Russia some people have phrase "special way of Russia" to explain their belief in that it possible, for example, to make space rockets with nuclear plants and to have absolute monarchy with feudalism simultaneously. So, I would recommend to You to learn phrase "special Flight Gear way" by heart, it could be useful to You. :D
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sun Mar 25, 2012 8:05 pm

Yes, that's true (but that would also apply to other FDMs such as YaSim or JSBSim) - one would need to run the "SFDM" decoupled from the frame rate to get better and more deterministic accuracy, i.e. by using a separate process (or a Nasal worker thread) and by only synchronizing the FDM outputs at FG frame rate, so that the FDM computations would be run separately, but FlightGear would read the FDM outputs (such as velocities, position, orientation) at frame rate from "global" variables that are written to by the worker thread (at much higher rates) - that way, the accuracy of the FDM computations would not be affected by your frame rate anymore.


No, that would in fact *not* apply to any other FDM since they run with a fixed rate and can have several iterations per graphical frame, which is what makes them (and hardcoded AP systems) stable at low framerates whereas Nasal-based AP systems are not stable at low framerates. Here's a genuine problem with Nasal. You can't write really sensitive stuff like positions from a worker thread into the property tree without a serious danger of crashing something important. The property tree isn't designed to do that.

Yes, one can write a Nasal script to place ISS into an orbit. But it seems actually better to implement an orbit feature into the AI system to me. I'm really a fan of doing stuff in Nasal, but this is a bit extreme...
Thorsten
 
Posts: 12017
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 8:11 pm

Thorsten wrote in Sun Mar 25, 2012 8:05 pm:Yes, one can write a Nasal script to place ISS into an orbit. But it seems actually better to implement an orbit feature into the AI system to me. I'm really a fan of doing stuff in Nasal, but this is a bit extreme...


I suppose ISS, as other AI orbital stations, gotta be runned as independent, and controllable, service on some server in multiplayer. Everyone should see it by mpmap.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sun Mar 25, 2012 8:15 pm

Well, actually no, because I'm not using Flightgear over MP ever and I still would like to go to ISS. I'm fine with it being synchronized over MP if applicable, but I'm absolutely against a feature that requires MP to work.
Thorsten
 
Posts: 12017
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby kyokoyama » Sun Mar 25, 2012 8:17 pm

Thorsten wrote in Sun Mar 25, 2012 8:15 pm:I suppose ISS, as other AI orbital stations, gotta be runned as independent, and controllable, service on some server in multiplayer. Everyone should see it by mpmap.

The ISS generally orbits on a set path, right? Then what about making a script that sets the "default" orbit of the ISS, but its specific path can be optionally adjusted according to the ISS in real life which is relayed through MP?

(though either way, I think MP needs to be more efficient and be able to synchronize better before we start this..)
Look for "B-BIRD" "N127KY" or "AVA0004" -that's me.

Despite having over 1700 posts here, I am not even close to being the most skilled guy here... I'm just words and bad drawing, not experience. :P
kyokoyama
 
Posts: 1981
Joined: Sun May 03, 2009 2:16 am
Location: Earth
Callsign: B-BIRD, N127KY
Version: 2.12.1
OS: Windows Vista

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 8:25 pm

Thorsten wrote in Sun Mar 25, 2012 8:15 pm:Well, actually no, because I'm not using Flightgear over MP ever and I still would like to go to ISS. I'm fine with it being synchronized over MP if applicable, but I'm absolutely against a feature that requires MP to work.


For example, child needs two human beings to be born. Somehow it's feature that requires MP to work. And real ISS is not some country private thing, it's common and requires MP to work too. It's not two different ISSes synchronised, it's objectively one thing. Anyway, anybody have right on their own "special way of something", even if sometimes that special way is existed only as simulation.

kyokoyama wrote in Sun Mar 25, 2012 8:17 pm:I think MP needs to be more efficient and be able to synchronize better before we start this..


MP needs adjusting anyway. In it's current state it would not allow any manned docking while most of real dockings was dockings of manned object to manned object.
Last edited by vitos on Sun Mar 25, 2012 8:27 pm, edited 1 time in total.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sun Mar 25, 2012 8:26 pm

Yes, it needs to be scripted. For instance, I would like an option 'place it such that my launch window is NOW!' so that you don't need to wait for half a day before it's finally in a suitable position. The same script can equally well be used to 'Set it to its actual position right now via MP sync'.

The launch window problem is even more pronounced for interplanetary spaceflight. I plotted a Jupiter-trajectory in Orbiter once which had 3 1/2 years wait before the launch window came up. I doubt that Flightgear even supports that kind of time-jump...
Thorsten
 
Posts: 12017
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 8:40 pm

Thorsten wrote in Sun Mar 25, 2012 8:26 pm:The launch window problem is even more pronounced for interplanetary spaceflight. I plotted a Jupiter-trajectory in Orbiter once which had 3 1/2 years wait before the launch window came up. I doubt that Flightgear even supports that kind of time-jump...


You gotta admit that spaceflight on itself is not so funny thing. Even one hour of free drift in orbital flight `round Earth is uninteresting on itself already. In reality interest of spaceflight is matter of beauty, company, and real work. I suppose it's impossible to reproduce its quality without these factors. So I do not agree with You about level of using MP in space flight. It's gotta be mostly MP thing, even if it would mean that Your flight to FGs ISS could have launch window at 3:00Am.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Thorsten » Sun Mar 25, 2012 8:45 pm

You gotta admit that spaceflight on itself is not so funny thing.


Look, it doesn't have to be 'either-or'. I would never do spaceflight over MP, because I wouldn't do it in real time - what interests me is sometimes the view, but most of the time plotting the maneuvers, so as far as I am concerned I'd separate the whole experience into maneuvers in real time, followed by fast forward to the next maneuver. Sitting three days in front of a computer to see the moon slowly approach is boring. But others like doing things over MP, so we design it such a way that both things are possible. I don't see the problem.
Thorsten
 
Posts: 12017
Joined: Mon Nov 02, 2009 8:33 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 8:50 pm

Thorsten wrote in Sun Mar 25, 2012 8:45 pm:I don't see the problem.


I do not see a problem too. Reproducing of one year of Mars flight in one to one proportion could be way too extremistic. Of course both approaches needs to be implemented. Anyway, ISS visible by mpmap, on same position where real ISS is, could be very attractive thing to new users. And possibility to dock to someone in visible to anyone else, even to guys without FG itself, multiplayer is completely other thing in means of attraction then possibility to dock to a local bot. It's, You know, kinda more real. I do not like that approach in closed source money sucking mmorpgs, but if it's Open Source which is invites people to learn something and to add something to freely accesible common good then there is no problem to me.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby kyokoyama » Sun Mar 25, 2012 9:13 pm

(it sounds like both of y'all are just in violent agreement...)

So the only question is whether or not to sync and share satellite locations?
(This doesn't have to be a mandatory feature, Thorsten)
Look for "B-BIRD" "N127KY" or "AVA0004" -that's me.

Despite having over 1700 posts here, I am not even close to being the most skilled guy here... I'm just words and bad drawing, not experience. :P
kyokoyama
 
Posts: 1981
Joined: Sun May 03, 2009 2:16 am
Location: Earth
Callsign: B-BIRD, N127KY
Version: 2.12.1
OS: Windows Vista

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Hooray » Sun Mar 25, 2012 9:32 pm

vitos wrote:Since You do not start to make that Nasal based celestial engine by Yourself You personally are not person of my interest. I am professionaly interested in Leonides themselves, not in Odysseuses.


Vitos, I am not sure if I want to understand you correctly (because that won't get us anywhere, as you should really know meanwhile).

You didn't want to cooperate with any of us (including Thorsten) because we kept telling you that *some* progress could be made in scripting space. You didn't even want to try my C++ patches because you were hoping to get other people interested in a different way.

It seems, you are still looking for people to implement your plans? I was hoping that you had reconsidered your attitude meanwhile?

While I am much more familiar with C, C++ and Nasal than with Greek mythology, I would probably consider it more interesting (and more immediate) to prototype something in scripting space, rather than in C++.

And I really don't mind disagreeing with Thorsten, for a change ;-)

Thorsten wrote:No, that would in fact *not* apply to any other FDM since they run with a fixed rate and can have several iterations per graphical frame, which is what makes them (and hardcoded AP systems) stable at low framerates whereas Nasal-based AP systems are not stable at low framerates.


Okay, you mean the interleaving of the FDM/AP, right? That's true.
But regardless of that, your computations are still limited by your frame rate, i.e. the execution time your code gets or not.

Also, you were misunderstanding what I wrote:

Thorsten wrote:Here's a genuine problem with Nasal. You can't write really sensitive stuff like positions from a worker thread into the property tree without a serious danger of crashing something important. The property tree isn't designed to do that.


Yes, I am aware of that (as you should know), but as you may remember: I suggested to synchronize the view (i.e. model placement in your main loop) by *copying* the values from GLOBAL *script* variables that are ONLY written to by the worker thread, there would be NO property tree access from the worker thread, it would just write to global variables, i.e. in pseudo code:

Code: Select all
# $FG_ROOT/Nasal/worker/worker.nas

var position = {lat:0,lon:0,alt:0,hdg:0,pitch:0,roll:0};
var g_stop_thread=0;
var g_thread_iterations_hz=0;

##
# called by the worker thread to update the global position hash
# do your calculations here, only write to members of the "position"
# hash

var work_horse = func {
  position.lat = 55.110;
  position.lon = 32.921;
  position.alt = 300000;
}

##
# this is the function running in the worker thread
# set g_stop_thread to stop thread
var heavy_computations = func {
 settimer( reset_iterations, 1);
 
 while (!g_stop_thread) {
  g_thread_iterations += 1;
  work_horse();
 }
}

##
# the timer callback
#

var reset_iterations = func {
  g_thread_iterations = 0;
}

##
# the main loop which merely updates the model's position
# based on the global variables stored in the position hash


var main_loop = func {
  update_model(position.lat,position.lon,position.alt); # wrapper for geo.put_model(...);
  settimer(main_loop,0); # run at frame rate
}

var update_model = func {
  var model_path = "";
  geo.put_model(model_path,position.lat,position.lon,position.alt); # hdg,pitch,roll
}

##
# the startup function that will be invoked once the module is loaded
#

var startup = func {
 thread.newthread( heavy_computations );
 main_loop();
}

##
# register the startup listener
#
_setlistener("/nasal/worker/loaded", startup);



Yes, one can write a Nasal script to place ISS into an orbit. But it seems actually better to implement an orbit feature into the AI system to me. I'm really a fan of doing stuff in Nasal, but this is a bit extreme...


Because of what exactly? You mentioned the required numerical stability and the lack of thread-safe property tree access - I think I illustrated how these limitations can be circumvented?
I still think it'll take less effort (coding and time-wise) to use a Nasal prototype for starters.

vitos wrote:I suppose ISS, as other AI orbital stations, gotta be runned as independent, and controllable, service on some server in multiplayer. Everyone should see it by mpmap.


Here, again, your perfectionism is killing everything: You come up with your ideal set of features, while it would be good enough, for the time being, to come up with some compromise. Pretty much everybody is aware of the limitations of the AI system and there's work going on to use the multiplayer system to synchronize AI across all clients. Mathias' HLA work is also related to this, too. It doesn't make sense to just come up with a list of "ideal" features, because that won't get us anywhere.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12186
Joined: Tue Mar 25, 2008 8:40 am

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby vitos » Sun Mar 25, 2012 10:33 pm

Hooray wrote in Sun Mar 25, 2012 9:32 pm:Vitos, I am not sure if I want to understand you correctly (because that won't get us anywhere, as you should really know meanwhile).

You didn't want to cooperate with any of us (including Thorsten) because we kept telling you that *some* progress could be made in scripting space. You didn't even want to try my C++ patches because you were hoping to get other people interested in a different way.


As You may check by my previous messages in that thread, if something works then I check this, and I am applying patches even if I do not like approach in that these patches had been made. I can add Your patch to check out if "Vostok" will slow down to 1fps here with it, but what if yes? And what if no? If yes then it would mean that there is one issue, if no then it would mean that there is other issue. Anyway, with Your patch it's become impossible to use FG as flight simulator, so it will not solve any problem really.

We discuss pros and contras here because nor me nor You are planning to implement some topic alike features, but Your point is to invite someone to do something right now in Nasal space while my point is to invite someone to do something in C space. That's what I mean by Odysseuses. Odysseus, You may know, had invited a lot of guys to war, and he went home alive while most of them had made much more heroical deeds than him but had died on it.

I am doing so because on time no one had helped me in learning FG core. I am knowing C enough, but will not do something alone, and of course I will not make Nasal space since I do not believe in it. Why You act as Odysseus I do not know and do not care about it a lot.
Waste of time: too unprofitable for work, too exhausting for hobby.
User avatar
vitos
 
Posts: 615
Joined: Sun Jan 25, 2009 8:10 pm
Location: Moscow, Russia
Callsign: vitos
IRC name: vitos
Version: 3.4
OS: Debian

Re: Earthview - an orbital terrain rendering engine [v0.1]

Postby Hooray » Mon Mar 26, 2012 12:15 am

OMFG...

I am not "inviting" anybody to do something in Nasal. I am just saying that it's possible, even without having to know anything about core programming and without knowing about building FG from source (which Thorsten agreed to btw). You repeatedly mentioned that those are EXACTLY the factors restricting your ability to bring changes to FG:

vitos wrote:I am doing so because on time no one had helped me in learning FG core.


You have a serious misunderstanding here, there are no people around here who are going to teach you about core programming. On the other hand, there ARE people around here, who will teach you how to do Nasal scripting and there are a number of tutorials, too.

If you are interested in core programming, it's a good idea to get subscribed to the FG devel mailing list and ask your questions there.

Honestly, you won't find anybody teaching you core programming or helping you learn more about it without making a conscious effort. If that's your interest, you could have said so MUCH earlier, our exchanges could have been way more constructive that way!

Look, I have no problem whatsoever if someone makes informed statements regarding Nasal restrictions. Thorsten, for example, has written incredible amounts of Nasal code, and so I don't mind exchanging different views with him, because he's obviously well-informed and usually knows what he's talking about, and even if we should disagree at times, he's still easy to get around with, even if one of us gets proven wrong.

Yet, there are certainly some programming paradigms and techniques that not even Thorsten has tried yet, including stuff in Nasal space - so, I don't mind pointing out how some of Nasal's "hard limits" can be circumvented using a different programming style or programming technique. That's not an invitation, it's just an explanation or illustration if you will.

Just do a quick google search: you will find numerous websites offering in-depth information on the calculations required to get the position for a satellite or the ISS, you can even find websites with fully working Java/Flash applets, and even JavaScript, doing all of these computations.

And you can even find fully documented source code for QBasic: http://www.amsat.org/amsat/articles/g3ruh/111.html
Just do a google search for "satellite position calculator" and you'll find numerous other examples.


vitos wrote:I will not make Nasal space since I do not believe in it.


It is easy to say that you "don't believe in Nasal space"-solutions, but you are gaining more credibility by actually having tried Nasal first, so that you can back your views with facts (that's exactly what's given Thorsten so much credibility and respect here).

Just look up all the postings where people are stating similar things: 90% of them are made by people who know little or even nothing about Nasal scripting. The remaining 10% are made by experienced C++ developers (such as core developers) who know Nasal scripting well enough that they're aware of the performance implications caused by its garbage collector and thus suggest to refrain from further using it for complex features until those issues are fixed.

There's something terribly broken if someone doesn't believe in scripting while claiming to "know C well enough", but requesting others to do the core work he's interested in, don't you think so?

Finally, I don't care at all if you are using Nasal, C, C++ or even Python - to me, it doesn't matter at all. Really, go ahead and use Visual Basic!
But just making a conscious effort would make a HUGE difference.

You said, I was "inviting" people (when I really wasn't), now here's a real invitation:

Honestly, while I think it's a little moot now to insinuate you needed some help to "learn core programming", I am here to take up your challenge to see if you can prove me wrong:

You said you are "familiar enough with C", right?

vitos wrote: I am knowing C enough, but will not do something alone


Great: I know enough about C, C++ and FlightGear core coding to answer your questions and explain to you, how to implement a new FlightGear subsystem, how to write and interface a new FDM, or how to expand the AI subsystem according to the suggestions that Thorsten has made.

So, be my guest: come up with your core programming questions and I will offer to provide step-by-step tutorials how the core code needs to be modified to implement the features you are looking for. I have done that various times for other users, particularly because their signal/noise ratio was VERY good (i.e. omega95 or redneck), so I don't mind doing this now for you.

Let me reiterate that: These will NOT be Nasal tutorials, these will be CORE programming tutorials illustrating step by step how to implement certain features in C and C++. You get personal programming support, provided by someone who's making a living as a software engineer coding in C and C++. For free, I may add!

However, please don't be surprised if you should have a hard time understanding them, because C/C++ code is generally much more complicated to understand than code implemented in scripting space.

Please just surprise me and don't respond with some pseudo-rethorical <synonym for bovine matter> metaphorical stuff and let's try to keep this constructive for a change, okay?

If it's really your lack of knowing how to do "FG core programming", that can be addressed - it will help all of us much more than embarking on these darn pseudo-intellectual debates where nothing gets done.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12186
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests