20,741
edits
FlightGear high-level architecture support: Difference between revisions
Jump to navigation
Jump to search
FlightGear high-level architecture support (view source)
Revision as of 22:40, 28 March 2013
, 28 March 2013→Benefits
| Line 79: | Line 79: | ||
== Benefits == | == Benefits == | ||
the RTI c++ interface is defined in a way that you do not need to recompile anything. Everyting is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. For the case that a particular RTI implementation does not follow this rule, you need to compile flightgear explicitly for this particular library. | |||
The spatial indices implemented in the RTI regions will be a huge benefit, since you will only recieve the messages that are relevant near the region of your interest. | The spatial indices implemented in the RTI regions will be a huge benefit, since you will only recieve the messages that are relevant near the region of your interest. | ||
| Line 114: | Line 116: | ||
Getting back to components: Latencies are a critical part of running in multiple threads/applications. This is not a particular problem of hla, this | Getting back to components: Latencies are a critical part of running in multiple threads/applications. This is not a particular problem of hla, this | ||
is a generic problem when running real time applications in parallel. I know a lot of really smart people who can even understand complex environments very well, but have no clue about the problems introduced by round trips. Seen this, this is the reason why I started that hla stuff, since this provides a framework which supports and even encourages a programming model that is able to hide latencies as good as possible. Anyway, there is a chance that you even use this api in a way that really hurts in this corner. And this is actually the really bad thing I want to avoid: If you are the first component that does not get that right you might just notice little to nothing - especially if you are running on extrem fast hardware. But when the next kind of problem is introduced this really starts to hurt more and more. And most people do not have any chance to see what happens and why. | is a generic problem when running real time applications in parallel. I know a lot of really smart people who can even understand complex environments very well, but have no clue about the problems introduced by round trips. Seen this, this is the reason why I started that hla stuff, since this provides a framework which supports and even encourages a programming model that is able to hide latencies as good as possible. Anyway, there is a chance that you even use this api in a way that really hurts in this corner. And this is actually the really bad thing I want to avoid: If you are the first component that does not get that right you might just notice little to nothing - especially if you are running on extrem fast hardware. But when the next kind of problem is introduced this really starts to hurt more and more. And most people do not have any chance to see what happens and why. | ||
= Use Cases = | = Use Cases = | ||