Jump to content


WFG Retired
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by RedFox

  1. Just thought it would be nice to clear this up. Due to some disagreements with the Dev team, I decided to withdraw from the position. It's quite unfortunate, but since teamwork didn't seem to be flowing in the desired direction and we couldn't come to common terms, I feel this is the best option. The long delay from WFG led to me finding a new job and I would much rather stick to that. I have no idea what WFG will do next regarding the fundraiser money, but I'm sure they'll find some way to put it into good use.
  2. If we manage to get NAT hole punching to work, then it doesn't matter what port number the client uses. As long as the listener server has its listening port open, we can create numerous connections from client to server and use the automatically opened ports on the client.
  3. I agree Ykkrosh, it's tough working on large scale changes on such a large project - it often looks like operating cancer, really. I'd say my focus would be on reviewing and bugfixing megapatch so that all the problems get fixed. And in the future, we should definitely avoid megapatch situations, since they become increasingly difficult to maintain the longer they remain off the main svn trunk.
  4. There is no October update thread. The last work I did was the first week of October where I fixed memory leaks in the new lobby, added VS2012 support for premake4 and some bug-fixes on megapatch (no new features). And the end of September I fell quite ill and was out of action for 2 weeks; actually I've yet to fully recover - I should probably give myself more rest. Since there has yet to be any discussion on resuming paid development, I'm remaining in stand-by.
  5. Is there any further progress on this test? What kind of issues are you facing currently? Updating the navmesh? Performance issues? For grid distances you could just use the standard "manhattan distance" method. It's a simple and fast method and also gives decent results.
  6. Looking good. To avoid the worst case of A*, you'll have to do some simple heuristics like described before. An iterative flood-fill method should be pretty fast and do the trick. Running some tests with my own A* setup on reasonably complex map layouts, a 48x48 (2304 tiles) can take around ~1500 iterations to cover the map, while a 512x512 (262144) can have over 88700 iterations per A* search query. If you can reduce the number of cells tenfold from a 256x256 map (~65k -> ~6k), you'd already cut down the number iterations by a huge amount, to somewhere around ~5000 for the whole map. Looks
  7. We are actually considering moving the AI to C++ because of how badly it performs in JS. It would save us a lot of time in the long run if we started working on a new AI in pure C++ instead of expanding the JS AI. It would also solve any limitations of JS and the duplication of game state (it's a major slowdown having full gamestate duplication from C++ to JS).
  8. I think the problematic cases are when drivers have bugs and/or incorrectly implement features. Though cross-checking features would be a good way to eliminate hopeless ancient drivers.
  9. When it comes to optimization, I would rather focus on a well thought out algorithmic approach at first. Micro-optimizations as some call them shouldn't be the focus, though they shouldn't be disregarded either - a good cache locality optimization can make many algorithms several times faster. I guess the main benefit of a grid-based system is its relative sequential nature, which is better for CPU cache than other pointer based methods. Notoriously, linked lists are ridiculously slow on modern hardware, even though they are algorithmically faster for insert/remove, any simple array/vector bas
  10. Exactly. If we plan to support 10-year old hardware, then any hardware since 2005 will have OpenGL 2.0 support. The only issue can be with some non-standard compliant drivers that fail to optimize or properly compile the GLSL shaders - so far we had an issue with pre-processor not working on OSX GLSL compiler. It might be simply because people are using outdated graphics drivers. Perhaps we should compile a list of suggested drivers for every platform? It would make our life easier if we just ensured proper driver suite is installed with the game, right? As for ARB shaders, the main problem is
  11. Regarding fixed-function pipeline, we have decided already months ago that it will be dropped in future releases. So all in all, it shouldn't really be a surprise. You can get a cheap modern laptop with just 200$. I don't see any reason to support fixed function pipeline as it is, since it's a relic Look at this from another perspective - should we had incorporated MS-DOS support in 2003, just because some people somewhere still used it? Even though it was a decade-old relic already?
  12. We won't need any special treatment of enemies in the pathfinder. The hypothetical new "CollisionManager" would detect collisions and decides whether to start fighting (collide with enemy), pushing (collide with friendly), or try to find a path around the friend/foe (disengage from fights).
  13. Thank you for explaining your point of view in detail.
  14. Entities are 2D bounding boxes (since they can be buildings, units, flora, fauna...). The PFor implementation isn't entirely horrible - though it has quite a few concurrency issues. We don't use OpenMP because we already implement pthreads and there is literally no useful cross-platform library with a PFor. The patch already implements thread pools if you didn't notice, so I wouldn't worry about the implementation efficiency. Since we use C++03, the code isn't that nice. In C++11 we could get away with cool little lambdas: ps::parallel_for(0, size, [&](int atIndex) => { printf("%d
  15. The testbed used was my own private OpenGL engine and doesn't have anything special other than an interactive demo for debugging / testing. I'm quite sure that my SAP implementation isn't completely optimized in the algorithmic sense. The most expensive parts are moving elements in the axis, which forces us to update the random-access indices. I thought I could make it work, but SAP isn't meant for random access. Even the GPU + SAP demo sweeps the entire set - which is very efficient, but totally different from what we need. Now, I'm not saying our implementation is perfect - far from it actua
  16. I only have my personal prototype build (since I ditched the pyrogenesis port after it failed to give any desirable results). The code doesn't really explain much of the problems, but trying to implement random-access search with SAP was pretty much the reason it failed (since SAP is supposed to be sweeping, not random accessing). However, there is no way around this with the current design of the simulation2 engine in 0AD - we need random access. SAPDivision.h: http://pastebin.com/5Ld0QUA6 SAPDivision.cpp: http://pastebin.com/mL211s2k
  17. So the previous week was actually really tough - I spent pretty much all the time working on implementing Sweep and Prune approach and testing all sorts of configurations. There were some obvious upsides to the algorithm at first, but unfortunately it has a worst case scenario that almost always plays out in our game engine. So my final through opinion is that we can't use it for the sort of queries we're doing. So would I vote this week of 53 hours as wasted? Well, I could have used all this time for something else that didn't end up with no results. Week #7 16.09 - 22.09 16.09 08-24 (16) - S
  18. Hi MattFox, nice to see another coder throwing himself into the fray on this one. I think the best place you can start from is creating a list of features that the 0AD pathfinder needs. For example, because the game design foresees variable-cost terrain movement (slower movement in mud and bog than on grass), the amount of possible options is drastically reduced. Another big issue is unit sizes - we need a pathfinder that works from small wardogs to large elephants. When we fail to find a path, we need to provide a new path that moves as close to the target as possible. I think the main issue
  19. I'm currently working on optimizing the RangeManager, which is used for detecting objects within a certain range. The error: "SpatialSubdivision Query too large. Results truncated." is simply a safeguard I put into place to detect if we're doing ridiculously big range queries. This is one of the reasons we're having such bad performance. Right now there's no way around the issue with the old code. I'm working on a completely new solution that lowers the amount of results noticeably.
  20. Hello John. I understand that projects written in C++ seem a bit over the top for hobbyist programmers or CS undergraduates at first. However, C++ is a perfectly productive language if you know it through and through. It's true that it's harder to master than any other language out there, but the performance it offers is something you can't really compare against with scripted or GC based languages. I've worked on several game projects in the past few years and in every case we wished we would have used C++, because GC based languages such as Java or C# would cause GC cleanup spikes that reall
  21. I committed a temporary "fix" that increases the capacity to 2048. Hopefully with the new Search and Prune approach for the Range Manager, we won't stumble into this issue. You'll have to wait for the next autobuild before the issue corrects itself.
  22. Hi lars, it seems you stumbled upon a new hardcoded limit. It's something I've put into our old SpatialSubdivision class for mostly testing and ensuring that our code isn't doing anything wrong. In your case, it seems like a range query returned more than 1024 entities - a really bad case. debug_warn("SpatialSubdivision Query too large. Results truncated."); Can you give more information on what map you were playing in, how late in the game were you and what /seemed/ to trigger the error? Were there a lot of units on the screen?
  23. A little preview for non-believers, I reckon. The idea is to drop the use of simple entity_id_t handles that we used in the past in the SpatialSubdivision class, where we had to do some searching for the entities own grid every time we did a lookup, which was kind of silly. Also, a huge downside of using Spatial Subdivision grid, was with buildings - a building can take several tiles, which complicated the range query algorithm. We had to sort all the results and then call std::unique on the results to remove the duplicate building id's. Worst of all - the Spatial Subdivision grid class provid
  24. Hi again jcantero. All of your statements regarding what /should/ be done is correct, however the current implementation pretty much forces these silly constraints. Basically they're bugs and issues with the approach/algorithm itself. And to fix the issues, the original programmer just threw CPU cycles at the issue to solve it. Hence we have std::sort + std::unique. Why do we need that? Because large buildings can exist in several tiles at the same time.... I know, sounds very silly, right? Well that's the only reason we need std::sort and std::unique. I explore this issue in detail in my late
  • Create New...