![]() This can be worked around with some trickery and magic, but that's stuff I wouldn't expect someone without much GPU programming experience to know how to do (which I presume Toady has none). Maybe it could, but I would expect it to have serious performance problems due to poor memory locality. Most people seem to believe that pathfinding is the worst offender, but I don't think it could really be moved to a GPU. If your problem doesn't match the architecture, expect it to run orders of magnitude slower (been there, done that). If your problem only mostly matches the GPU's architecture, then you will probably see some small speed up (maybe 5x for that section of the program). If you have a problem that is well suited to using it, then you'll see tremendous benefit. I've written a fair number of accelerators on GPUs, and even with high level libraries it can be challenging to get any speedup at all from a GPU. It makes sense from his POV to not do it right now, although I would strongly encourage him to explore this option eventually.Īs far as using GPUs for this. I have no doubt that things like pathfinding or temperature calculations could be done in a multithreaded manner, but it might require a substantial rewrite of how it works, and if you're not experienced with writing multithreaded stuff (Toady isn't), then it will possibly add lots of new bugs, and possibly not be any faster. It's kind of hard to guess how this could really be improved without a significant (although maybe acceptable for some) loss of precision. It's able to get playable FPS with hundreds of units and many thousands of items to keep track of. Which is a shame, but without knowing how the game works internally I have no idea if it could be done with any level of relative ease.Īnother thing to consider is that aside from the lack multithreading, I'd say that DF is remarkably efficient. In particular Toady has stated at least once that he's probably not going to multithread DF any time soon, if ever. Unfortunately the nebulous concept of complete here is something I doubt even Toady can agree on. ![]() So I imagine his intention is to optimize features heavily once they are more or less complete. ![]() On one hand this makes sense: if he's going to go back and change existing code when new features are added, it doesn't make a lot of sense to 'waste' time optimizing it heavily. Toady seems content to work toward making the game more complete first, and although I have no doubt he optimizes as he goes along, he probably keeps this mostly restricted to the code he's working on, not older stuff (which probably contributes more to FPS death).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |