next »

[Player 3]

What a mess. SFML 2.0 relied on an outdated GLEW version and had to compile SFML from source. Cmake wasn't exactly a walk in the park either. Then there was learning how to properly install a library (sudo cp -r lib /usr once it was compiled). This probably goes in the Happy Programmer thread too, but the heck if this didn't leave me feeling grump and not so grump in the end.

[Klaim]

Why did you have to "install" the library? Couldn't you just compile it statically?

[Geti]

@Player3 I'd gloat about being on arch and installing being as easy as "yaourt sfml2" but I know those feelings and should really only offer my sympathies.

[Pineapple]

Writing a chess game because I never did before. Got all the rules set with the exceptions of castling and en passant, I'll worry about those later. Making an AI that operates on some interesting paradigm I came up with myself and want to see how it works. For some reason whenever the AI feeds the board object moves they get fucked up and I can't figure out where or how because everything seems to be functioning exactly fine up until the moment of "oops, nope, that's not the piece the AI told it to move."

 

[rivon]

What a mess. SFML 2.0 relied on an outdated GLEW version and had to compile SFML from source. Cmake wasn't exactly a walk in the park either. Then there was learning how to properly install a library (sudo cp -r lib /usr once it was compiled). This probably goes in the Happy Programmer thread too, but the heck if this didn't leave me feeling grump and not so grump in the end.

cmake
make
make install
?
Or if you use Debian-based bistro, you'd better use checkinstall (as root) instead of the "make install" to get a .deb package automatically installed, so you can easily uninstall later.

Copying the libs manually is definitely not the right way to do it

[_Tommo_]

My async job system requires all workers to be able to do the same stuff or it wouldn't be able to dispatch a task to any thread transparently... so I had to share the OpenGL context with each one.
However, wglMakeCurrent on windows randomly failed.
I spent an hour or so wondering what I might have done wrong, then I thought... what if I just put it in a loop?

The following works perfectly:

Code:

int tries = 0;
for( ; wglMakeCurrent( hdc, req.contextHandle ) == FALSE && tries < 10; ++tries ) //be nice, wglMakeCurrent just wants you to ask politely and more than once
Sleep(20);

DEBUG_ASSERT( tries < 10, "Cannot share OpenGL on this thread" );

I've benchmarked it and it fails 1 time on 7 on Intel, much less on Nvidia. Of course MSDN said nothing about this.

But hey, it's win32  

[BorisTheBrave]

The docs say a context can be current to only one thread at once. That means your tasks need to grab a mutex, call wglMakeCurrent, do work, call wglMakeCurrent again to unset the context, and release the mutex, in order to safely manipulate the context. Are you doing that? If so, why? It's near useless to have a threadpool where the tasks are fighting over a single mutex. Better to have a task queue per context.

[ThemsAllTook]

The following works perfectly:

Code:

int tries = 0;
for( ; wglMakeCurrent( hdc, req.contextHandle ) == FALSE && tries < 10; ++tries ) //be nice, wglMakeCurrent just wants you to ask politely and more than once
Sleep(20);

DEBUG_ASSERT( tries < 10, "Cannot share OpenGL on this thread" );

I've benchmarked it and it fails 1 time on 7 on Intel, much less on Nvidia. Of course MSDN said nothing about this.

Gross!

Failing 1 time in 7 doesn't quite sound like "working perfectly" to me...

My async job system requires all workers to be able to do the same stuff or it wouldn't be able to dispatch a task to any thread transparently... so I had to share the OpenGL context with each one.

This makes me wonder if your simulation logic is mixed up with your display logic. Are you sure you need to access your OpenGL context from your worker threads? Seems to me like you'd want to run just pure game logic stuff in them, and keep a single display thread that does all of your drawing.

[bateleur]

Better to have a task queue per context.

You have to be a bit careful... if putting things onto the task queue is going to be done by many threads, then it too needs a lock of some kind (eg. a mutex). This being the case there is a deadlock risk if one thread has the queue lock and wants the OpenGL context lock at the same time as another thread has the context lock and wants the queue lock, you're doomed.

Luckily the fix is simple: don't allow anything to ever hold both locks at once. If you need to read the queue then copy the result somewhere and release the lock before starting work on the dequeued task.

