What Are You Working On? V13

[ZeekyHBomb]

[QUOTE=PatGlynn;25613832]With the first block of code, Yes it would happen. But you cannot count on the lock in myThread being called prior or after the lock being called in main. So if you did that you might lock that mutex and the thread wouldnt execute anything past the lock call untill it was unlocked ( or if it unlocked prior to the thread ever calling lock )[/QUOTE]
Is this for mutexes in general or just the mutexes of the WinAPI?

[QUOTE=PatGlynn;25613832]So if your wanting like a job thread to process along side of anything it looks like you would do it like this

[cpp]

// make the thread
boost::thread physicsThreadJob = boost::thread(&physicsThreadFunctionSingleIteration);
// do whatever you want that doesnt rely on physics data as its being possibly updated and modified by the job thread.

// join the thread ( wait for it to finish if it has not )
physicsThreadJob.join();
[/cpp]
and i mean that would be inside of a function. You wouldnt have physicsThreadJob be a global.
or maybe i'm missing something?[/QUOTE]

Already proposed that:

[QUOTE=ZeekyHBomb;25612500][cpp]class PhysicsThread
{
void run()
{
//update physics objects
physEngine.update();
}
};

//Somewhere in main game thread
update()
{
physThread.join(); //waits untill the thread stops execution

//update game objects etc

physThread = boost::thread(&PhysicsThread::Run, &physicsThreadInstance);

//rendering begins when exiting this update loop
}[/cpp][/QUOTE]

But the allocation of a new OS thread per iteration is wanted to be avoided (read the following posts).
I'd also think that this is just example-code, since for example the run-method also wasn't declared public, which I'd think it has to be ;) physicsThreadInstance will probably be a member in the real code.

[neos300]

[QUOTE=PatGlynn;25613890][url]http://code.google.com/p/chipmunk-physics/[/url] -- my favorite. Its a c api too so don't have to deal with all the c++ bs ( i like c++ but its almost always a pain to deal with api's exposed as c++ )

[editline]24th October 2010[/editline]

But the problem your having is you need to put a const and & for b2Vec2
[cpp]
bc_Game::bc_Game(const b2Vec2 &grav, bool sleep) : box_world(grav, sleep)[/cpp]

and looks like you didnt define the deconstructor.[/QUOTE]
Nope, I did.

Still not working.
And cmake is giving me crap apparently for having devKitPro installed, so I can't build the library.
Gonna go look at chipmunk.

[ZeekyHBomb]

[QUOTE=PatGlynn;25613890][url]http://code.google.com/p/chipmunk-physics/[/url] -- my favorite. Its a c api too so don't have to deal with all the c++ bs ( i like c++ but its almost always a pain to deal with api's exposed as c++ )[/QUOTE]
Really? I never had any problems using C++ libs that I would not have had with C libs.

[QUOTE=PatGlynn;25613890]But the problem your having is you need to put a const and & for b2Vec2
[cpp]
bc_Game::bc_Game(const b2Vec2 &grav, bool sleep) : box_world(grav, sleep)[/cpp]

and looks like you didnt define the deconstructor.[/QUOTE]

The error specifies that the destructor (and constructor) of b2World is missing, not bc_Game ;)

[Darwin226]

So I decided I'd do some List vs. LinkedList testing in C#.
I filled them with 50k floats, then iterate over them and add a random number from 0 to 1 and if the total sum of that float is more than 10, I remove the element from the List/LinkedList.

The difference is HUGE. The LinkedList finishes in < 0.1 seconds while the List takes around 0.8
I know that LinkedLists are supposed to be faster when removing members but this much faster?
Seems a bit too much, so here's the code I used, it would be awesome if someone could tell me if I did anything wrong.

[cpp]
LinkedList<float> numbers = new LinkedList<float>();
Stopwatch timer = new Stopwatch();

Random rand = new Random();
timer.Start();

