Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2018-12-18 in all areas

  1. Yay I got some screenshots of a new map that will show up in the next version, taking place on the beaches of Lanayru
    4 points
  2. Update: textures retouched. Currently working on special structures that will generate resources.
    4 points
  3. "Ridiculously complex" is a bit of an overstatement. None of the code is super easy but there's nothing too unexpected - except for unitMotion maybe. The pathfinder is actually 5 components: The obstruction manager handles collisions (for unitMotion - not the pathfinder proper) and rasterising static obstacles (like buildings and terrain) and keeping track of units. UnitMotion handles the actual movement logic. It's terribly written at the moment (buggy, unclear and inefficient at actually moving sanely…) and I have a patch (I think it's D13) fixing it. On top of that, we need to change the architecture to a Data-oriented design - I may or may not have a patch for this, can't recall, but I've definitely done it somewhere. The hierarchical pathfinder handles accessibility (and could be used to handle high-level pathfinding, but it's not really much faster). It creates big "regions" and connects them. That's where flood-fill comes in. I have a patch (D53 I think) that improves its performance. The "long-range pathfinder", AKA the A* JPS pathfinder, is pretty well optimised (aka making it much faster would take too much work). It can create a path from navcell A to navcell B using the rasterised map of the obstruction manager - so no unit avoidance here. The "short-range pathfinder", aka the vertex pathfinder, aka a graph pathfinder, is used to walk around units. It's triggered by unitMotion when getting stuck in some special circumstances. It creates on-demand an exact map of all units and A* on that. Nothing is threaded right now but two things are 'easily' threaded: the long and short paths computations. These are currently done between turns, and could be parallelised. Doing it _super_ safely would mean rewriting some stuff, doing it kinda dangerously is very easy and I have a patch for it on Phabricator somewhere. I also have (this one indeed very WIP) patch for unit-pushing, which removes most of the need for the short-range pathfinder (it's still useful to keep around for stuff such as finding your way around a resource). The short-range pathfinder might be optimised for the common-is case of several units close together since we could reuse the graphs across computations if those are in the same region - but it's not trivial to do correctly. The other patches are pretty much finished and ready to merge, they just need some review and some more testing.
    2 points
  4. Everything is simpler: you're building debug, but running release. To run debug you need to run the pyrogenesis_dbg
    2 points
  5. No, thanks. I can test it on Windows myself. Only reason I haven't already done so is because I haven't compiled it for Windows yet. No problem Sorry for that It has been very pleasant for me so far.
    1 point
  6. @wraitii "doing it kinda dangerously is very easy and I have a patch for it on Phabricator somewhere". Well, I've updated* your patch so it compiles on latest version. And I must admit I was quite surprised with the result. It really significantly decreased amount of lags for single player game. However when I tried to open replay took with original version, I got out of sync error. (actually not a suprise) However there were no problems when I've played a multiplayer game over LAN. Even when using different amount of worker threads for each game instance. Not only that there were no problems, while there were still some lags in single player game, in multiplayer game lags actually disappeared. 3 players, 1500 units fighting in the center of map, 46 FPS and almost no lags (almost means that there still were some lags, but they were almost unnoticeable). 2 instances of the game running at computer with intel i5-7300 and NVIDIA GTX 1050 8GB RAM, and 1 instance running at computer with intel i5-5th gen and NVIDIA GTS 450 8GB RAM. When I recreated this situation with original version of the game, lags were so huge that game was almost unplayable. I've added option in settings, so players can change amount of worker threads (I actually used it just for debugging purposes, probably not needed for end users). I haven't noticed any problems with determinism in this one game. I've uploaded it back to D14. Oh, and I only tested it on linux, but I think it should work on other platforms too. I'm now thinking about more safe version, since it would be very nice to save such speedup. * 'updated'... hmm... actually changed a few lines....
    1 point
  7. Hello @Trinketos That's because you are using the VS2017 compiler instead of the 2015 one. You need to install the 2015 compiler using the visual studio installer.
    1 point
  8. Better indeed. Don't forget add plants and mold.
    1 point
  9. I don't know for games but I didn't really see it for the ar vr xr dev
    1 point
  10. I wish we had grass like that tho.
    1 point
  11. also for term of use , term of service and policy please make it in 1 shot for the user instead of 3 separate screens and accept
    1 point
  12. 1 point
  13. Thanks for the recommendation to use an ao. It now looks 100% better. More awesomeness added.
    1 point
×
×
  • Create New...