What Are You Working On? V13

[Chandler]

Hey Zeeky, thanks for pointing out my mistake earlier. Total disregard for control flow on my part.

[cpp]
namespace {

typedef std::pair<std::vector<std::string>, std::vector<std::string> > item_pair;

item_pair get_items(const std::string& path)
{
item_pair items;
/* once you herp, you just can't */
DIR* dirp = NULL;
if ((dirp = opendir(path.c_str())))
{
dirent* direntp = NULL;
while ((direntp = readdir(dirp)))
{
std::string name = path;
path.append("/"); // might be able to remove this, must test later.
path.append(direntp->d_name);
struct stat stat_buffer;
switch (direntp->d_type)
{
case DT_DIR:
if (strcmp(direntp->d_name, ".") == 0 || strcmp(direntp->d_name, "..") == 0) { break; }
items.first.push_back(direntp->d_name);
break;
case DT_REG:
items.second.push_back(direntp->d_name);
break;
case DT_LNK:
if (stat(name.c_str(), &stat_buffer) == -1) { break; }
if (stat_buffer.st_mode & S_IFDIR) { items.first.push_back(direntp->name); }
else if (stat_buffer.st_mode & S_IFREG) { items.second.push_back(direntp->name); }
else { /* do nothing, because it isn't a file or directory */ }
break;
default: break;
}
}
(void)closedir(dirp);
}
return item_pair;
}

} /* internal linkage */
[/cpp]

[backwardspy]

[QUOTE=Richy19;25602026]Just wondering but is this book any good for learning OpenGL?
[url]http://www.amazon.co.uk/OpenGL-Programming-Guide-Official-Learning/dp/0321552628/ref=sr_1_1?ie=UTF8&qid=1287875903&sr=8-1[/url][/QUOTE]
I have that book, or rather my dad does. I just borrowed it.

It teaches old, deprecated OpenGL, but then again most of them do as far as I can see

[Greendead]

I'm working on a game in Java. It's actually 2-D game in Netbeans. It's called memory. Most of you people already know this game.

I know that here are some really hardcore programmers and doing 3D stuff already, but I'm only a beginner and I'm quite happy with the current project I have.

Here are some pics(Language is slovenian, since I'm doing this for school):

[img]http://filesmelt.com/dl/Capturejava1.JPG[/img]
[img]http://filesmelt.com/dl/java2.JPG[/img]

Keep in mind that this is a way early version. I have to complete this project until May 2011, so I still have a lot of time to make it better and bigger.

I had a problem with random generator for cards to randomly get their position. And also have a pair. It was quite hard to figure it out, how to do it. But with some table programming, I finished that.

I have a few different mods in mind, like challenge mode, timer mode, topic mode(nature, animals, people, cities,...), find a treasure, etc.
I also had an idea to add achivements, but first, I'll complete the program, then I'll add them(If they will fit in there).
That's mostly it.

[Zeonho]

[QUOTE=Greendead;25611549]
...
Keep in mind that this is a way early version. I have to complete this project [b]until May 2010[/b], so I still have a lot of time to make it better and bigger.
...
[/QUOTE]
:raise:

[Greendead]

[QUOTE=Zeonho;25611626]:raise:[/QUOTE]

Crap, wrong year. Thanks for that.

[Chandler]

[QUOTE=Chris220;25611497]I have that book, or rather my dad does. I just borrowed it.

It teaches old, deprecated OpenGL, but then again most of them do as far as I can see[/QUOTE]

Best OpenGL books you can get are OpenGL superbible 4th and 5th edition. 4th edition teaches the older 1.x API, but also goes into 2.0 for the second half of the book.

The 5th editions covers *only* 3.0.
There are no books available at the moment for opengl 4

[r4nk_]

Guys is this the correct way to thread a section of a game per frame?
I assume that creating a new thread each frame for the same operation is stupid and costly so I can't use join() or yield(). So you'd have to have a worker class with a mutex on a workFinished bool, and and inside that thread you set that to true when it finishes the work and sleep, waiting for an interrupt. Then in the main thread you'd check if workFinished and if not you sleep until it is, then you do your shit and then interrupt the thread telling it to get started on its work again. Pseudo code below (I'll be using boost::thread) :

[cpp]
class PhysicsThread
{
void run()
{
if(workFinished) sleep(100); //Will be interrupted in main thread

//update physics objects
physEngine.update();

workFinished = true;
}

bool isFinished();
};