int i = 0;
while ( i < 50000 ) {

numbers.AddLast( 0 );
++i;
}
while ( numbers.Count > 0 ) {

LinkedListNode<float> j = numbers.First;
while ( j != null ) {

j.Value += (float)rand.NextDouble();
if ( j.Value > 10 ) {

numbers.Remove( j );
}

j = j.Next;
}

}

timer.Stop();
Console.WriteLine( timer.ElapsedTicks / (double)Stopwatch.Frequency );

List<float> numbers2 = new List<float>();
Stopwatch timer2 = new Stopwatch();

timer2.Start();

int i2 = 0;
while ( i2 < 50000 ) {

numbers2.Add( 0 );
++i2;
}
while ( numbers2.Count > 0 ) {

int j = 0;
while ( j < numbers2.Count ) {

numbers2[ j ] += (float)rand.NextDouble();
if ( numbers2[ j ] > 10 ) {

numbers2.RemoveAt( j );
}

++j;
}

}

timer2.Stop();
Console.WriteLine( timer2.ElapsedTicks / (double)Stopwatch.Frequency );
[/cpp]

[esalaka]

Over eight times faster with [B]fifty thousand values[/B]. That sounds reasonable, especially since both times are below one second.

[ZeekyHBomb]

Why do you add a random amount to the first element and remove it when it's > 10?
I'd make more sense to do something like always removing the element in the middle.

Anyways, a List in C# has its elements stored continuously iirc, meaning that if you remove an element from the middle it has to reallocate the complete memory - minus one element - and copy the old ones over - apart from the one you wanna remove.
A linked list however can simply re-link the element before and after the one you wanna remove and is done.

[bean_xp]

[QUOTE=Darwin226;25614074]
The difference is HUGE. The LinkedList finishes in < 0.1 seconds while the List takes around 0.8
I know that LinkedLists are supposed to be faster when removing members but this much faster?
Seems a bit too much, so here's the code I used, it would be awesome if someone could tell me if I did anything wrong.
[/QUOTE]
Lists are stored contiguously in memory, so when you remove an element from the middle of the list it's going to (at least), have to move everything after the element down a list index. For 50,000 elements that's a fair amount of data to remove. A linked list stores pointers with each element, removing an element is just a case of correcting one pointer.

[neos300]

After a long and ardorus process I finally managed to build box2d with Code::Blocks by stealing a supplementary project and switching out all the files for box2d and making it a static lib.

I am happy now.

[Darwin226]

[QUOTE=ZeekyHBomb;25614159]Why do you add a random amount to the first element and remove it when it's > 10?
I'd make more sense to do something like always removing the element in the middle.

Anyways, a List in C# has its elements stored continuously iirc, meaning that if you remove an element from the middle it has to reallocate the complete memory - minus one element - and copy the old ones over - apart from the one you wanna remove.
A linked list however can simply re-link the element before and after the one you wanna remove and is done.[/QUOTE]

I don't know. It just seemed more realistic XD
Ok. Now I removed the removal part (hehe...) and I'm only iterating over them a 1000 times and adding a random number. The Linked List also seems to be ~15% faster at that too but IIRC someone said that List was supposed to be a bit faster at iteration.

[PatGlynn]

[QUOTE=ZeekyHBomb;25613987]Really? I never had any problems using C++ libs that I would not have had with C libs.[/QUOTE]
It's mainly C++ libraries that have you implement anything other than interfaces that are problematic for me. class structure doesn't work for everything, and i ushually avoid c++ libraries that are heavy on that sort of thing like i hear box2D is. Got nothing against a api being writen in c++ and externed "c" entirely. Stuff like taking values by reference ( & ) also gets a bit annoying over time if the library mixes it with pointers alot in parameters. Just my opinion though, but theres definitely less options to make stuff confusing in c lol

[QUOTE]The error specifies that the destructor (and constructor) of b2World is missing, not bc_Game ;)[/QUOTE] Yea that's right, my bad. Looks like its got to do with linking then

[bean_xp]

