Hot answers tagged multithreading
67
Any system which had a thread for each of so many characters would run out of resources very quickly. Threads may give you access to extra processor cores but they don't make anything intrinsically more efficient, and they come with overhead.
The simple answer is just to be efficient about processing each entity in the game.
Don't process every entity ...
41
Dwarf Fortress is not open source, and while there is a lot of conjecture and reverse engineering that can go into how that all works, I will instead focus on some basic techniques for optimizing a 3D (not 3D graphics, 3D world) roguelike of the same type.
As is the case with all video games there are a lot of smoke and mirrors that are creating the ...
36
From this page:
Well [the pathfinding] looks amazing from my end, since there's a metric ton of characters all doing it at once.
TA: The dwarves themselves mostly move around with A*, with the regular old street-distance heuristic. The tricky part is that it can't really call A* if they don't know they can get there in advance, or it'll end up ...
26
I may be wrong, but your question makes it seem like you are missing a lot of knowledge in order to successfully write an MMO server. I know this message will likely fall on deaf ears because I was in your position when I started programming.
My answer:
If I were you I would start smaller. If you want to learn to write an MMO server I would do the ...
20
There's a couple things to consider. The thread-per-subsystem route is easy to think about since the code separation is pretty apparent from the get go. However, depending on how much intercommunication your subsystems need, inter-thread communication could really kill your performance. In addition, this only scales to N cores, where N is the number of ...
16
If anything, it's the opposite - the whole thing runs on one thread and it's now hitting the point where that is becoming the blocking factor (last time I checked!)
The reason it's fast is that there's no fancy graphics. It's deceptive, but the main thing that slows stuff down is drawing things (think upwards of two thirds of a frame in AAA titles). Since ...
14
The common approach for taking advantage of multiple cores is, frankly, just plain misguided. Separating your subsystems into different threads will indeed split up some of the work across multiple cores, but it has some major problems. First, it's very hard to work with. Who wants to muck around with locks and synchronization and communication and stuff ...
13
I highly recommend that you have a render thread (using Canvas/OpenGL ES, Canvas is probably a little bit easier to setup) and a game thread where you put your game logic.
To actually "load" the game you can create a GameEngine class and make that the central point of your application. When your renderer is ready to go you can create a callback to the ...
12
Basicly, the xbox 360 has 6 hardware threads, spread over 3 cores. Two of these are reserved for the xna framework and general system use. Threading works the same as it does on the .net framework on windows,except you get an extra methods, SetProcessorAffinity. Unlike windows, the xbox dosnt do any fancy thread scheduling for you, so you have to tell it ...
12
That question has no best answer, as it depends upon what you are trying to accomplish.
The xbox has three cores and can handle a few threads before context switching overhead becomes a problem. The pc can deal with quite a few more.
A lot of games have typically been single threaded for ease of programming. This is fine for most personal games. The ...
12
Google's Chris Pruett talks about this issue in his Replica Island blog. Because eglSwapBuffers() is a blocking call in the GLSurfaceView thread, having game logic code in another thread allows it to run while the swap buffers call is blocking. This is important if your game is complex and you want to achieve 60 frames per second.
You can download the ...
12
You propose running each separate "system" in parallel. The problem with this is that you will have to lock every single piece of shared state. CLARITY EDIT: When you have two parallel operations using all of the same data, lock contention and synchronization is going to slow things down so that you're not gaining many benefits from the parallelization.
...
11
You talk about "multithreading difficulties" but what difficulties are you actually talking about? In a way you're citing a phantom problem which may not even exist. The real challenge is one you make for yourself - if you are absolutely determined to get every last drop of power out of a piece of hardware, that does involve using the hardware to best ...
9
You are right that the most critical part is to avoid synchronization wherever possible. There are a few ways to achieve this.
Know your data and store it in memory according to your processing needs. This enables you to plan for parallel calculations without the need of synchronization. Unfortuantely this is most of the time quite hard to achieve as the ...
8
Without looking at your code, the only thing I can suggest is to make your graph coarser. So I would plan the route in 2 steps:
given desired route:
If you find the route (from the o to the x) using the full graph (with 1 graph node per tile in this case) it would be more expensive than it needs to be.
Consider the following (more sparse) set of graph ...
8
You have to create the threads yourself, using your threading library of choice (boost, C++11 async, Windows threads, etc). The idea is that you will create several threads and split up your CPU rendering work amongst them. Each thread uses a D3D11 deferred context to accumulate all the D3D11 commands (state changes, draw calls, etc.) it wants to execute. ...
7
A thread per subsystem is the wrong way to go. Suddenly, your app won't scale because some subsystems demand a lot more than others. This was the threading approach taken by Supreme Commander and it didn't scale beyond two cores because they only had two subsystems that took up a substantial amount of CPU- rendering and physics/game logic, even though they ...
7
MUD cycles are generally not there because the server has trouble processing everything within the available time or serving network requests fast enough. They are there because spamming commands as fast as possible should not be a valid tactic.
Simply have a cooldown / charge-up timer associated with each ability. Depending on your social design this might ...
7
If your game is going to be remotely hardware intensive then you need threads to cope with all modern hardware; future CPUs coming out in the next year or two are starting to make 4 cores the minimum and up to 16 cores common for enthusiast/performance markets. If you're doing any multi-threading at all, definitely do a task-oriented architecture as any ...
7
Do you think it would be a good idea to have each part of the screen (game session) handled by different thread?
When it comes to rendering: No!
OpenGL and multithreading don't mix well. It's best practice to keep all OpenGL operations to one single thread.
7
Normally, it's not that common to split up in-game logic based on entity types; this is primarily due to the fact that there needs to be interactions between different entities computed as a part of the game in most situations, and separating them into multiple threads makes synchronizing and ordering those interactions a living nightmare, as opposed to ...
6
I didn't try, but I'm a Scala programmer, and I would say that this isn't the best approach. Sprites need to be animated synchronously. Actors have no guarantees that they will be executed fairly - some sprites may thus be faster than others, which is not what you want. You might want to use a barrier to synchronize them, but then - why use actors.
If you ...
6
To your broader problem, consider trying to find ways to reduce inter-thread communication as much as possible. It's better to avoid synchronisation issues altogether, if you can. This can be achieved by double buffering your data, introducing a single-update latency but greatly easing the task of working with shared data.
As an aside, have you considered ...
6
Solution
The solution was to use a monitor like v8::Locker locker;. Exactly this line must be entered the line before the creation of the HandleScope and it should work, although my code up there is crap. I have combined all variables etc. into one method without a setup method or the variables in ScriptingEngine.
Long story short: the Locker object is ...
5
The short answer is: don't. Multithreading will give you more headaches than it saves.
Taking your example in particular:
User clicks on an item The function walkToAndPickUp(item) is called which is basically this:
I'd rethink things a bit. At any point the state contains (among other things) the PC's target location and the PC's target item.
A ...
5
You're going to want to double/triple buffer any data necessary for rendering that gets altered in the update pass. That way you won't be rendering with something that's been partially changed. The reason you'll probably need to triple buffer is needing 1) the copy you're updating, 2) the last copy you updated fully, and 3) the copy that is currently being ...
5
Usual solution for concurrency problems is data isolation.
Isolation means that every thread has its own data, and does not touch data of other threads. This way there are no problems with concurrency... but then we have problem of communication. How can these threads work together if they don't share any data?
There are two approaches here.
First one is ...
5
It's usually not a great idea to try and have different subsystems on different threads, because safe communication between them is often too expensive. I wouldn't want to have to use a mutex every time I recorded a mouse movement, for example. And putting AI in a separate thread creates a game design problem in real-time games; does this risk making the AI ...
5
When there is no path from the start to the end, the algorithm must search every possible location. This means that A* becomes as least as slow as a naive flood-fill algorithm (as it is covering the whole graph) and probably slower (as it is performing extra work to manage the queue and calculate heuristics). Optimising your algorithm is unlikely to help ...
5
I don't know how DF is coded but the amount of AIs doesn't really impress me because what people often oversee it that AI doesn't need precision. It's perfectly viable to do most stuff only every few seconds. It's also viable to use imprecise calculations. Imperfection saves a lot performance. You can run the decision making routine of 100 units every 100 ...
Only top voted, non community-wiki answers of a minimum length are eligible
