Jump to content

scroogie

Community Members
 View Profile  See their activity

  • Posts

    76

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Everything posted by scroogie

  1. scroogie
    Can I toggle/force a track change somehow to test that?
  2. scroogie
    It happens right from the start (in the main menu) and then every few minutes. I can try to time it if it helps.
  3. scroogie
    No, this is a Core i5-3570 on an Z77 chipset (no further sound card). Running Linux, Kernel 3.7.10.
  4. scroogie
    Actually that is the first error (apart from the sound stuff I reported in the other thread): <!DOCTYPE html> <meta charset="utf-8"> <title>Pyrogenesis Log</title> <style>body { background: #eee; color: black; font-family: sans-serif; } p { background: white; margin: 3px 0 3px 0; } .error { color: red; } .warning { color: blue; }</style> <h2>0 A.D. Main log (warnings and errors only)</h2> <p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345) </p> <p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345) </p> <p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345) </p> <p class="error">ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345) </p> <p class="error">ERROR: JavaScript error: gui/session/session.js line 452 ReferenceError: type is not defined updateHero()@gui/session/session.js:452 onSimulationUpdate()@gui/session/session.js:413 __eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0</p> <p class="error">ERROR: JavaScript error: gui/session/session.js line 452 ReferenceError: type is not defined and then the last one is repeated endlessly.
  5. scroogie
    "Reduced archer attack damage." --- nooo, my precious archers. Looking forward to all those changes.
  6. scroogie
    After some minutes in the game, I endlessly receive the following message: ERROR: JavaScript error: gui/session/session.js line 452 ReferenceError: type is not defined updateHero()@gui/session/session.js:452 onSimulationUpdate()@gui/session/session.js:413 __eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0 ERROR: JavaScript error: gui/session/session.js line 452 ReferenceError: type is not defined updateHero()@gui/session/session.js:452 onSimulationUpdate()@gui/session/session.js:413 __eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0 ERROR: JavaScript error: gui/session/session.js line 452 ReferenceError: type is not defined updateHero()@gui/session/session.js:452 onSimulationUpdate()@gui/session/session.js:413 __eventhandler36 (simulationupdate)([object Object])@sn simulationupdate:0 ERROR: JavaScript error: gui/session/session.js line 452
  7. scroogie
    I periodically receive this message on every game now: ERROR: OpenAL error: Invalid Enum; called from FadeToIn (line 345) *Update*: See http://www.wildfiregames.com/forum/index.php?showtopic=17314entry269697 for solution. Default OpenAL version in OpenSUSE 12.3 has the bug mentioned there. Using the multimedia repository (http://pmbs.links2linux.org/project/repositories?project=Multimedia for 12.3: http://download.opensuse.org/repositories/multimedia:/libs/openSUSE_12.3/) and doing a zypper dup fixes the issue.
  8. scroogie
    I don't know why yet, but I'm getting patch: **** malformed patch at line 1658: Index: source/simulation2/components/CCmpObstructionManager.cpp
  9. scroogie
    So if I see that correctly, the WIP-Pathfinder is a hierarchical A* with JPS optimization on a Grid of 16 cells per terrain cell with unit-based clearance and using a points-of-visibility algorithm with higher precision obstruction edges on the local step (local being the way to the next high level waypoint?)? That seems like quite a beast.
  10. scroogie
    There is no such thing as "the boost". Boost is a collection of libraries, which you are free to use separately. Most of them are only made up of some header files that you can simply copy somewhere. iirc for 0ad you only need to build filesystem and signals, the rest is just headers.
  11. scroogie
    Applied the patch for fun: - doesn't apply cleanly anymore - C++0x errors (need flag in all makefiles) - ambiguous overloads in CCmpRangeManager (due to removal of implicit cast) - misses some coding conventions (trivial things like position of pointer symbol etc.) - duplicate isqrt (both in header and cpp) - fast_blur_halide misses the intrinsics includes and is never used (?) - contains some commented out code? Don't know if its related, but also after a few minutes the game errored, printing this over and over: ERROR: JavaScript error: gui/session/session.js line 452 ReferenceError: type is not defined updateHero()@gui/session/session.js:452 onSimulationUpdate()@gui/session/session.js:413 __eventhandler34 (simulationupdate)([object Object])@sn simulationupdate:0
  12. scroogie
    I was curious about this. Actually, the code of the pathfinder points to the "points of visibility" article in GPG. As I had that lying around I had a look, and the article specifically says that POV is a reasonable choice if you have 3D with few dynamic obstacles. For RTS it suggests a rectangular Grid approach. I think its also meant to have the edges precomputed instead of on the fly? If I look at the code, seeing edges between passability classes, edges between obstruction squares, a sort for every open vertex etc. I'm wondering if this is actually much faster than simply searching the squares with heuristic directly?
  13. scroogie
    As an addition to what quantumstate said, it depends on what your angle is supposed to mean. Is it relative to the current moving direction or global? Also, again rephrasing what quantumstate said, you have to make sure your turning direction is always equal. Usually you only have the smallest angle in arbitrary direction. How do you calculate the angle?
  14. scroogie
    As has been said before, many things are cpu-bound right now. You can step into the different components with the number in front of the lines, so maybe you can localize the culprit by stepping into sim update.
  15. scroogie
    Note that I never implemented flow fields. These are just my thoughts about the algorithm. > What do you mean with oscilating paths? Units moving left-right-left-right ... ? Yes. I would expect that relative to the original goal, units will periodically divert into orthogonal directions, as they toggle between taking an alternative route and completely following "the flow". This is basically the cost of approximating a global problem with local solutions. > I think that can be solved by smoothing it out. Don't go to the exact pixel with the least cost, but look 3-4 pixels ahead. That's only a very small calculation, > and if the resolution of the flow field is big enough (so that every obstacle is bigger than 4 pixels) it should not cause routing problems. Principally, yes, but I would expect it to be a bit tricky in detail. What you describe works great with typical paths (bread-crumbs), but in this case your cells are much smaller (its your local direction after all).
  16. scroogie
    As far as I understand, a flow field is rather a vector field pointing to the cheapest local steering direction relative to the goal (or is that what you meant with routing tree?). So units are still free to choose the direction in which they steer, but diverting from the vector field direction will raise the movement cost. I would think you combine it with a dynamic cost map and coarse planning/replanning, so that units choose a different coarse path if the prior one is blocked. The fine movement will then be directed by the flow field. I guess you will get problems with oscillating paths, but it should work with formations etc.
  17. scroogie
    Very interesting read. Its great to gain some insight like this! Its already enjoyable to play against Aegis, although I noticed some glitches when I tried it yesterday. I played on Sahel Watering Holes and at some time the AI, apparently undaunted by death, intended to build a CC in one tight corner that was left neutral territory. Of course I had some defense at the entrance to my island, but it kept trying to squeeze through with a horde of workers and civil soldiers. So I guess the point "No sense of "this is a dangerous area, I should avoid going/collecting/building there"." is indeed quite important. Looking forward to even more great improvements!
  18. scroogie
    Are you sure that a relational database is a good fit for this feature? I'd guess that you'd rather need a more specialized graph database, of course depending on which approach you want to take (game trees etc.). Performance will most probably also get critical.
  19. scroogie
    quantumstate: Wouldn't it be enough to implement a quadtree for the map/entities? Or would you need the 3rd dimension somewhere? And could you elaborate the idea in your last post a bit? Isn't the sim interpolation also for calculating positions etc. (which would still be needed for units out of sight)? Sorry, but maybe others are also interested.
  20. scroogie
    I see, thanks for the info! As I said, I was just wondering about the integer square root.
  21. scroogie
    I was not trying to be clever. I don't know why you start getting like that. I was stating a simple fact. Why would you use an approximation if you're slower? Makes no sense. And I know fully well what the manhattan distance is. It is not an approximation, that is for sure.
  22. scroogie
    Yes, but an approximation should be faster, not slower. This is not it I think. There seem to be different generations of profilers. Ok, thanks for the hint. I'll have to think about this.
  23. scroogie
    In a small callgrind run, I've seen that the fixed point integer square root function consumes quite some time in path computation. The attachments show three cases of CCmpPathfinder_Tile::ComputePath recorded through a CALLGRIND_START_INSTRUMENTATION and CALLGRIND_STOP_INSTRUMENTATION in the function itself (otherwise valgrind was too slow for me to use). Has the isqrt64 been benchmarked against the "normal" lm function? I don't have much time, but some initial tests seem to suggest that a casted sqrt is faster than the custom function in my case, even when casting from u32 to double and back. Or do I miss some other reason for this function? And out of curiosity, is the CProfiler2 stuff visible in two of the graphs required for some kind of runtime performance adaptation? The callgrind run is from saturday mornings SVN iirc, in case something was changed recently.
  24. scroogie
    Confirmed. Thanks.
  25. scroogie
    Here is a backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00000000008494e5 in CRenderer::GetMaterialManager (this=0x0) at ../../../source/renderer/Renderer.cpp:2116 2116 return m->materialManager; (gdb) bt #0 0x00000000008494e5 in CRenderer::GetMaterialManager (this=0x0) at ../../../source/renderer/Renderer.cpp:2116 #1 0x0000000000806571 in CTerrainTextureEntry::CTerrainTextureEntry (this=0x11b13f0, properties=..., path=...) at ../../../source/graphics/TerrainTextureEntry.cpp:109 #2 0x00000000007e06f4 in CTerrainTextureManager::AddTexture (this=0x1174ae0, props=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:103 #3 0x00000000007e09aa in CTerrainTextureManager::LoadTextures (this=0x1174ae0, props=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:138 #4 0x00000000007e0cdc in CTerrainTextureManager::RecurseDirectory (this=0x1174ae0, parentProps=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:169 #5 0x00000000007e0c8a in CTerrainTextureManager::RecurseDirectory (this=0x1174ae0, parentProps=..., path=...) at ../../../source/graphics/TerrainTextureManager.cpp:166 #6 0x00000000007e0ebb in CTerrainTextureManager::LoadTerrainTextures (this=0x1174ae0) at ../../../source/graphics/TerrainTextureManager.cpp:176 #7 0x000000000067cced in CReplayPlayer::Replay (this=0x7fffffffe1d0) at ../../../source/ps/Replay.cpp:138 #8 0x00000000004a64a3 in RunGameOrAtlas (argc=2, argv=0x7fffffffe4f8) at ../../../source/main.cpp:471 #9 0x00000000004a6b0b in main (argc=2, argv=0x7fffffffe4f8) at ../../../source/main.cpp:550
×
×
  • Create New...