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

Find any bugs in Vega Strike? See if someone has already found it, or report them here!
Post Reply
AVBJim
Merchant
Merchant
Posts: 42
Joined: Tue Dec 22, 2009 9:16 pm

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

Post 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.
TBeholder
Elite Venturer
Elite Venturer
Posts: 753
Joined: Sat Apr 15, 2006 2:40 am
Location: chthonic safety

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

Post 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
Last edited by TBeholder on Sun May 01, 2011 10:10 pm, edited 1 time in total.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
athomic1
Bounty Hunter
Bounty Hunter
Posts: 137
Joined: Wed Apr 08, 2009 6:07 am

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

Post 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.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

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

Post 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.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

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

Post 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.
strook
ISO Party Member
ISO Party Member
Posts: 461
Joined: Fri Sep 03, 2010 12:10 pm

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

Post 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();
}
plz visit my vegastrike project branch here

plz support VegaOgre by donating to it!

My systems: Mac mini 1, 4gig RAM;
i5 Quad Core 2400, 300mbit WLAN, 1,3Tbyte HD, 60 GB SSD,
nvidia geforce 8400gs 512MB, 6gig RAM with Ubuntu 11.4,
win7 and hackintosh installed
breese
Bounty Hunter
Bounty Hunter
Posts: 152
Joined: Thu Sep 02, 2010 8:00 pm

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

Post 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.
Post Reply