[QUOTE=Darwin226;25614228]I don't know. It just seemed more realistic XD
Ok. Now I removed the removal part (hehe...) and I'm only iterating over them a 1000 times and adding a random number. The Linked List also seems to be ~15% faster at that too but IIRC someone said that List was supposed to be a bit faster at iteration.[/QUOTE]

The loop in which you add elements to the list will cause it to resize, this can cause it to re-allocate the list and copy it to the new memory location. With the linked list each item is stored at separate memory locations, so adding an element just links it to the end of the list.

[URL="http://msdn.microsoft.com/en-us/library/dw8e0z9z.aspx"]There is a constructor you can use which will allow you to specify the initial (internal) size.[/URL]

[Overv]

[QUOTE=neos300;25613772]Fffff Box2D again.

So I kinda got it to work, by using this.
[cpp][/cpp]
Went to sleep, got up, fixed soem non-related compile errors and got this:

In function `~bc_Game':
undefined reference to `b2World::~b2World()'
undefined reference to `b2World::~b2World()'
In function `bc_Game':
undefined reference to `b2World::b2World(b2Vec2 const&, bool)'
undefined reference to `b2World::~b2World()'
undefined reference to `b2World::b2World(b2Vec2 const&, bool)'
undefined reference to `b2World::~b2World()'

GAHHHG

Are there any other 2d physics engines that aren't complete pieces of crap?[/QUOTE]

For your information, Chipmunk Physics is derived from Box2D and is greatly lagging behind. It's missing features such as buoyancy. Other than that, just because you are new to C++ and making mistakes doesn't mean that a library is crap. Box2D is very easy to use and changing to another library isn't going to solve your lack of knowledge.

[backwardspy]

[QUOTE=Richy19;25613121]Really? even the 7th edition? it says it covers 3.0 & 3.1 openGL[/QUOTE]
Oh... it looked exactly the same as mine :P
Ignore my post then

[Darwin226]

(LinkedList)
0,01686756 fill
5,11804804

(List)
0,00890864 fill
5,53997856

There's less difference in iteration now (for some reason...) but,
it's still in the favor of the LinkedList (which apparently takes a lot
longer to fill)

[ZeekyHBomb]

[QUOTE=PatGlynn;25614263]It's mainly C++ libraries that have you implement anything other than interfaces that are problematic for me. class structure doesn't work for everything, and i ushually avoid c++ libraries that are heavy on that sort of thing like i hear box2D is. Got nothing against a api being writen in c++ and externed "c" entirely. Stuff like taking values by reference ( & ) also gets a bit annoying over time if the library mixes it with pointers alot in parameters. Just my opinion though, but theres definitely less options to make stuff confusing in c lol[/QUOTE]
Bad design isn't really the fault of the language, unless the language doesn't really let you design a decent interface. But with C++ that is quite possible.
It's not like I used many libraries, but the ones I have used didn't have inconsistencies and normally decent interfaces.
Well, OGRE seems to use pointers everywhere for some reason. Maybe they fear having to return NULL? Dunno.

Also, about mutexes:
[QUOTE=ZeekyHBomb;25613954][QUOTE=PatGlynn;25613832]With the first block of code, Yes it would happen. But you cannot count on the lock in myThread being called prior or after the lock being called in main. So if you did that you might lock that mutex and the thread wouldnt execute anything past the lock call untill it was unlocked ( or if it unlocked prior to the thread ever calling lock )[/QUOTE]
Is this for mutexes in general or just the mutexes of the WinAPI?[/QUOTE]
Maybe you missed it. I'd really like to know and I couldn't find anything related using Google :eng99:

[QUOTE=Darwin226;25614228]I don't know. It just seemed more realistic XD
Ok. Now I removed the removal part (hehe...) and I'm only iterating over them a 1000 times and adding a random number. The Linked List also seems to be ~15% faster at that too but IIRC someone said that List was supposed to be a bit faster at iteration.[/QUOTE]

Post code.

[Darwin226]

