Tag Info

Hot answers tagged

83

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 ...


48

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 ...


39

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 ...


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 ...


35

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 ...


34

What you have here is a classic O(n²) algorithm. The root cause of your problem has nothing to do with threading and everything to do with the fact that your algorithm has a high complexity. If you haven't come across "Big O" notation before, it basically means the number of operations required to work on n elements (this is the super-simplified ...


27

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 ...


20

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 ...


20

Ok at first glance there are some things you should try out. At first you should try to reduce your collision checks, you can do this by using some kind of spatial structure like a quadtree. This will allow you to reduce the second foreach count, as you will only query entities close the first one. Regarding your threading: Try not to create a thread every ...


15

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 ...


15

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

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. ...


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

Some intel resources. http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ http://software.intel.com/en-us/videos/dont-dread-threads-part-1/


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 ...


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 ...


10

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 ...


10

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 ...


10

As always, it depends. Audio is a very complex topic, and the details can be vastly different from API to API, and from system to system. Introduction to audio processing Note: for all the examples below, we will be considering linear PCM, at 44100Hz (samples per second), with 16-bit samples, and two channels (stereo). This is a very common configuration. ...


10

Rule number one of multithreading: Don't even think about it, unless you really need to use multiple CPU cores for performance reasons*. Multithreading opens up a whole can of worms of obscure and impossible to reproduce bugs: Race conditions! Because you have no control over the thread scheduling of the OS, you have no control over the order in which ...


10

You're right on track with using the context only from a single thread. You can only use an OpenGL context from one thread at a time, but you can do everything else in another thread. The simplest way to take advantage would be to do all the loading as you normally would, but send some kind of "event" back to your main thread to actually call the OpenGL ...


9

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 ...


9

Treat scripts like the GPU treats shaders- no global variables, limited inputs and outputs, that is, enforce thread safety via language rules.


9

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

A brief overview of Multi-threaded engine approaches. Gamasutra to the rescue. Multithreaded Game Engine Architectures Threading 3D Game Engine Basics


8

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 ...


8

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 ...


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. ...


8

Honestly, the first thing you should do is switch to a better algorithm. Parallelizing your simulation can, even in the best possible case, speed it up only by a factor equal to the number of CPUs × cores per CPU × threads per core available on your system — i.e. somewhere between 4 to 16 for a modern PC. (Moving your code to the GPU can ...



Only top voted, non community-wiki answers of a minimum length are eligible