//Somewhere in main game thread
update()
{
while( !physThread.isFinished() ) sleep(1);

//update game objects etc

physThread.startWork(); //Interrupts and sets workFinished = false

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

Is this the right way, or am I completely off?

[editline]24th October 2010[/editline]

[QUOTE=Greendead;25611549]I know that here are some really hardcore programmers and doing 3D stuff already, but I'm only a beginner and I'm quite happy with the current project I have.[/QUOTE]

I for one love to see beginner projects. I hope other beginners aren't discouraged from posting their stuff. Looks good, keep it up.

[bromvlieg]

[QUOTE=Dj-J3;25603456]Make it easier to find things? For example categorizing.[/QUOTE]
[IMG]http://i.imgur.com/I5eyv.png[/IMG] Thanks

Edit:
R4nk_, it might be better to check the time it started, on that way it wil always start working each 100 sec, else if it takes too long once it delays?

[r4nk_]

[QUOTE=bromvlieg;25611962]Edit:
R4nk_, it might be better to check the time it started, on that way it wil always start working each 100 sec, else if it takes too long once it delays?[/QUOTE]

Not really sure what you mean by check the time it started, but that sleep 100 was just there because I needed to type something. I intend to make it sleep forever until it gets an interrupt.

[ZeekyHBomb]

[QUOTE=Chandler;25611049]Hey Zeeky, thanks for pointing out my mistake earlier. Total disregard for control flow on my part.

[cpp]
namespace {

typedef std::pair<std::vector<std::string>, std::vector<std::string> > item_pair;

item_pair get_items(const std::string& path)
{
item_pair items;
/* once you herp, you just can't */
DIR* dirp = NULL;
if ((dirp = opendir(path.c_str())))
{
dirent* direntp = NULL;
while ((direntp = readdir(dirp)))
{
std::string name = path;
path.append("/"); // might be able to remove this, must test later.
path.append(direntp->d_name);
struct stat stat_buffer;
switch (direntp->d_type)
{
case DT_DIR:
if (strcmp(direntp->d_name, ".") == 0 || strcmp(direntp->d_name, "..") == 0) { break; }
items.first.push_back(direntp->d_name);
break;
case DT_REG:
items.second.push_back(direntp->d_name);
break;
case DT_LNK:
if (stat(name.c_str(), &stat_buffer) == -1) { break; }
if (stat_buffer.st_mode & S_IFDIR) { items.first.push_back(direntp->name); }
else if (stat_buffer.st_mode & S_IFREG) { items.second.push_back(direntp->name); }
else { /* do nothing, because it isn't a file or directory */ }
break;
default: break;
}
}
(void)closedir(dirp);
}
return item_pair;
}

} /* internal linkage */
[/cpp][/QUOTE]

np mang ^^

btw, no need to initialize dirp and direntp to NULL. In fact, you could initialize dirp straight away with opendir(path.c_str()).

[QUOTE=Chris220;25611497]I have that book, or rather my dad does. I just borrowed it.

It teaches old, deprecated OpenGL, but then again most of them do as far as I can see[/QUOTE]

[quote]The Official Guide to Learning OpenGL, [b]Versions 3.0 and 3.1[/b][/quote]
OGL 3 ain't too old.

[QUOTE=r4nk_;25611917]Guys is this the correct way to thread a section of a game per frame?
I assume that creating a new thread each frame for the same operation is stupid and costly so I can't use join() or yield(). So you'd have to have a worker class with a mutex on a workFinished bool, and and inside that thread you set that to true when it finishes the work and sleep, waiting for an interrupt. Then in the main thread you'd check if workFinished and if not you sleep until it is, then you do your shit and then interrupt the thread telling it to get started on its work again. Pseudo code below (I'll be using boost::thread) :

[cpp]
class PhysicsThread
{
void run()
{
if(workFinished) sleep(100); //Will be interrupted in main thread

//update physics objects
physEngine.update();

workFinished = true;
}

bool isFinished();
};

