Page 1 of 1

"Warping" effect during SPEC in auto, A Question for all

Posted: Thu Apr 28, 2011 4:41 pm
by AVBJim
When traveling in systems, I prefer to select target and hit the auto key. But, I keep getting either "warped" past objects/suns or crash into them. Question, is anyone else experiencing this on a regular basis? If so, are you also using a multi-core or multi-processor system?

I am currently analyzing the navigation coding to make changes for a mod I am planning. I ask the above question because I have seen this type of effect with games designed for single processors when run on multi-processors without selecting a single core. I am considering changing the coding to include threading. If others are having the same problem, I will attempt to make the threading version and make it available to everyone. That is, a threading version that does not include other changes based on my mod.

If it also occurs on single processor systems, then it may be a bug instead of a multi-core/processor problem.

Re: "Warping" effect during SPEC in auto, A Question for all

Posted: Thu Apr 28, 2011 7:20 pm
by TBeholder
AVBJim wrote:When traveling in systems, I prefer to select target and hit the auto key. But, I keep getting either "warped" past objects/suns or crash into them. Question, is anyone else experiencing this on a regular basis? If so, are you also using a multi-core or multi-processor system?
Yes, but rarely and it worked this same way on single-core too. It just that autopilot will not slow down until SPEC is suppressed and turns off at a very short distance.
Tweak "warp*" variables in physics.
Hm, maybe turning "autopilot_ramp_warp_down" on is enough.

Edit: meowwit!
I forgot - it's irrelevant because my VS always runs with CPU affinity enforced, mainly because otherwise machine did randomly slow down to drooling and accelerate, like with many other 3D games. The same can be done with Xorg, but i don't know where to do it on start-up. My vs.sh:

Code: Select all

#!/bin/sh
 if [ "$PROGRAM" = "" ]; then
  PROGRAM=$0
fi
PROGRAM_DIR=`dirname "$PROGRAM"`
cd $PROGRAM_DIR
if [ "$1" = "" ]; then
  CMDLINE="mission/main_menu.mission"
else
  CMDLINE=$@
fi
REPORT_DIR="$HOME/.vegastrike"
taskset 02 vegastrike/vegastrike $CMDLINE  2>"$REPORT_DIR"/vegastrike_err.txt 1>"$REPORT_DIR"/vegastrike_out.txt

Re: "Warping" effect during SPEC in auto, A Question for all

Posted: Fri Apr 29, 2011 11:55 pm
by athomic1
This seemed to happen when I would run with cockpit on. My ship would overshoot the target, and then struggle to get turned about and back on track. I think the overhead of maintaining the cockpit view interfered with the autopilot's response. Not sure if this is the same thing you're talking about, but seems similar.

Re: "Warping" effect during SPEC in auto, A Question for all

Posted: Sat Apr 30, 2011 12:05 am
by klauss
athomic1 wrote:This seemed to happen when I would run with cockpit on. My ship would overshoot the target, and then struggle to get turned about and back on track. I think the overhead of maintaining the cockpit view interfered with the autopilot's response. Not sure if this is the same thing you're talking about, but seems similar.
That might happen, but only if your fps also dropped very low, like 5-10.

Otherwise, I don't think it's the cockpit.

Re: "Warping" effect during SPEC in auto, A Question for all

Posted: Sun May 01, 2011 2:15 pm
by breese
AVBJim wrote:I am considering changing the coding to include threading. If others are having the same problem, I will attempt to make the threading version and make it available to everyone. That is, a threading version that does not include other changes based on my mod.
The VS code is not thread-safe, and it is not easy to make it thread-safe without a major rewrite.

Re: "Warping" effect during SPEC in auto, A Question for all

Posted: Tue May 03, 2011 10:32 am
by strook
Multithreading is easy!
With boost!
And you can paralelize everything, that doesn't need to be executed in a serial order.
That means, the folowing result depends on the previous result.

Code: Select all

#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>


struct drawer_work
{
  Drawer_work(int id) : id(id),exit(false) { }

  void operator()()
  {
    While(!exit)
    {
      //do some io operation
      boost::mutex.lock();
      Somevalue =1;
      Boost::mutex.unlock();
      Glbegin();
      gldrawsomething();
      Glend();
    }
  }
 Bool exit;
  int id;
};

int main(int argc, char* argv[])
{
Int somevalue;
// create a thread
  boost::thread drawthread(drawer_work(1));
// now you have 2threads
...
//at exit: synchronize and set exit value to ensure all threads are killed
Boost::mutex.lock();
Drawthread.exit = true;
Boost::mutex.unlock();
  Drawthread.join();
}

Re: "Warping" effect during SPEC in auto, A Question for all

Posted: Tue May 03, 2011 5:07 pm
by breese
strook wrote:Multithreading is easy!
It is hard to do multithreading correctly. See for instance Herb Sutter's Effective Concurrency series.

However, that was not really my point. Point was that the VS code is not thread-safe, and it is difficult to make it so.
strook wrote:With boost!
Boost.Thread helps, but it only provides the basic primitives that are needed for multithreading.

On the commercial projects that I have worked on, the conclusion has always been that we need higher levels of abstraction (such as the Active Object pattern) to avoid the most common threading errors (such as deadlocks or forgetting to lock a mutex before accessing the variable it protects.) It is way to easy to make threading errors with the basic primitives, and these errors are often difficult to find.
strook wrote:And you can paralelize everything, that doesn't need to be executed in a serial order.
Intel's TBB is better suited for this, but I doubt that we gain much from it.
strook wrote: boost::mutex.lock();
Somevalue =1;
Boost::mutex.unlock();
This is not thread-safe.

First, "boost::mutex.lock()" is not legal, because lock() is not a static member function.

Second, your mutex must have at least the same lifespan as the Somevalue variable that it protects. In other words, the mutex must be a member variable. If your mutex is a local variable the each thread will lock a different mutex (allocated on stack), and there would be no synchronization between the threads.

Third, use scoped_lock to handle the locking in an exception-safe manner.