(When this style of fix is inapplicable what you have to do is define a strict nesting order for your multiple locks, so that you always acquire A before B before C etc. That fortunately isn't applicable here.)

[_Tommo_]

Hey people, I've done my homework I swear

The docs say a context can be current to only one thread at once. That means your tasks need to grab a mutex, call wglMakeCurrent, do work, call wglMakeCurrent again to unset the context, and release the mutex, in order to safely manipulate the context. Are you doing that? If so, why? It's near useless to have a threadpool where the tasks are fighting over a single mutex. Better to have a task queue per context.

I am creating a context per thread that shares buffers with the main context and then making it current on the owner thread only.
This way, the resources are shared but the context itself is not, and the driver is happy.
Also, this avoids the use of any mutex and/or stalls of the main threads.
It is especially nice to use to load big chunks of data which might make the main thread glitch or lag, like big textures or a-la-Minecraft tesselated procedural meshes.

Gross!

Failing 1 time in 7 doesn't quite sound like "working perfectly" to me...

wglMakeCurrent is failing 1 time in 7, however putting it in the while has always worked until now.
Indeed I never had wglMakeCurrent fail more than 1 times in a row.
If it is indeed 1 on 7, the probability of the while failing by random chance is 1/7^10, not exactly a big number.

This makes me wonder if your simulation logic is mixed up with your display logic. Are you sure you need to access your OpenGL context from your worker threads? Seems to me like you'd want to run just pure game logic stuff in them, and keep a single display thread that does all of your drawing.

Nope, it isn't.
The only thread that draws stuff is of course the main thread which owns the main context, the workers have headless contexts and are used to load or stream resources, tesselate stuff, process textures, etc.
This is inherently faster and lockless if the threads can push the resources to OpenGL without having to rely on the main thread to do it for them, obviously.
The main thread has just to avoid using those resources until they are ready (hint: std::atomic<bool> is nice, and a simple bool will do too ).

tl;dr: multithreaded OpenGL exists and works too (and you'd better start using it)!
It just needs a bit of "massaging" to work under Windows, of course, being advanced OpenGL stuff.

 

[ThemsAllTook]

The only thread that draws stuff is of course the main thread which owns the main context, the workers have headless contexts and are used to load or stream resources, tesselate stuff, process textures, etc.
This is inherently faster and lockless if the threads can push the resources to OpenGL without having to rely on the main thread to do it for them, obviously.

Ah, interesting. I've only ever done this by having the worker threads do all of the processing they can (decompress images, etc.) short of uploading to OpenGL, then letting the main thread do that. I really ought to learn more about multithreaded OpenGL one of these days.

My earlier post sounded kinda grumpy. Didn't mean it that way, sorry! Though I guess it's appropriate for this thread...

[Klaim]

In my case I got Ogre with OGL plugin running on it's own thread, the main thread manage a queue of timed tasks but sleep sometime when there's nothing to do for a long time, the rest use a task executor which is implemented using TBB's task scheduler. I also use a custom made task type which are highly augmented std::function<void()>, with thing like automatic rescheduling.
Each system have either it's own thread for task execution or use the task scheduler which will spawn tasks ASAP on any thread. One system's tasks are always executed only by one thread at a time which mean there is no sharing.

EDIT> All that talks to each other injection of tasks in system-specific scheduling interface, the tasks taking in argument the objects representing the data of the system. So it's all executed in sync with the system's update. Maybe I'll also put somewhere available the code I use to generalize monitored systems. But I'll think about it when I got more systems running with it.

So far it works well but I don't have a full game working so I'll post some blog articles when I know more about this architecture.

[_Tommo_]

Ah, interesting. I've only ever done this by having the worker threads do all of the processing they can (decompress images, etc.) short of uploading to OpenGL, then letting the main thread do that. I really ought to learn more about multithreaded OpenGL one of these days.

My earlier post sounded kinda grumpy. Didn't mean it that way, sorry! Though I guess it's appropriate for this thread...

Yeah, I see that most people come up with complicated message passing solutions and command buffering to schedule OGL ops on the main thread, which is a bit strange given that the problem doesn't exist in the first place.
I guess this comes from DX9 which is still caparbiously single-threaded even today as far as I know... so people just assume that graphics multithreading is "unsafe", which is not.

Also, command buffering isn't a real parallel solution because if you are loading a big texture your main thread *will* lock while it uploads... so even if it works performance wise it is still crap user-experience wise.

And don't worry about the grumpyness

[TheLastBanana]

A while back, I read that Adobe AIR had joystick support. "Great," I thought, "since I'll be needing that for my game."

And it does! Except only on Android devices. Well, shit.

On the bright side, there are a bunch of third-party extensions to handle it... on Windows only. Well, double shit.

So now I'm writing a program in C++ to handle joystick input so I can pipe it to Adobe AIR so I can actually use a joystick in my game. That, or I could port the game to a better language, but I think it's a bit too late for that.

[Gregg Williams]

Maybe just bundle joy2key?

[TheLastBanana]

Joy2Key isn't cross-platform as far as I'm aware. Also, my game would really benefit from full 360-degree analog control as opposed to being constrained to 45-degree increments.

[Gregg Williams]

Joy2Key isn't cross-platform as far as I'm aware. Also, my game would really benefit from full 360-degree analog control as opposed to being constrained to 45-degree increments.

Fair enough. I just know several successful games made with flash/air, have managed to get by with telling their customers to use a 3rd party program. Although I don't think any of those would handle analog input really.

[TheLastBanana]

Yeah, Binding of Isaac comes to mind (if I remember correctly, there's an button in the options menu for gamepad controls, and when you click it, it says "download Joy2Key" ). If this turns out to be a huge pain in the arse, I may just stick to mouse/keyboard input and get on with my life... but if I can go the extra mile to polish this kind of thing, I'd really like to.

I'll likely end up setting up a simple AS3 interface for this library which was posted on our very own forum! Means brushing up on my rusty C skills, but that's probably not such a bad thing anyway. It's still ridiculous that I even have to do this for something as basic as gamepad support, and for that reason I am grumpy.

[Pineapple]

I wrote a simple physics engine a while back that would be ideal for use in platformers.

Thought I'd try a really quick platformer and I'm using that engine. I don't know what I'm forgetting but it is absolutely not working how it was before as far as a player-controlled character goes.

edit: Joy, it only took about an hour to sort everything out. It works decently now.

[framk]

Doesn't it pay off in the long run to create your own version of a joy2key program if nothing exists on your platform? It seems rather shortsighted to rely on a third party program. I understand that this will increase development times, but it's ultimately about the experience of the user, and if someone playing one of my games has to exit, download another program, and then relaunch my program to experience it (not to mention the fact that you have absolutely no control over the functionality of the third party program), I would consider it a failure on my part.