//Somewhere in main game thread
update()
{
while( !physThread.isFinished() ) sleep(1);

//update game objects etc

physThread.startWork(); //Interrupts and sets workFinished = false

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

Is this the right way, or am I completely off?[/QUOTE]

[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.start();

//rendering begins when exiting this update loop
}[/cpp]
Should be as simple as that.

[r4nk_]

But how do you start the boost::thread again? There is no start function and looking through the docs I can't see any obvious member function that makes it run its thread function again?

[bromvlieg]

[QUOTE=r4nk_;25612050]Not really sure what you mean by check the time it started, but that sleep 100 was just there because I needed to type something. I intend to make it sleep forever until it gets an interrupt.[/QUOTE]

you store the ms it started, (miliseconds) then you do a while loop, while (ms + 100 < currenttime){} and after this, you restart it, like

while (true){
     double ms = currenttime.miliseconds;
     while (ms + 100 < currenttime.miliseconds){}
     WorkerThingy();
}

something semiliere to that

Edit: dint see it had a next page :(

[jA_cOp]

[QUOTE=r4nk_;25612149]But how do you start the boost::thread again? There is no start function and looking through the docs I can't see any obvious member function that makes it run its thread function again?[/QUOTE]

I'm fairly sure boost::thread doesn't have that functionality for portability reasons. If your system supports it, you can use the native_handle() member function to get a workable handle. For example, on Windows, there's SuspendThread and ResumeThread.

[ZeekyHBomb]

[QUOTE=r4nk_;25612149]But how do you start the boost::thread again? There is no start function and looking through the docs I can't see any obvious member function that makes it run its thread function again?[/QUOTE]

I see.
[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]

[jA_cOp]

[QUOTE=ZeekyHBomb;25612500]I see.
[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]

That's going to reallocate the entire thread stack for every frame...

[ZeekyHBomb]

Is creating a boost::thread expensive?
There shouldn't be much copying, due to RVO and move assignment; boost::threads have no copy assignment and the docs don't specify anything about needing C++0x and uses thread_move_t instead of the expected boost::thread&& syntax, so I think they're doing some magic to make it work for C++98.

[jA_cOp]

[QUOTE=ZeekyHBomb;25612573]Is creating a boost::thread expensive?
There shouldn't be much copying, due to RVO and move assignment; boost::threads have no copy assignment and the docs don't specify anything about needing C++0x and uses thread_move_t instead of the expected boost::thread&& syntax, so I think they're doing some magic to make it work for C++98.[/QUOTE]

I know it has move semantics, which is good, but unrelated. You're still creating a new boost::thread every frame, which means a different thread with a different thread ID, which means it needs to create a fresh OS thread.

[ZeekyHBomb]

[QUOTE=jA_cOp;25612605]which means it needs to create a fresh OS thread.[/QUOTE]

Ahh, of course.
[cpp]class PhysicsThread
{
public:
void start()
{
updateFinished.lock();
runThread.unlock();
}

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

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

//update physics objects
physEngine.update();

updateFinished.unlock();

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

private:
boost::mutex runThread;
boost::mutex updateFinished;
};

//Somewhere in main game thread
update()
{
physicsThreadInstance.waitForFinish();

//update game objects etc

physicsThreadInstance.start();

//rendering begins when exiting this update loop
}[/cpp]
I think that would work.

[Richy13]

[QUOTE=Chris220;25611497]I have that book, or rather my dad does. I just borrowed it.

It teaches old, deprecated OpenGL, but then again most of them do as far as I can see[/QUOTE]

Really? even the 7th edition? it says it covers 3.0 & 3.1 openGL

[PatGlynn]

[QUOTE=ZeekyHBomb;25612809]Ahh, of course.
[cpp]class PhysicsThread
{
public:
void start()
{
updateFinished.lock();
runThread.unlock();
}

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

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

//update physics objects
physEngine.update();

updateFinished.unlock();

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

private:
boost::mutex runThread;
boost::mutex updateFinished;
};

//Somewhere in main game thread
update()
{
physicsThreadInstance.waitForFinish();

//update game objects etc

physicsThreadInstance.start();

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

You probably only want one mutex. What your doing there with the wait doesnt really stop the thread from executing again after waiting. Something like the below would work

[cpp]
class PhysicsThread
{
public:
PhysicsThread() : killMe(false), threadDead(true) { }

void pause() { physicsMutex.lock(); }
void resume() { physicsMutex.unlock(); }

void loop() {
threadDead = false;
while(!killMe)
{
// wilderness here
physicsMutex.lock();
// do whatever physics specific updating here.
physicsMutex.unlock();
}
threadDead = true;
// do not stick any code below this line. as if kill me is true this thread should exit.
// small chance that we could have set killMe to true between lock and unlock calls in the while loop ( see wilderness here comment ) -- do not do any kind of shut down methods here.
}

~PhysicsThread() {
while(!threadDead){
killMe = true;
physicsMutex.lock();
physicsMutex.unlock();
}
// at this point you should be pretty confident that the thread has finished
}

private:
boost::mutex physicsMutex;
bool killMe;
bool threadDead;
};

//Somewhere in main game thread
update()
{
physicsThreadInstance.pause();

//update game objects etc

physicsThreadInstance.resume();
}
[/cpp]

But this still doesnt deal with creating the thread itself. You'll have to create a thread to run the loop function though. With the
void waitForFinish()
{
updateFinished.lock();
updateFinished.unlock();
}
That wouldn't stop the update thread from continuing, so you would basically have the calling thread wait for the thread locking the mutex and then unlock it right away. This could be good for say like a job/worker thread boosting priority to whatever is left. but if you need the data between the two threads to be shared you wouldn't want to unlock again right away like you are there. Theres better ways to handle the shutdown/deconstruction i put up there too, if you can join the thread ( like pthread_join (posix) or WaitForSingleObject (winapi) ) thats a sure thing and takes alot of the unsecure logic out like threadDead.

[r4nk_]

The problem with these is that I [i]think[/i] they will run multiple times if the physics update is faster than the rendering...

[ZeekyHBomb]

It does stop execution, due to the runThread-mutex being locked until a call to start().
Your loop-function might execute several times in a row, without it being halted. It was my understanding that only one iteration should happen upon each call to a start-function.

[editline]24th October 2010[/editline]

:ninja:
I think mine only does one iteration per start().

[PatGlynn]

[QUOTE=r4nk_;25613261]The problem with these is that I [i]think[/i] they will run multiple times if the physics update is faster than the rendering...[/QUOTE]
Thats the idea i would think. If you have render world and physics world, You don't want to throttle them together if your using multiple threads. You should just be concerned about when it comes time to render, physics world isnt modifying data while render world is polling physics world.

But with mutexes if one thread has the mutex locked and another thread calls lock() it keeps order of what thread is queued next.

You still have to have some sort of system for time stepping your physics in place as far as like delta or a fixed time step. Physics in most cases shouldn't be running constantly but if other stuff takes up enough time for two physics updates thats a good thing that those two physics updates can occur. More so now with multiple core processors being so popular. But of course with any code, you should always shoot for execution to be fast. And if your trying to throttle by doing a fixed time step with physics then you don't need to block the mutex at all.

[editline]24th October 2010[/editline]

[QUOTE=ZeekyHBomb;25613293]It does stop execution, due to the runThread-mutex being locked until a call to start().
Your loop-function might execute several times in a row, without it being halted. It was my understanding that only one iteration should happen upon each call to a start-function.

[editline]24th October 2010[/editline]

:ninja:
I think mine only does one iteration per start().[/QUOTE]

It gets halted by the mutex. when you call lock and something else owns the lock it waits. the loop function is the thread basically. But again i mean i am not a long time user of boost so i'm not sure how they implemented it. But most of the time when you refer to a thread, its like having another main function.

If your using a thread to do a single iteration along side whatever else is going on then it works to create the thread every time you need to update. Then you call join when you need that thread to be done ( wait or not). Either way after your calling thread calls join you can be confident that the created thread isnt executing anymore. And you shouldn't need any mutex with this approach.

[editline]24th October 2010[/editline]

But whatever works, Threading is a pain in general most of the time :)

[ZeekyHBomb]

[QUOTE=PatGlynn;25613405]But with mutexes if one thread has the mutex locked and another thread calls lock() it keeps order of what thread is queued next.[/QUOTE]

Are you sure about that?
So, this cannot be the case:
[cpp]boost::mutex mutex;
void myThread()
{
while(true)
{
mutex.lock();
mutex.unlock();
}
}

int main()
{
boost::thread(&myThread);
mutex.lock(); //might never happen
}[/cpp]
?

[QUOTE=PatGlynn;25613405]If your using a thread to do a single iteration along side whatever else is going on then it works to create the thread every time you need to update. Then you call join when you need that thread to be done ( wait or not). Either way after your calling thread calls join you can be confident that the created thread isnt executing anymore. And you shouldn't need any mutex with this approach.[/QUOTE]

The point was not needing to create a new thread for each iteration you need to do.
Have one thread, do one iteration, wait.
[cpp]update()
{
physicsThread.join();
//update game objects
physicsThread.start();
//render
}[/cpp]
Thing is, boost::threads don't have a start member.

[Dlaor-guy]

[QUOTE=deloc;25605804][img_thumb]http://imgur.com/nZ6wE.gif[/img_thumb]
took a little over a minute to render. i could probably speed up the marching using some d&c technique.[/QUOTE]
Trippy.

[neos300]

Fffff Box2D again.

So I kinda got it to work, by using this.
[cpp]
bc_Game::bc_Game(b2Vec2 grav, bool sleep) : box_world(grav, sleep)
{
box_timestep = 1.f/60.f;
velocityIter = 10;
posIter = 10;
box_gravity.Set(0.f, -10.f);
box_sleep = true;
//box_world(box_gravity, box_sleep);
//b2World temp_world(box_gravity, box_sleep);
//box_world = temp_world;
//box_world = b2World(box_gravity, box_sleep);
}
[/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?

[esalaka]

Lemme guess: You didn't link the libraries in?

[PatGlynn]

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 )

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?

[neos300]

[QUOTE=esalaka;25613803]Lemme guess: You didn't link the libraries in?[/QUOTE]

It didn't come with any libraries.... just the source...

I'm such an idiot, I have to build the library don't I?

That would explain why the demo hello world doesn't compile.

[PatGlynn]

[QUOTE=neos300;25613772]
Are there any other 2d physics engines that aren't complete pieces of crap?[/QUOTE]
[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]

[QUOTE=neos300;25613772]Fffff Box2D again.[/QUOTE]

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.