[url]http://pastebin.com/U9DqHH4F[/url]

[ZeekyHBomb]

Yeah, you should add all the numbers to the list, then start the timer and begin accessing the list members.
By list I mean both the LinkedList as well as the List of course.

[PatGlynn]

[QUOTE=Overv;25614369]Chipmunk Physics is derived from Box2D and is greatly lagging behind.[/QUOTE]
It was inspired by and basically uses Box2D's 2D spacial hashing. But I mean it's not like they took Box2D and just ported it to C. But they are very similar, each has advantages. Like chipmunk is faster, Box2D supports more features.

But how do you think its lagging behind?

[Overv]

[QUOTE=PatGlynn;25614666]It was inspired by and basically uses Box2D's 2D spacial hashing. But I mean it's not like they took Box2D and just ported it to C. But they are very similar, each has advantages. Like chipmunk is faster, Box2D supports more features.

But how do you think its lagging behind?[/QUOTE]

From the features list it looks like that's exactly what happened. The thing is that Box2D has been around for a longer time and has a lot more features, which is why you should use that. I doubt the speed difference is that big.

[Darwin226]

[QUOTE=ZeekyHBomb;25614563]Yeah, you should add all the numbers to the list, then start the timer and begin accessing the list members.
By list I mean both the LinkedList as well as the List of course.[/QUOTE]

I do that. I measure the time it takes to add all the number and then restart the timers to measure the time it takes to do the iterations.

[PatGlynn]

[QUOTE=ZeekyHBomb;25614502]
Maybe you missed it. I'd really like to know and I couldn't find anything related using Google :eng99:
[/QUOTE]

Well I used to work for Novint Technologies. We depended on Window's critical sections alot which are basically a mutex but not shared between processes. But i've done some iphone work that has depended on posix mutexes before as well and tested that they work the right way.

When you call lock you are saying this thread owns control of this mutex. when something else calls lock on that same mutex while something else owns control of the mutex it waits for the mutex to be unlocked by the thread locking it before continuing execution. When a third thread comes into play it basically gets put behind the lock call of the second. So once the mutex is unlocked by a thread the thread continues to go through updating, but immediately if there was any thread that called lock while the thread was locked by another thread gets resumed. and that thread needs to unlock to resume any other threads on it. With winapi Critical Section lock == EnterCriticalSection, unlock == LeaveCriticalSection try_lock == TryEnterCritcalSection .

But really what i was saying is and have ran into before is when you create a thread whether in CreateThread (winapi) or pthread_create (posix) you're not guaranteeing any bit of the function is executed by the time the next instruction takes place on the owner thread creating the new one.

Like in the snippet you posted you had the thread right away do a lock and then right after creating the thread you call lock. So theres no way to plan for what lock gets hit first, Just you'll know that between lock and unlock calls that anything else that calls lock on that mutex isnt going to be executing.

[jA_cOp]

[QUOTE=ZeekyHBomb;25614563]Yeah, you should add all the numbers to the list, then start the timer and begin accessing the list members.
By list I mean both the LinkedList as well as the List of course.[/QUOTE]

He's restarting the timer between filling and iteration, though?

Also, when you see code like:
[cpp]
int b2 = 0;
while(b2 < 1000)
{
...
++b2;
}
[/cpp]
You should really just do:
[cpp]
int b2 = 0;
for(int b2 = 0; b2 < 1000; ++b2)
{
...
}
[/cpp]

[ZeekyHBomb]

[QUOTE=Darwin226;25614824]I do that. I measure the time it takes to add all the number and then restart the timers to measure the time it takes to do the iterations.[/QUOTE]

Oh, I missed the restart-call.
Try using an enumerator (or simply a foreach).

[neos300]

Okay now this is just weird.
I'm trying to get the position of a b2Body using GetPosition. Intellisense say's it isn't a member of b2Body. Compiling and looking through the source confirms it exists. (The actual function code is in a .h file, which may be the probelm) However, when I run the code it just bugs out. Running it through the debugger hasn't helped at all either.

