"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!

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

Postby AVBJim » Thu Apr 28, 2011 9:41 am

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.
AVBJim
Merchant
Merchant
 
Posts: 42
Topics: 10
Joined: Tue Dec 22, 2009 2:16 pm

Share On:

Share on Facebook Facebook Share on Twitter Twitter Share on Digg Digg

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

Postby TBeholder » Thu Apr 28, 2011 12:20 pm

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 3:10 pm, edited 1 time in total.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
User avatar
TBeholder
Elite Venturer
Elite Venturer
 
Posts: 747
Topics: 38
Joined: Fri Apr 14, 2006 7:40 pm
Location: chthonic safety

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

Postby athomic1 » Fri Apr 29, 2011 4:55 pm

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.
athomic1
Bounty Hunter
Bounty Hunter
 
Posts: 137
Topics: 7
Joined: Tue Apr 07, 2009 11:07 pm

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

Postby klauss » Fri Apr 29, 2011 5:05 pm

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
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

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

Postby breese » Sun May 01, 2011 7:15 am

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.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm

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

Postby strook » Tue May 03, 2011 3:32 am

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
User avatar
strook
ISO Party Member
ISO Party Member
 
Posts: 461
Topics: 20
Joined: Fri Sep 03, 2010 5:10 am

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

Postby breese » Tue May 03, 2011 10:07 am

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.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm



Return to Bug Triage

Who is online

Users browsing this forum: No registered users and 1 guest

cron