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.
"Warping" effect during SPEC in auto, A Question for all
-
- Merchant
- Posts: 42
- Joined: Tue Dec 22, 2009 9:16 pm
-
- 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
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.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?
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
-
- Bounty Hunter
- Posts: 137
- Joined: Wed Apr 08, 2009 6:07 am
Re: "Warping" effect during SPEC in auto, A Question for all
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.
-
- 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
That might happen, but only if your fps also dropped very low, like 5-10.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.
Otherwise, I don't think it's the cockpit.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: "Warping" effect during SPEC in auto, A Question for all
The VS code is not thread-safe, and it is not easy to make it thread-safe without a major rewrite.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.
-
- ISO Party Member
- Posts: 461
- Joined: Fri Sep 03, 2010 12:10 pm
Re: "Warping" effect during SPEC in auto, A Question for all
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.
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
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
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: "Warping" effect during SPEC in auto, A Question for all
It is hard to do multithreading correctly. See for instance Herb Sutter's Effective Concurrency series.strook wrote:Multithreading is easy!
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.
Boost.Thread helps, but it only provides the basic primitives that are needed for multithreading.strook wrote:With boost!
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.
Intel's TBB is better suited for this, but I doubt that we gain much from it.strook wrote:And you can paralelize everything, that doesn't need to be executed in a serial order.
This is not thread-safe.strook wrote: boost::mutex.lock();
Somevalue =1;
Boost::mutex.unlock();
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.