[jA_cOp]

[QUOTE=neos300;25615008]Okay now this is just weird.
I'm trying to get the position of a b2Body using GetPosition. Intellisense say's it isn't a member of b2Body. Compiling and looking through the source confirms it exists. (The actual function code is in a .h file, which may be the probelm) However, when I run the code it just bugs out. Running it through the debugger hasn't helped at all either.[/QUOTE]

Why does it matter if intellisense failed you, as long as it compiles?

Also, declarations (and type definitions) go in header files. That's the way it's supposed to be. The actual function and data definitions are found by the linker if you supplied the relevant libraries.

[editline]24th October 2010[/editline]

[QUOTE=ZeekyHBomb;25614972]Oh, I missed the restart-call.
Try using an enumerator (or simply a foreach).[/QUOTE]

That could help if it skips bounds-checking for every step, but the difference is still going to be tiny since he's not going to run into any caching problems the way he allocates right now.

[PatGlynn]

[QUOTE=Overv;25614753]From the features list it looks like that's exactly what happened. The thing is that Box2D has been around for a longer time and has a lot more features, which is why you should use that. I doubt the speed difference is that big.[/QUOTE]
Well you should try it haha, switching from box2D to chipmunk was probably the best thing i could do for my iPhone app which gained about 8 more frames a second because it rarely had to play catchup with the time steps. I follow chipmunk development a great deal and i can assure you its not a port of Box2d to C. It's based around the same 2D space hashing method Box2D invented, but thats really where the differences end besides them both being 2D physics engines.

[r4nk_]

Thanks Zeeky and PatGlynn for all your help, really interesting solutions and much more elegant than my shitty wait and interrupt system. :love:
And sorry it took so long to get back to you guys, I was fighting a stupid compiling error which for some fucking reason will crash my program unless I set boost::thread to use a DLL instead of statically linking.

Here is a reusable version of Zeekys code:

[cpp]
class RestartableThread
{
public:
RestartableThread()
{
runThread.lock();
worker = boost::thread( boost::bind(&RestartableThread::threadMain, this) );
}

virtual ~RestartableThread(){}

void join()
{
updateFinished.lock();
updateFinished.unlock();
}

void start()
{
updateFinished.lock();
runThread.unlock();
}

void threadMain()
{
while( true )
{
runThread.lock();

run();

updateFinished.unlock();

runThread.lock();
runThread.unlock();
}
}

private:
boost::mutex runThread;
boost::mutex updateFinished;
boost::thread worker;

protected:
//You must implement this yourself, basically your thread main
virtual void run() = 0;
};[/cpp]

[VeryNiceGuy]

More progress on Groove.
[img]http://filesmelt.com/dl/GrooveUpdate3.PNG[/img]

[neos300]

[QUOTE=jA_cOp;25615075]Why does it matter if intellisense failed you, as long as it compiles?

Also, declarations (and type definitions) go in header files. That's the way it's supposed to be. The actual function and data definitions are found by the linker if you supplied the relevant libraries.

[editline]24th October 2010[/editline]

That could help if it skips bounds-checking for every step, but the difference is still going to be tiny since he's not going to run into any caching problems the way he allocates right now.[/QUOTE]
I know that about header files, but here is whats in the header file:

[cpp]
class b2Body
{
//stuff
const b2Transform& GetTransform() const;
//more stuff
};
//stuff
inline const b2Vec2& b2Body::GetPosition() const
{
return m_xf.position;
}
//even more stuff
[/cpp]

ALL of that stuff is in b2Body.h
And whenever I call GetPosition it just crashes on me.

[Torquil]

[QUOTE=VeryNiceGuy;25615283]More progress on Groove.
[img_thumb]http://filesmelt.com/dl/GrooveUpdate3.PNG[/img_thumb][/QUOTE]
Should be spelt 'Align' in the top bar. Other than that, line numbers would be a nice touch, although I recall they are difficult to do.