Jump to content

RedFox

WFG Retired
  • Content Count

    245
  • Joined

  • Last visited

  • Days Won

    7

RedFox last won the day on September 10 2013

RedFox had the most liked content!

Community Reputation

48 Excellent

About RedFox

  • Rank
    Real-time Systems Programmer

Previous Fields

  • First Name
    J.
  • Last Name
    Fox
  • Skype ID
    jorma.rebane

Profile Information

  • Gender
    Male
  • Location
    Estonia
  • Interests
    C/C++, x86 ASM, hardcore performance

Contact Methods

  • Skype
    jorma.rebane

Recent Profile Visitors

803 profile views
  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
×
×
  • Create New...